A Claude Code Skill That Asks the Questions You Forgot to Ask
- Yoel Frischoff
- Feb 22
- 4 min read
Updated: Mar 12
You have a product idea. It includes a microcontroller, a couple of sensors, and maybe an app. You can picture it working. You can almost feel the enclosure in your hand. But can you describe the firmware update mechanism? What about the power budget under peak load? What happens when the BLE connection drops mid-transfer? Which side of the HW/SW boundary owns the calibration logic? These questions often arise six months later, during EVT, when it’s expensive.
The Gap Between Two Toolkits
Software PMs have their tools — user stories, PRDs, sprint planning. Hardware PMs have theirs — datasheets, BOMs, and DFM checklists. But products that combine both — firmware-driven hardware with sensors, actuators, a companion app, and maybe a cloud backend — fall between these two worlds. Most teams reach for one template or the other, covering the rest in meetings and Slack threads.
The HW/SW boundary, where the most expensive integration surprises lurk, often becomes implicit knowledge in someone’s head. It stays there until it becomes a problem.
Seven Phases of Asking "What About...?"
Electrum is a structured way to interrogate a product idea before you commit to it. It’s built as a Claude Code skill — type `/electrum <your idea>` and it starts a dialogue that walks through seven phases. The key word is dialogue. This isn’t just a form to fill out. Each phase involves back-and-forth interaction: the system drafts, you push back, it revises, and you push back again. It’s Socratic in nature — the value lies not in the answers it generates but in the questions the process forces you to confront.
Phase 1: Explore
Where does the hardware end and the software begin? Which of the 16 competency areas does this product touch — analog signal conditioning? RF design? Cloud infrastructure? Regulatory compliance? What don’t you know yet? The output is an exploration document that maps the terrain before you start designing.
Phase 2: High-Level Design
This phase is concise — just one page. It includes a block diagram, subsystem boundaries, interface protocols, and constraints. You also identify the three hardest unsolved problems. This is where your idea meets physics. "Runs on a coin cell" collides with "streams data over BLE at 100 Hz." Good! You want those collisions now, not later.
Phase 3: System Description
Now, push harder. Name specific components — not "an MCU" but "nRF52840." Not "a battery" but "3.7V 500mAh LiPo with a 15-hour target runtime." Create power budgets with real numbers. Specify interface specs with actual protocols. Break down the firmware architecture into modules. The goal isn’t to write the final engineering spec but to see where your idea breaks when you apply specifics.
Phase 4: Gate Checklist
This checklist contains 90 items. Each can be marked as PASS, FAIL, or N/A. Many items specifically target the HW/SW boundary: "Is the watchdog timer behavior defined for each failure mode?" "Are sensor sampling rates compatible with the processing pipeline?" "Is there a defined strategy for field firmware updates?" Each FAIL indicates a conversation you haven’t had yet. The checklist doesn’t tell you the product is ready; it reveals what you’re still assuming.
If the FAIL count is high, the process sends you back to Phase 3 to revise. This loop — describe, validate, revise — is where most of the discovery happens.
Phases 5–7: Communicating the Concept
The final phases shift from thinking to communicating. You create product illustrations via DALL-E, an 8-page slide deck, and a PDF carousel. These are useful for sharing the idea with others, but the real work lies in Phases 1–4.
The Conversation Is the Product
What sets this apart from a document generator is the rhythm. Each phase pauses for reflection. You read what was produced. You might disagree with a component choice, notice the power budget doesn’t add up, or realize the firmware architecture assumes a feature the hardware can’t support. You voice your concerns, and the document gets revised. Then, you move on.
The gate checklist is particularly effective at provoking thought. You might read "FAIL: No defined behavior for loss of sensor calibration during power brownout" and think — right, we never discussed that. That one item could reshape the firmware architecture or be irrelevant for this product. Either way, you’re making the decision consciously instead of discovering the gap during testing.
The process works because it’s progressive. Exploration gives you vocabulary. High-level design provides structure. System description offers specifics. The checklist ensures accountability. Each phase builds on the previous one, surfacing different classes of questions.
Try It With a Bad Idea
Seriously, pick a product concept you’re unsure about — the weirder, the better. Think of a clip-on chair tilt sensor that beeps when you lean too far. Or a wrist-worn haptic metronome for drummers. Maybe an indoor air quality monitor with mesh networking.
Run it through the seven phases. The exploration will reveal which technical domains you need to staff. The high-level design will show where the system complexity actually resides. The system description will force you to choose real parts and perform real calculations. The gate checklist will highlight what you’re still hand-waving about.
Within an hour, you’ll know whether the idea has legs — not because the tool told you, but because the process compelled you to think it through.
What’s in the Repo
Templates — high-level design template, system description template, 90-item gate checklist, 16-area skills map, and the 7-phase workflow description.
Reference scripts — Python code for generating product illustrations (DALL-E via Playwright), building PPTX carousels, and creating block diagrams.
Three worked examples — a chair balance sensor, a haptic metronome bracelet, and a smart sensor hub, each at varying levels of completeness.
The templates work without AI. You can copy them, fill them in by hand, and run the checklist yourself. The Claude Code skill just speeds up the conversation.
It’s a research and exploration tool, not a production methodology. Take the parts that provoke useful thinking and skip the rest.
Comments