Hardware

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).