Skip to main content
A useful request says what should change, what must remain true, and how to verify the result.

Give the task a finish line

For a bug, include the symptom, conditions, and expected behavior. For research, ask for findings before choosing an implementation.

Attach precise context

Use @ to select relevant files or directories. A directory reference does not include every implementation inside it, so point to the smallest useful scope. After uploading schematics, cite a component or net:
Paste or drop an image when its visual details matter. Add a caption describing the question, such as the failing transaction in a logic capture.

Keep project instructions current

Run /init to create or refresh EMBEDDER.md. Record exact commands, target selection, expected output, and generated-code boundaries. Update the guide when the toolchain, board, or build configuration changes. A command that existed on a previous workstation may need rechecking.

Pick the right mode

  • Plan: investigate alternatives and review an approach before editing implementation files.
  • Act: implement, run tests, build, and perform ordinary hardware checks.
  • Debug: inspect debugger state or run bounded instruction and coverage captures.
Approval settings remain separate from mode selection.

Ask for evidence at each stage

Require output that answers the actual question: a passing regression test, verified image, specific log line, decoded frame, or measured waveform.

Preserve useful hardware state

A reset or reflash can destroy evidence. If the board is faulted, ask for attach-only inspection before changing it. For measurements, identify the instrument, wiring, limits, and duration. Keep the same firmware and workload when comparing before and after. Record any halt or instrumentation that could change timing.

Steer work in progress

Send a follow-up during a turn to add constraints or correct course. Embedder picks it up at the next step boundary. Review queued messages and remove any that no longer apply. See Sessions and context.

Reuse what worked

Save repeatable checks as hardware scripts, recurring procedures as skills, and confirmed project facts as memory. Review the final diff and unresolved limitations before treating a task as complete.
Last modified on September 18, 2026