Load only the context you need

Use the site’s machine-readable outputs instead of scraping rendered HTML:

Endpoint	Use
/llms.txt	Compact discovery index with links to the important Markdown pages
/llms-full.txt	Complete site content as one text document, without navigation or page chrome
/docs/tooling/serial-and-device-control.md	One documentation page as Markdown; other pages follow the same .md URL pattern
/docs-index.json	Structured page metadata, Markdown locations, headings, and content hashes
/SKILL.md	Agent skill generated from this page during the site build

Start with llms.txt, then fetch only the pages needed for the task. Use llms-full.txt when the agent genuinely needs the complete documentation set.

Invoke-RestMethod https://bub.0xbubbuff.de/llms.txt
Invoke-RestMethod https://bub.0xbubbuff.de/docs/tooling/serial-and-device-control.md

Work in the owning repository

The LilBub workspace contains independent repositories:

Repository	Owns
lil_buddy	ESP32-S3 firmware, the Python harness, DeviceControl, and hardware tests
LilBuddyBackend	Go API, MQTT, Redis, Supabase persistence, and relay services
LilBuddyFrontend	React/TypeScript web and Android management surfaces
LilBubSite	Public documentation and machine-readable documentation exports

Run Git commands and project checks from the relevant child repository. Read its local instructions before editing, and preserve unrelated uncommitted changes.

Start with read-only evidence

1. Identify the owning repository and inspect its current state.
2. Load the specific documentation page for the task.
3. Diagnose with source, tests, logs, or read-only DeviceControl methods.
4. Confirm the exact device, build, and intended state change before a control or destructive operation.
5. Make the smallest coherent change and run the owning repository’s checks.

Do not upload firmware, reset services, provision credentials, or change hosted infrastructure unless the user explicitly requests that action and the target is confirmed.

Use DeviceControl for device work

Set up the harness from lil_buddy/harness:

python -m venv .venv
& .\.venv\Scripts\python.exe -m pip install -e ".[test,e2e]"
& .\.venv\Scripts\lilbub.exe discover
& .\.venv\Scripts\lilbub.exe doctor

Begin with identity, health, and capability queries:

& .\.venv\Scripts\lilbub.exe call system.info --serial COM6
& .\.venv\Scripts\lilbub.exe call system.health --serial COM6
& .\.venv\Scripts\lilbub.exe call control.capabilities --serial COM6

Use semantic UI methods and harness screenshots instead of guessing touch coordinates. Ask for the compiled method inventory instead of assuming two firmware builds expose the same operations. Close other serial monitors before giving the port to the harness.

Verify in proportion to the change

Area	Default check
Firmware	platformio run -e waveshare_hw
Backend	go test ./...
Frontend	npm run typecheck, npm run lint, and npm run build
Public documentation	bun run build and the focused documentation tests

Use physical-device tests when correctness depends on Bluetooth, touch geometry, the circular display, brightness, animation, or the display pipeline. Treat a source file or test harness as evidence that an implementation exists, not as a substitute for a named hardware result.