Kicad

KiCad Project Analysis Skill

Related Skills

| Skill | Purpose | |-------|---------| | bom | BOM extraction, enrichment, ordering, and export workflows | | digikey | Search DigiKey for parts (prototype sourcing) | | mouser | Search Mouser for parts (secondary prototype source) | | lcsc | Search LCSC for parts (production sourcing, JLCPCB) | | element14 | Search Newark/Farnell/element14 (international sourcing, reliable datasheets) | | jlcpcb | PCB fabrication & assembly ordering | | pcbway | Alternative PCB fabrication & assembly | | spice | SPICE simulation verification of detected subcircuits | | emc | EMC pre-compliance risk analysis — consumes schematic + PCB analyzer output |

Handoff guidance: Use this skill to parse schematics/PCBs and extract structured data. Hand off to bom for BOM enrichment, pricing, and ordering. Hand off to digikey/mouser/lcsc/element14 for part searches and datasheet fetching. Hand off to jlcpcb/pcbway for fabrication ordering and DFM rule validation. Always run spice for simulation verification during design reviews when any SPICE simulator is installed (check with which ngspice ltspice xyce). Always run emc for EMC pre-compliance risk analysis during design reviews when both schematic and PCB analysis are available. These are not optional — skipping them leaves value-computation errors and EMC risks undetected.

Before analysis: When the user asks to analyze or review a KiCad project, check whether a datasheets/ directory exists in the project. If not, and DigiKey API keys are available (DIGIKEY_CLIENT_ID), offer to sync datasheets first: "I can download datasheets for your components before analysis — this enables pin-level verification and decoupling validation against manufacturer specs. Want me to sync them?" If the user declines or no API keys are set, proceed without datasheets — the analysis works without them but datasheet verification findings won't be available.

If you see a DS-001 finding in the analyzer output (severity high, detector audit_datasheet_coverage), the review cannot make any verified claim. Stop and either (a) run the datasheet sync via digikey / mouser / lcsc / element14 (whichever has credentials/stock), (b) populate MPNs on the BOM parts, or (c) state explicitly in the report that every pin-level, electrical, and regulator finding is consistency only — do not use the words "verified", "confirmed", or "per datasheet" anywhere. DS-002 (datasheets missing but MPNs set) and DS-003 (partial MPN coverage) are softer variants with the same implication for the parts they cite.

Design Review Contract

When the user asks for a design review, complete report, ready-to-fab assessment, or anything equivalent, do not stop at running one or two analyzers and summarizing their findings. A design review in this skill has a stricter contract:

1. Read the full workflow in this SKILL.md, not just the analyzer command sections.
2. Read references/report-generation.md before writing the report.
3. Run every applicable analyzer for the files present in the project, then say explicitly which ones were and were not run.
4. Perform raw-file and datasheet cross-verification before claiming anything is "verified".
5. Triage likely analyzer false positives before elevating them into blockers.
6. If a required step could not be done, state it as a review gap, not as silent omission.

Treat this as the minimum bar. Analyzer JSON alone is not the final review.

Minimum Review Checklist

For a full design review, explicitly account for each item below in the report:

• datasheets/ present, synced, or verification gap stated
• analyze_schematic.py
• analyze_pcb.py --full
• cross_analysis.py
• analyze_emc.py
• SPICE simulation when any simulator is installed
• analyze_thermal.py when both schematic and PCB JSON exist
• analyze_gerbers.py when fabrication outputs exist
• lifecycle audit when network access and MPN coverage allow it
• prior review / prior run delta check
• raw schematic/PCB spot-verification elevated to full verification for critical parts
• explicit report sections for blockers, verification basis, false positives, and skipped analyses

If an item is not applicable, say why. If it was skipped, say why. If it failed, say how that limits confidence.

Common Review Failure Modes

These are the failure modes this contract is meant to prevent:

• Stopping after schematic + PCB + EMC output and calling it a complete review
• Reporting analyzer findings without checking whether they are expected layout artifacts
• Claiming "verified" without direct datasheet evidence or structured extraction evidence
• Omitting thermal, lifecycle, prior-review delta, or gerber checks without disclosure
• Writing a report that lacks a verdict, blockers table, verification basis, or skipped-analysis notes
• Reading only the first part of this skill and missing the design-review workflow later in the file

PDF Schematic Analysis

This skill also handles PDF schematics — reference designs, dev board schematics, eval board docs, application notes, and datasheet typical-application circuits. Common use cases:

• Analyze a manufacturer's reference design to understand the circuit
• Extract a subcircuit (power supply, USB interface, sensor front-end) to incorporate into your own KiCad design
• Compare a PDF reference design against your own schematic
• Extract a full BOM from a PDF schematic
• Validate component values in a PDF against current datasheets

Workflow: Read the PDF pages visually → identify components and connections → extract structured data → translate to KiCad symbols and nets → validate against datasheets.

For the full methodology — component extraction, notation conventions, net mapping, subcircuit extraction, KiCad translation, and validation — read references/pdf-schematic-extraction.md.

For deep validation of extracted circuits against datasheets (verifying values, checking patterns, detecting errors), use the methodology in references/schematic-analysis.md.

Analysis Scripts

This skill includes Python scripts that extract comprehensive structured JSON from KiCad files in a single pass. Run these first, then reason about the output.

Read analyzer JSON output directly rather than writing ad-hoc extraction scripts. The JSON schema has specific field names (documented below and in references/output-schema.md) that are easy to get wrong in custom code. To extract a specific section: python3 -c "import json; d=json.load(open('file.json')); print(json.dumps(d['key'], indent=2))".

When the JSON surprises you — an AttributeError, unexpected shape, field returning None that "should" have a value — stop and run --schema before writing a second extraction attempt. It prints the exact field names and types for every top-level key:

python3 /scripts/analyze_schematic.py --schema
python3 /scripts/analyze_pcb.py --schema
python3 /scripts/analyze_gerbers.py --schema

JSON field cheat sheet — the most common mistakes when reading analyzer output by hand:

| What you want | Correct path and field | Common mistake | |---------------|-----------------------|----------------| | Pins on a net | nets[].pins[].component / .pin_number / .pin_name / .pin_type | ref, pin, type, number | | Unnamed-net pretty display | nets[].display_name — when set, a Ref.PinName hint for an __unnamed_N net whose only named IC pin tells the story (e.g. __unnamed_36 → U1.VBOOT). Absent means the analyzer couldn't disambiguate. | Ignoring display_name and pasting raw __unnamed_36 into the report | | IC pin map | ic_pin_analysis[] is a list of IC entries; each has .reference and .pins[] with .pin_number / .pin_name / .pin_type / .net / .connected_to[] | Treating it as {ref: {...}} or pins[].number | | Detected circuits | Every pattern-matched circuit (power regulators, RC filters, crystal oscillators, bridges, …) lives in findings[] — filter with finding_schema.get_findings(data, Det.POWER_REGULATORS) etc. Do not read from subcircuits[]: that's an IC-neighborhood grouping ({center_ic, ic_value, neighbor_components, …}), not a categorized detection index | Looking for subcircuits.power_regulators, subcircuits.rc_filters, or any subcircuits[type] key — these never existed in v1.3 output | | Zone net | pcb.zones[].net is an integer net ID, not a string. Use f"{net!r}" or convert first | f"{net:20s}" — crashes with ValueError: Unknown format code 's' for object of type 'int' | | Footprint position | pcb.footprints[].x / .y at top level (no .position wrapper) | footprints[].position.x | | Findings | findings[] flat list — each has rule_id, detector, severity, summary, report_context. Filter with finding_schema.get_findings(data, Det.*) or group_findings(data) | Looking for keyed dicts like signal_analysis.power_regulators[] (pre-v1.3 format, removed) |

This prevents format-string bugs and wrong field names. Use f-strings or json.dumps() for output formatting — never %s with non-string types. See references/output-schema.md for the full schema with common extraction patterns.

In all commands below, `` refers to this skill's base directory (shown at the top of this file when loaded).

Schematic Analyzer

python3 /scripts/analyze_schematic.py  --analysis-dir analysis/
python3 /scripts/analyze_schematic.py  --analysis-dir analysis/ --compact
python3 /scripts/analyze_schematic.py  --output analysis.json  # one-off, no cache

Outputs structured JSON (~60-220KB depending on board complexity) with:

• Components & BOM: inventory with reference, value, footprint, lib_id, type classification, MPN, datasheet; deduplicated BOM with quantities
• Nets: full connectivity map with pin-to-net mapping, wire counts, no-connects
• Detected subcircuits (pattern-matched circuits — all emitted as findings[] entries with matching Det.* detectors; use get_findings(data, Det.POWER_REGULATORS) etc. to fetch):
• Power regulators — LDO/switching/inverting topology, Vout estimation via datasheet-verified Vref lookup (~60 families) with heuristic fallback and fixed-output suffix parsing, vref_source (lookup/heuristic/fixed_suffix) and vout_net_mismatch fields
• Voltage dividers, RC/LC filters (cutoff frequency), feedback networks, crystal circuits (load cap analysis, IC pin-based detection)
• Op-amp circuits (configuration, gain, integrator/compensator), transistor circuits (net-name-aware load classification: motor/heater/fan/solenoid/valve/pump/relay/speaker/buzzer/lamp; FET level shifter topology)
• Bridge circuits (H-bridge, 3-phase, cross-sheet detection), protection devices (ESD/TVS), current sense, decoupling analysis
• Domain-specific: RF chains, RF matching networks, BMS, Ethernet (BFS PHY-to-connector tracing), HDMI/DVI interfaces, memory interfaces, key matrices (net-name and topology-based), isolation barriers, addressable LED chains (WS2812/SK6812/APA102), battery chargers (TP4056/MCP73831/BQ2404x), motor drivers (A4988/TMC2209/DRV8301), ESD protection coverage audit, debug interfaces (SWD/JTAG with MCU tracing), power path (load switches/ideal diodes/USB PD controllers), ADC signal conditioning (external ADCs + voltage references with anti-aliasing cross-ref), reset/supervisor circuits (voltage supervisors/watchdogs/RC reset networks), clock distribution (clock generators/PLLs/oscillator output tracing), display/touch interfaces (SSD1306/ILI9341/ST7789/FT6236/GT911), sensor fusion (IMU/environmental/magnetometer with interrupt validation and bus clustering), level shifters (IC-based + discrete BSS138 with supply domain mapping), audio circuits (amplifiers/codecs with I2S/class-D detection), LED driver ICs (PWM/matrix/constant-current), RTC circuits (battery backup/crystal pairing), LED lighting audit (current limiting validation), thermocouple/RTD interfaces (MAX31855/MAX31865), power sequencing validation (power tree/enable chain/PG daisy chain analysis)
• IC pinout analysis: pin-level connectivity, IC function classification (3-tier: library prefix, part number keywords, description fallback)
• Power analysis: PDN impedance (1kHz–1GHz with MLCC parasitics), power budget, power sequencing (EN/PG chains), sleep current audit (resistive paths + regulator Iq with EN detection), voltage derating, inrush estimation
• Design analysis: ERC warnings, power domains, bus detection (I2C/SPI/UART/CAN/RS-485 with COPI/CIPO/SDI/SDO), differential pairs (suffix-pair matching for USB/LVDS/Ethernet/HDMI/MIPI/PCIe/SATA/CAN/RS-485), cross-domain signals (voltage equivalence), BOM optimization, test coverage, assembly complexity, USB compliance
• Quality checks: annotation completeness, label validation, PWRFLAG audit, footprint filter validation, sourcing audit, property pattern audit, generic transistor symbol detection (flags QNPN/QPNP/QNMOS/QPMOS_ symbols with datasheet availability check)
• Structural: MCU alternate pin summary, ground domain classification, bus topology, wire geometry, spatial clustering, pin coverage, hierarchical label validation

Supports modern .kicad_sch (KiCad 6+) and legacy .sch (KiCad 4/5). Hierarchical designs parsed recursively.

Legacy format: For KiCad 5 legacy .sch files, the analyzer parses .lib files (cache libraries and project libs) to populate pin data. Pin-to-net mapping, signal analysis, and subcircuit detection all work when .lib files are available. Coverage is typically 92–100% — components whose .lib files are missing (standard KiCad system libs not in the repo) will lack pin data. Built-in fallbacks cover 40+ common symbols (R, C, L, D, LED, transistors, MOSFETs, crystals, switches, polarized caps, connectors up to 20-pin, resistor packs) with mil-based pin offsets and automatic wire-snap correction for version-mismatched pin positions.

Supplementary Data for Legacy Designs

When analyze_schematic.py returns incomplete data (components with missing pins due to unavailable .lib files), use additional project files to recover full analysis capability. The most valuable source is the .net netlist file, which provides explicit pin-to-net mapping that closes any remaining gaps.

For detailed parsing instructions, data recovery workflows, and a priority matrix of supplementary sources (netlist, cache library, PCB cross-reference, PDF exports), read references/supplementary-data-sources.md.

Verify analyzer output against reality. The analyzer can silently produce plausible-looking but incorrect results — wrong voltage estimates, missing MPNs, wrong pin-to-net mappings. These don't cause script errors; they just produce bad data that flows into your report. In testing across multiple boards, every project had at least one misleading analyzer output. Cross-reference against the raw .kicad_sch file:

1. Component count — grep for (symbol (lib_id blocks, subtract power symbols. Must match analyzer count exactly.
2. Pin-to-net mapping — verify the analyzer's pin-to-net mapping against the raw schematic for each component. Read the symbol block, trace wires/labels to confirm connections. Cross-reference IC pin assignments against the manufacturer's datasheet pin table. This is the highest-value verification step — a wrong pin mapping produces a non-functional board and is invisible to DRC/ERC.
3. Physical correctness (not just consistency) — consistency checks (schematic=PCB=analyzer all agree) are necessary but not sufficient. They only confirm the design is internally coherent — not that it matches the real-world part. The most dangerous case: a transistor symbol encodes a pinout assumption (like Q_NPN_BEC = pin 1=B, 2=E, 3=C) that doesn't match the actual part. Everything passes consistency checks, bu

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: aklofas
• Source: aklofas/kicad-happy
• License: MIT
• Homepage: https://github.com/aklofas/kicad-happy

Install and usage instructions live in the source repository linked above.