Add electrical engineering persona, protocols, and hardware lifecycle pipeline #91
Description
Summary
Add an electrical engineering domain to PromptKit — persona, analysis protocols, and a hardware lifecycle pipeline for spec-first PCB/electrical design. This extends the library from software-only into hardware engineering, starting with the domain most synergistic with the existing embedded firmware components.
Problem
PromptKit can audit software specs, firmware specs, and protocol specs — but hardware specifications (schematics, netlists, BOMs, simulation results) have no coverage. Engineers designing PCBs follow a lifecycle analogous to software: requirements → schematic → simulation → layout → manufacturing files. Each stage produces artifacts that can be audited against the requirements, but there are no personas, protocols, or templates for this.
Proposal
Persona: electrical-engineer
Domain expertise in:
- Power delivery networks (regulators, voltage domains, decoupling strategy)
- Signal integrity (impedance matching, termination, crosstalk, EMI)
- Voltage domain crossings and level shifting
- ESD protection and transient suppression
- Thermal derating and thermal design
- Component selection constraints (package, availability, temperature range)
- Schematic-to-layout traceability
- Standard interfaces (UART, SPI, I2C, USB, Ethernet PHY, etc.)
Natural pairing with existing \�mbedded-firmware-engineer\ persona for full hardware+firmware spec audits.
Protocols (analysis)
Potential protocol candidates (each a separate file):
- schematic-compliance-audit — Audit a netlist or schematic against requirements. Check: missing pull-ups/pull-downs, unconnected pins, wrong voltage domains, missing decoupling, ESD protection gaps, power sequencing violations.
- simulation-validation — Review SPICE or other simulation output against requirements. Check: voltage/current margins, timing constraints, thermal limits, transient behavior.
- bom-consistency — Audit a BOM against schematic and requirements. Check: correct part numbers, voltage/temperature ratings, package footprint matches, single-source risks.
- layout-design-review — Audit KiCad/EDA DRC output and layout decisions against schematic intent. Check: trace widths for current capacity, impedance-controlled routing, ground plane integrity, thermal relief.
Templates
- review-schematic — Audit a schematic/netlist against requirements
- validate-simulation — Audit simulation results against spec
- review-bom — Audit BOM for correctness and risk
- review-layout — Audit PCB layout against schematic and requirements
Pipeline: hardware-lifecycle
Spec-first hardware design lifecycle:
\
requirements → schematic audit → simulation validation → BOM audit → layout review
\\
Each stage consumes the requirements document and the stage-specific artifact. Analogous to the existing \document-lifecycle\ pipeline.
LLM Tractability Notes
- Schematics/netlists: LLM-tractable when provided as text-based netlists (KiCad netlist format, SPICE netlist). NOT tractable as images.
- Simulation results: LLM-tractable when provided as text/CSV output (voltage/current measurements, timing data).
- BOMs: LLM-tractable (CSV/spreadsheet data).
- Layout/DRC: LLM-tractable when provided as DRC report text. Raw Gerber files are binary geometry — likely past the LLM usefulness boundary.
- Gerber files: Out of scope — binary format, geometry-level, not spec-level analysis.
Dependencies
- Builds on: \�mbedded-firmware-engineer\ persona (shipped ✅)
- Reuses: \investigation-report\ format, \spec-invariant-audit\ protocol (for spec-level analysis)
- Related: \�udit-spec-invariants\ template (shipped ✅) — can audit hardware specs against invariants today using the existing template with a custom persona
Scope
This is a large body of work. Suggested phasing:
- Phase 1: Persona + schematic-compliance-audit protocol + review-schematic template
- Phase 2: simulation-validation protocol + validate-simulation template
- Phase 3: BOM and layout protocols/templates
- Phase 4: hardware-lifecycle pipeline definition