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