Hardware — parts, circuits, firmware, bring-up, traps
Rule content lives in the five files below; this SKILL.md only routes
(doctrine/04-maintenance.md governs edits to this bundle too).
Route by moment
| You are about to… | Read (in this folder) |
|---|---|
| Pick an MCU, module, sensor, or any component; judge a BOM or parts proposal | parts.md |
| Design or review a circuit: power, protection, interfaces, layout concerns | circuits.md |
| Write or review embedded firmware (loops, ISRs, watchdogs, OTA, flash) | firmware.md |
| Debug a physical board, plan first power-up, or validate before shipping | bringup.md |
| Estimate battery life or a power budget ("how long on a 2000mAh cell?") | circuits.md §1 + traps.md A5 — peak budgeting, measured charge per duty cycle |
| Review a hardware project's health; name why a design or process feels fragile | traps.md |
A new design usually runs parts.md → circuits.md (power tree first) → firmware.md,
with bringup.md §1 consulted BEFORE layout — bring-up is designed, not improvised.
Scope and neighbors
Physical-world engineering judgment. Firmware architecture inherits backend/logic.md
(this bundle adds the physics); debugging inherits methods/investigate.md (this bundle
adds instruments and the four failure domains); whether to delegate → doctrine.
The stance
The physical world is analog, undocumented, and expensive to iterate: derate, measure,
and design for bring-up — and treat every datasheet as a contract whose real terms are
in the footnotes (parts.md §4). One honest limit governs all debugging here: the model
cannot see the board, so measurements come before theories (bringup.md §4).
