arduino-workflow-router

Embedded Workflow Router

Use this skill as the concise entrypoint for complete or cross-discipline embedded work. For a focused task with a confirmed board and one stage, load the specialist skill directly.

Recommended lifecycle entry

For any physical or multi-session request, load embedded-project-loop first. It establishes the goal, one next action, evidence boundary, rollback path, and user-owned physical gate. Then return here for board and toolchain routing.

Load First

1. Read ../../docs/arduino-skill-contract.md.
2. If the work spans sessions or physical actions, embedded-project-loop is

the recommended first skill; create its goal/next-todo state before implementation and keep it open until the evidence gate is satisfied.

1. Fill ../../docs/board-support/board-profile-template.md or state why it is

unnecessary.

1. When a named board or board family must be resolved, load

../board-support/SKILL.md and its indexed profile before selecting pins.

1. Read references/board-intake.md for board and hardware checks.
2. Read references/toolchain-selection.md for IDE, CLI, PlatformIO, or vendor

version and library compatibility.

1. Select specialist skills from the routing table below.
2. Read references/failure-recovery.md before upload, boot, power, or firmware

recovery actions; read references/connected-device-security.md for any networked or updateable device.

This is the load-first order. Load on demand: references are loaded only when their trigger applies, so the router stays under 500 lines and detailed variants remain progressive disclosure.

Trigger precedence

• For combined, underspecified, or cross-discipline requests, this router owns

the first route. Load it before any overlapping specialist, including arduino-project-builder or board-selection.

• For physical or multi-session requests, load embedded-project-loop before

this router, then return to this router for the combined specialist route.

• For a single-stage request with a confirmed board and toolchain, load the

narrowest specialist directly.

• For a named-board reference or capability lookup, board-support owns the

exact identity and source-backed profile. board-selection owns choosing or replacing a board from requirements and may consume its handoff.

• A board-choice request without implementation, wiring, or lifecycle work may

start at board-selection; once another discipline appears, return to this router and preserve the combined-workflow order.

• Do not load both arduino-serial-monitor and a second serial-debugging skill;

the existing serial monitor owns structured runtime evidence.

Intake Gate

Do not invent a pin, voltage, current limit, memory size, peripheral, protocol, library version, or upload command. Ask for the missing value or proceed with a clearly labeled assumption and a verification step. Record the exact board, framework, toolchain, host, dependency versions, and desired proof stage.

Routing Table

Combined Workflows

Toolchain precedence: when a repository selects PlatformIO or a native SDK, embedded-build-workflow owns build intake. Do not route native app_main, Zephyr, Pico SDK or Rust projects to Arduino CLI by default. See the support matrix before claiming a framework, target or host is validated. Consult the active BottleSumo lessons for mixed builds, separate flash/PSRAM settings, wireless evidence, OTA and bench control.

Skills can be used together. Keep one owner for each decision and pass its artifacts to the next skill. For a combined request, use this concise default order:

loop (if long-running) -> board selection/intake -> wiring safety -> library/memory -> project/code/timing -> toolchain build/upload -> serial and hardware tests -> system/calibration -> deployment/security/maintenance

Default combined order: arduino-workflow-router -> board-selection -> board-support -> pin-assignment -> wiring-safety-check -> sensor-signal-filtering -> non-blocking-patterns -> arduino-serial-monitor -> hardware-tdd. Start with embedded-project-loop when the work spans sessions or physical gates, then keep its next-todo and evidence ledger open through the later stages.

If the user already supplied an exact, supported board identity, skip board-selection and begin with board-support; never skip board-support before pin or electrical advice.

• Battery-powered Wi-Fi sensor: board intake -> datasheet -> power ->

project builder -> code generator -> toolchain -> serial/calibration -> OTA security -> maintenance README.

• Uno R4 WiFi upload incident: board-family reference -> IDE/CLI discovery

-> serial and error diagnosis -> USB/power checks -> boot recovery -> upload proof -> runtime/system proof. See ../../docs/board-support/uno-r4-family.md.

• Robot controller: board intake -> project builder -> power/BOM -> circuit

and code -> serial/system tests -> enclosure -> signed update and rollback.

• Multi-board sensor library: board profiles -> datasheets/protocol bringup

-> code generator -> IDE/CLI/PlatformIO branches -> per-board build proof and documented unsupported behavior.

• Four-button ESP32 controller: board selection -> pin assignment -> wiring

safety -> non-blocking debounce -> code generator -> build proof -> hardware gate -> serial/system evidence.

Do not treat a table row as proof that a skill was run. Report which skills were actually used, which artifacts they produced, and which evidence stages remain unverified.

Output Contract

Use ../../docs/arduino-skill-contract.md: state assumptions, required tools and versions, implementation steps, tests/evidence by proof stage, known limitations, and recovery/security notes.