Skip to main content
Follow this page to take a firmware change from setup to a verified result on the board. Treat each check as its own result: a passing build, a verified flash, and correct behavior on the board prove different things.

Set up the project

  1. Run /project and select a project. To start one, select New project in VS Code, or + Create new project in the terminal UI.
  2. Confirm the target platform. Then run /peripheral, or in VS Code select Open project peripherals in the chat header, to add the parts fitted to your board.
  3. Run /upload-schematics if Embedder needs the board’s connections.
  4. Run /init and confirm the build, test, debug, and hardware details Embedder finds. It records them in EMBEDDER.md.
See the Quickstart for the full first-run flow.

Plan a change with unknowns

Use Plan mode when a change spans several modules or depends on hardware details you haven’t confirmed. Run /plan, then describe the behavior and constraints:
Review the affected files, assumptions, error handling, and verification steps. Reply in the chat to request changes. When the plan is ready, approve it, and Embedder starts implementing in Act mode. See Agent modes. For a focused fix, stay in Act mode and be specific:

Build and test

Ask for the checks recorded in EMBEDDER.md:
Check that the reported output comes from the current build. If a step fails, fix the first useful error before you move on to hardware.

Flash and observe

Before you flash, confirm the board, the probe or remote bridge, the power setup, and the serial connection. Then ask:
Embedder can read output the serial port has already captured, or watch for new output while the board runs:
  • Ask it to check captured output when the message may already have appeared.
  • Ask it to monitor live when it needs to wait for the message.
An open serial tab in the Embedder Monitor doesn’t show that the expected message arrived. Ask Embedder to report the line it observed.

Investigate a failure

Switch to Debug mode with /debug when you need a debugger on the target, for example to read registers, memory, or the call stack after a fault or hang. Start from the output that already exists. When the target’s current state matters, tell Embedder not to disturb it:
For electrical or timing questions, ask for a bounded instrument capture. Name the channel assignments and the result you expect. Save the check as a hardware script so you can repeat it.

Review the outcome

Ask Embedder to summarize the changed behavior, the files it changed, the checks it ran, and anything it couldn’t verify. Each check answers a different question: Keep reusable commands in EMBEDDER.md and confirmed constraints in project memory.

Continue or change direction

In VS Code, queued messages appear above the input under Queued. In the terminal UI, press Ctrl+Q to list them. Review or remove the ones that no longer apply before you switch tasks; /clear discards them. See Sessions and context.
Last modified on November 13, 2026