Arduino 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
- Read
../../docs/arduino-skill-contract.md.
- 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.
- Fill
../../docs/board-support/board-profile-template.md or state why it is
unnecessary.
- When a named board or board family must be resolved, load
../board-support/SKILL.md and its indexed profile before selecting pins.
- Read
references/board-intake.md for board and hardware checks.
- Read
references/toolchain-selection.md for IDE, CLI, PlatformIO, or vendor
version and library compatibility.
- Select specialist skills from the routing table below.
- 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
| Need |
Load next |
Evidence focus |
| Requirements or board choice |
board-selection, then board-support, then arduino-project-builder |
decision and design |
| Named board reference or capability lookup |
board-support, then the relevant specialist |
exact identity and source-backed constraints |
| Pin map or GPIO declarations |
board-support, then pin-assignment, then wiring-safety-check |
board constraints and hardware |
| Wiring, voltage, current, or pull-ups |
wiring-safety-check, power-budget-calculator, circuit-debugger |
hardware |
| ADC/sensor noise, sampling, filtering, or signal conditioning |
board-support, wiring-safety-check, sensor-signal-filtering, then sensor-calibration-workbench after detection is proven |
signal-chain design and measured hardware behavior |
| Code pattern or board abstraction |
arduino-code-generator, non-blocking-patterns, memory-budgeting |
build and memory |
| Library or framework dependency |
library-selection, then the code/project skill |
compatibility and memory |
| Datasheet, component, or protocol uncertainty |
datasheet-interpreter, i2c-bringup-diagnostician |
hardware assumptions |
| Compile, board discovery, upload, or port |
arduino-cli-skill plus error-message-explainer |
build and upload |
| Runtime logs or field symptoms |
arduino-serial-monitor, error-message-explainer, hardware-tdd |
hardware and system |
| Timing, blocking, or watchdog risk |
non-blocking-patterns, hardware-tdd |
build and system |
| Memory or footprint risk |
memory-budgeting, library-selection |
build and runtime |
| Calibration or sensor drift |
sensor-calibration-workbench after detection is proven |
system |
| Complete application |
arduino-project-builder, then the relevant domain skills |
design and build |
| Connected update or field deployment |
ota-deployment-guardian plus the security reference |
deployment |
| Parts, PCB-adjacent, or enclosure work |
bom-generator, enclosure-designer, readme-generator |
design and maintenance |
| Host/simulation/target test plan |
hardware-tdd and embedded-project-loop when physical work is pending |
evidence |
| Multi-session, physical, or recovery work |
embedded-project-loop first, then this router |
durable state and user-owned gate |
Combined Workflows
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.
1---2name: arduino-workflow-router3description: Route Arduino and embedded-system requests across Arduino IDE, Arduino CLI, PlatformIO, and vendor-specific tools. Use when a request combines firmware, board constraints, electronics, power, networking, calibration, enclosure, upload, debugging, OTA, or maintenance, or when the exact board or toolchain is not yet clear.4---5
6# Arduino Workflow Router
7
8Use this skill as the concise entrypoint for complete or cross-discipline
9embedded work. For a focused task with a confirmed board and one stage, load the
10specialist skill directly.
11
12## Recommended lifecycle entry
13
14For any physical or multi-session request, load `embedded-project-loop` first.
15It establishes the goal, one next action, evidence boundary, rollback path, and
16user-owned physical gate. Then return here for board and toolchain routing.
17
18## Load First
19
201. Read `../../docs/arduino-skill-contract.md`.
212. If the work spans sessions or physical actions, `embedded-project-loop` is
22 the recommended first skill; create its goal/next-todo state before
23 implementation and keep it open until the evidence gate is satisfied.
243. Fill `../../docs/board-support/board-profile-template.md` or state why it is
25 unnecessary.
264. When a named board or board family must be resolved, load
27 `../board-support/SKILL.md` and its indexed profile before selecting pins.
285. Read `references/board-intake.md` for board and hardware checks.
296. Read `references/toolchain-selection.md` for IDE, CLI, PlatformIO, or vendor
30 version and library compatibility.
317. Select specialist skills from the routing table below.
328. Read `references/failure-recovery.md` before upload, boot, power, or firmware
33 recovery actions; read `references/connected-device-security.md` for any
34 networked or updateable device.
35
36This is the load-first order. Load on demand: references are loaded only when
37their trigger applies, so the router stays under 500 lines and detailed
38variants remain progressive disclosure.
39
40## Trigger precedence
41
42- For combined, underspecified, or cross-discipline requests, this router owns
43 the first route. Load it before any overlapping specialist, including
44 `arduino-project-builder` or `board-selection`.
45- For physical or multi-session requests, load `embedded-project-loop` before
46 this router, then return to this router for the combined specialist route.
47- For a single-stage request with a confirmed board and toolchain, load the
48 narrowest specialist directly.
49- For a named-board reference or capability lookup, `board-support` owns the
50 exact identity and source-backed profile. `board-selection` owns choosing or
51 replacing a board from requirements and may consume its handoff.
52- A board-choice request without implementation, wiring, or lifecycle work may
53 start at `board-selection`; once another discipline appears, return to this
54 router and preserve the combined-workflow order.
55- Do not load both `arduino-serial-monitor` and a second serial-debugging skill;
56 the existing serial monitor owns structured runtime evidence.
57
58## Intake Gate
59
60Do not invent a pin, voltage, current limit, memory size, peripheral, protocol,
61library version, or upload command. Ask for the missing value or proceed with a
62clearly labeled assumption and a verification step. Record the exact board,
63framework, toolchain, host, dependency versions, and desired proof stage.
64
65## Routing Table
66
67| Need | Load next | Evidence focus |
68|---|---|---|
69| Requirements or board choice | `board-selection`, then `board-support`, then `arduino-project-builder` | decision and design |
70| Named board reference or capability lookup | `board-support`, then the relevant specialist | exact identity and source-backed constraints |
71| Pin map or GPIO declarations | `board-support`, then `pin-assignment`, then `wiring-safety-check` | board constraints and hardware |
72| Wiring, voltage, current, or pull-ups | `wiring-safety-check`, `power-budget-calculator`, `circuit-debugger` | hardware |
73| ADC/sensor noise, sampling, filtering, or signal conditioning | `board-support`, `wiring-safety-check`, `sensor-signal-filtering`, then `sensor-calibration-workbench` after detection is proven | signal-chain design and measured hardware behavior |
74| Code pattern or board abstraction | `arduino-code-generator`, `non-blocking-patterns`, `memory-budgeting` | build and memory |
75| Library or framework dependency | `library-selection`, then the code/project skill | compatibility and memory |
76| Datasheet, component, or protocol uncertainty | `datasheet-interpreter`, `i2c-bringup-diagnostician` | hardware assumptions |
77| Compile, board discovery, upload, or port | `arduino-cli-skill` plus `error-message-explainer` | build and upload |
78| Runtime logs or field symptoms | `arduino-serial-monitor`, `error-message-explainer`, `hardware-tdd` | hardware and system |
79| Timing, blocking, or watchdog risk | `non-blocking-patterns`, `hardware-tdd` | build and system |
80| Memory or footprint risk | `memory-budgeting`, `library-selection` | build and runtime |
81| Calibration or sensor drift | `sensor-calibration-workbench` after detection is proven | system |
82| Complete application | `arduino-project-builder`, then the relevant domain skills | design and build |
83| Connected update or field deployment | `ota-deployment-guardian` plus the security reference | deployment |
84| Parts, PCB-adjacent, or enclosure work | `bom-generator`, `enclosure-designer`, `readme-generator` | design and maintenance |
85| Host/simulation/target test plan | `hardware-tdd` and `embedded-project-loop` when physical work is pending | evidence |
86| Multi-session, physical, or recovery work | `embedded-project-loop` first, then this router | durable state and user-owned gate |
87
88## Combined Workflows
89
90Skills **can be used together**. Keep one owner for each decision and pass its
91artifacts to the next skill. For a combined request, use this concise default
92order:
93
94`loop (if long-running) -> board selection/intake -> wiring safety ->
95library/memory -> project/code/timing -> toolchain build/upload -> serial and
96hardware tests -> system/calibration -> deployment/security/maintenance`
97
98Default combined order: `arduino-workflow-router` -> `board-selection` ->
99`board-support` -> `pin-assignment` -> `wiring-safety-check` ->
100`sensor-signal-filtering` -> `non-blocking-patterns` -> `arduino-serial-monitor` ->
101`hardware-tdd`. Start with
102`embedded-project-loop` when the work spans sessions or physical gates, then
103keep its next-todo and evidence ledger open through the later stages.
104
105If the user already supplied an exact, supported board identity, skip
106`board-selection` and begin with `board-support`; never skip `board-support`
107before pin or electrical advice.
108
109- **Battery-powered Wi-Fi sensor**: board intake -> datasheet -> power ->
110 project builder -> code generator -> toolchain -> serial/calibration -> OTA
111 security -> maintenance README.
112- **Uno R4 WiFi upload incident**: board-family reference -> IDE/CLI discovery
113 -> serial and error diagnosis -> USB/power checks -> boot recovery -> upload
114 proof -> runtime/system proof. See `../../docs/board-support/uno-r4-family.md`.
115- **Robot controller**: board intake -> project builder -> power/BOM -> circuit
116 and code -> serial/system tests -> enclosure -> signed update and rollback.
117- **Multi-board sensor library**: board profiles -> datasheets/protocol bringup
118 -> code generator -> IDE/CLI/PlatformIO branches -> per-board build proof and
119 documented unsupported behavior.
120- **Four-button ESP32 controller**: board selection -> pin assignment -> wiring
121 safety -> non-blocking debounce -> code generator -> build proof -> hardware
122 gate -> serial/system evidence.
123
124Do not treat a table row as proof that a skill was run. Report which skills were
125actually used, which artifacts they produced, and which evidence stages remain
126unverified.
127
128## Output Contract
129
130Use `../../docs/arduino-skill-contract.md`: state assumptions, required tools and
131versions, implementation steps, tests/evidence by proof stage, known
132limitations, and recovery/security notes.
wedsamuel1230