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