Decide where every function lives across hardware, firmware, app, and cloud — before tooling locks the choice in.
Open-source, MIT-licensed. The toolkit lives on GitHub; this page is the explainer and on-ramp.
Software PMs have PRD templates. Hardware PMs have datasheets and BOMs. When the product is both — firmware-driven hardware with sensors, actuators, maybe an app, maybe cloud — most teams use a software PRD that ignores physics or a hardware spec that ignores the software. The HW/SW boundary is where the expensive mistakes happen, and it is usually the least documented part of the product.
A four-phase workflow that takes a one-line product idea to a reviewable engineering definition.
explore_notes.md
HW/SW boundary sketch, knowledge gaps, hardest problems.
high_level_design.md
Single-page system overview an executive and an engineer both read.
system_description.md
Full engineering-grade spec — 10 sections, hardware and software in lockstep.
gate_checklist.md
90-item completeness validation, cross-domain review.
AI-assisted: 60–90 minutes for a full run By hand: a few days
The /electrum skill drives all four phases interactively, drafting at each step and pausing for your review.
git clone https://github.com/yoelf22/electrum.git
cd electrum
claude
> /electrum <describe your product in one sentence>Five files in the templates/ folder. Copy them into a project and fill them in — still 80% of the value the AI-assisted path produces.
A force-sensing bubble machine, run end-to-end through all four phases. Useful first read for a team trying the discipline.
Electrum is the boundary-discipline tool referenced in Chapter 13: Lean Hardware of Tangibles.
© 2026 Yoel Frischoff / TheRoad. All rights reserved.