KiCad Project Analysis Skill

Disambiguation: This skill analyzes existing KiCad files (.kicad_sch, .kicad_pcb). For a new design use circuit-weaver; use design-wizard only when explicitly requested. For sourcing use bom; run the Circuit Weaver simulate command for supported simulation.

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)
jlcpcb	PCB fabrication & assembly ordering
pcbway	Alternative PCB fabrication & assembly

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 for part searches and datasheet fetching. Hand off to jlcpcb/pcbway for fabrication ordering and DFM rule validation.

Design readiness check: When a user asks "is this ready to order", "check my design", or wants a pre-fab review and a design.yaml exists, run the confidence dashboard:

python -m circuit_weaver confidence design.yaml --run-sims -o confidence_report.html

This aggregates validation, simulation, thermal, DFM, ERC, and cross-reference checks into a single 0-100 readiness score.

Durable Project Intake

For a KiCad project/file, PCB, Gerber/drill directory, or ZIP, start with the non-destructive Circuit Weaver lifecycle instead of producing ad-hoc analyzer JSON with no restart state:

circuit-weaver import-design "${SOURCE_PATH}" --analyze
circuit-weaver status "${PROJECT_ROOT}"
circuit-weaver resume "${PROJECT_ROOT}"

Read project_root, manifest, analysis_status, and next_actions from the import JSON. Source files are inventoried and hashed, not regenerated. ZIPs are safely staged inside .circuit-weaver; analysis results are fingerprinted and committed under .circuit-weaver/analysis/index.json.

For a later pass, reuse unchanged cached results:

circuit-weaver analyze-design "${PROJECT_ROOT}"

Use --force only to intentionally replace a changed import source set/ZIP stage or invalidate cached analysis. Netlist-only imports remain inventoried but report analysis as unsupported because they contain neither schematic presentation nor physical layout evidence. resume prints a plan and never executes it.

For Gerber intake, import the directory or ZIP as a unit so copper, mask, silkscreen, outline, drill, and job files can be assessed together. Treat declared X2 same-coordinate metadata as alignment evidence; when neither X2 metadata nor sufficient geometry establishes alignment, report unknown rather than failure or a false pass.

Use the direct scripts below for deeper one-off options or as a fallback when the lifecycle CLI is unavailable. Do not let direct output replace the durable analysis index silently.

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 with the Read tool rather than writing ad-hoc extraction scripts. The JSON schema has specific field names (documented below) that are easy to get wrong in custom code. To extract a specific section: python -c "import json; d=json.load(open('file.json')); print(json.dumps(d['key'], indent=2))".

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

Schematic Analyzer

python <skill-path>/scripts/analyze_schematic.py <file.kicad_sch>

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
• Signal analysis (automated subcircuit detection):
  • Power regulators — LDO/switching/inverting topology, Vout estimation via datasheet-verified Vref lookup (~60 families) with heuristic fallback, vref_source and vout_net_mismatch fields
  • Voltage dividers, RC/LC filters (cutoff frequency), feedback networks, crystal circuits (load cap analysis)
  • Op-amp circuits (configuration, gain), transistor circuits (net-name-aware load classification: motor/heater/fan/solenoid/valve/pump/relay/speaker/buzzer/lamp)
  • Bridge circuits (H-bridge, 3-phase, cross-sheet detection), protection devices (ESD/TVS), current sense, decoupling analysis
  • Domain-specific: RF chains, BMS, Ethernet, memory interfaces, key matrices, isolation barriers
• 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 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, PWR_FLAG audit, footprint filter validation, sourcing audit, property pattern audit, generic transistor symbol detection (flags Q_NPN_/Q_PNP_/Q_NMOS_/Q_PMOS_ 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 limitations: For KiCad 5 legacy .sch files, the analyzer provides component and net extraction only — no pin-to-net mapping, no signal analysis, no subcircuit detection. When signal analysis is missing from the output, use supplementary data sources to fill the gaps — see the section below.

Supplementary Data for Legacy Designs

When analyze_schematic.py returns incomplete data (typically legacy .sch format — missing pin-to-net mapping, signal analysis, and subcircuit detection), 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 the signal analysis gap entirely.

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, but the board is wrong. To catch this:
   • For transistors (BJT/MOSFET) in SOT-23, SOT-223, TO-252 and similar packages, the KiCad lib_id suffix encodes a pin ordering assumption. SOT-23 BJTs exist in at least 6 pinout variants (BEC, BCE, EBC, ECB, CBE, CEB); SOT-23 MOSFETs in GDS, GSD, SGD, DSG. If no MPN is specified, there's no way to verify the assumption — flag this as a critical ambiguity.
   • When an MPN is specified, verify the symbol's pin-to-pad assignment against the datasheet's pinout diagram for that specific package.
   • This principle extends beyond transistors — any component where multiple pin orderings exist for the same package (voltage regulators with different pin assignments, connectors with vendor-specific pinouts) needs MPN-level verification.
   • When verification isn't possible, assess plausibility. Not all unverified choices carry equal risk. Some align with strong conventions (the most common SOT-23 NPN pinout is BCE; 2N2222 in SOT-23 is almost always BCE); others go against convention or are genuinely ambiguous (SOT-23 MOSFETs have no dominant standard). When an MPN is missing and you can't verify, use domain knowledge — typical pinouts for that device type and package, manufacturer conventions, what the majority of parts in that category do — to assess whether the assumed pinout is likely correct, unusual, or a coin flip. Report the confidence level: "matches the most common convention" is different from "could go either way." This same reasoning applies to passive values (is 4.7kΩ a typical pull-up value for this bus?), circuit topologies (is this a standard application circuit?), and component selection (is this part commonly used for this purpose?).
4. Net trace — trace power rails and critical signal nets end-to-end through wires/labels. Verify the analyzer's pin list is complete for each net.
5. Regulator Vout — check the vref_source field. "lookup" means datasheet-verified (~60 families); "heuristic" means it's a guess that needs manual verification. The vout_net_mismatch field flags estimated Vout differing >15% from the output rail name voltage.
6. Hierarchical connectivity — on multi-sheet designs, verify sub-sheet connections are reflected in the net data.

See references/schematic-analysis.md Step 2 for the full verification checklist. If the script fails or returns unexpected results, see references/manual-schematic-parsing.md for the complete fallback methodology.

PCB Layout Analyzer

python <skill-path>/scripts/analyze_pcb.py <file.kicad_pcb>
python <skill-path>/scripts/analyze_pcb.py <file.kicad_pcb> --proximity  # add crosstalk analysis

Outputs structured JSON (~50-300KB depending on board complexity) with:

• Core: footprint inventory (pads, courtyards, net assignments, extended attrs, schematic cross-reference), track/via statistics, zone summaries, board outline/dimensions, routing completeness
• Zones & copper presence: zone outline vs filled polygon bounding boxes, fill ratio, cross-layer copper presence at every pad (which components have zone copper on the opposite layer and which don't), same-layer foreign zone detection
• Via analysis: type breakdown (through/blind/micro), annular ring checks, via-in-pad detection, BGA/QFN fanout patterns, current capacity, stitching via identification, tenting
• Signal integrity: per-net trace length, layer transition tracking (ground return paths), trace proximity/crosstalk (with --proximity)
• Power & thermal: current capacity per net, power net routing summary, ground domain identification (AGND/DGND), zone stitching via density, thermal pad detection and via counting
• Manufacturing: placement analysis (courtyard overlaps, edge clearance), decoupling cap distances, DFM scoring (JLCPCB standard/advanced tier), tombstoning risk (0201/0402 thermal asymmetry), thermal pad via adequacy, silkscreen documentation audit

Add --full to include individual track/via coordinates. Supports KiCad 5 legacy format.

Zone fills must be current. The copper presence analysis uses KiCad's filled polygon data, which is computed when the user runs Edit → Fill All Zones (shortcut B) and stored in the .kicad_pcb file. If the board was modified after the last fill, the filled polygon data may be stale and the copper presence results will be inaccurate. When reviewing copper presence data, note whether the fill_ratio seems reasonable — a zone with 0 filled area or is_filled: false likely hasn't been filled.

Zone outline ≠ actual copper. The zone outline_bbox is the user-drawn boundary; filled_bbox is where copper actually exists after clearances, keepouts, and priority cuts. The copper_presence section shows which components have zone copper on the opposite layer — use this for capacitive touch pad isolation, antenna keep-out, and thermal analysis instead of inferring copper presence from zone outlines.

Verify after every run: Confirm footprint count and board outline dimensions against the raw .kicad_pcb file. Verify pad-to-net assignments for IC footprints against the schematic's pin-to-net mapping — this catches library footprint errors where pad numbering doesn't match the symbol pinout. If the script fails, see references/manual-pcb-parsing.md for the fallback methodology.

Gerber & Drill Analyzer

python <skill-path>/scripts/analyze_gerbers.py <gerber_directory/>

Outputs: layer identification (X2 attributes), component/net/pin mapping (KiCad 6+ TO attributes), aperture function classification, trace width distribution, board dimensions, drill classification (via/component/mounting), layer completeness, alignment verification, pad type summary (SMD/THT ratio). Add --full for complete pin-to-net connectivity dump. ~10KB JSON.

If the script fails or returns unexpected results, see references/manual-gerber-parsing.md for the complete fallback methodology for parsing raw Gerber/Excellon files directly.

All scripts output JSON to stdout by default. Use --output file.json to write to a file, --compact for single-line JSON.

Analyzer JSON is worth keeping — these are expensive to regenerate (large schematics take time). Use --output to save them for multi-pass analysis. They're not worth committing to git, but don't delete them between analysis steps.

Generated Files

The analysis workflow creates files in the project tree. Analyzer JSON and design review reports use user-chosen filenames, so track what you create:

1. Tell the user what files were created and where
2. Record them in the project's AGENTS.md or equivalent agent-rules file under a "Generated files" section (create one if needed) so future sessions can find or clean them up
3. When the user asks to clean up, remove generated reports and analyzer JSON. Check AGENTS.md or the equivalent agent-rules file for the file list — filenames vary per session.

File Type	Example	Regenerable?	Commit to git?
Analyzer JSON (--output)	schematic_analysis.json	Yes (expensive)	No
Design review report	review.md, power_tree_review.md	Yes	Optional — user may want to keep for reference

See also the bom skill's cleanup section for datasheets, order CSVs, and backups.

Output JSON Schema Quick Reference

Schematic analyzer top-level keys:

file, kicad_version, file_version, title_block, statistics, bom, components,
nets, subcircuits, ic_pin_analysis, signal_analysis, design_analysis,
connectivity_issues, labels, no_connects, power_symbols, annotation_issues,
label_shape_warnings, pwr_flag_warnings, footprint_filter_warnings,
sourcing_audit, ground_domains, bus_topology, wire_geometry,
simulation_readiness, property_issues, placement_analysis, hierarchical_labels

Optional (present when non-empty): text_annotations, alternate_pin_summary, pin_coverage_warnings, instance_consistency_warnings, pdn_impedance, sleep_current_audit, voltage_derating, power_budget, power_sequencing, bom_optimization, test_coverage, assembly_complexity, usb_compliance, inrush_analysis, sheets

Key nested structures:

• statistics: {total_components, unique_parts, dnp_parts, total_nets, total_wires, total_no_connects, component_types, power_rails, missing_mpn, ...}
• bom[]: {reference, references[], value, footprint, mpn, manufacturer, datasheet, quantity, dnp, ...}
• components[]: {reference, value, footprint, lib_id, type, mpn, datasheet, dnp, in_bom, parsed_value, ...}
• nets{net_name}: {pins[], wires, labels[], ...} — each pin: {component, pin_number, pin_name, pin_type, ...} (NOT ref or pin)
• signal_analysis: {power_regulators[], voltage_dividers[], rc_filters[], opamp_circuits[], transistor_circuits[], bridge_circuits[], crystal_circuits[], current_sense[], decoupling_analysis[], protection_devices[], buzzer_speaker_circuits[], design_observations[], ...}

PCB analyzer top-level keys:

file, kicad_version, file_version, status, kicad_verified,
verification_status, verification_reason, statistics, layers, setup, nets,
board_outline, component_groups, footprints, tracks, vias, zones,
connectivity, net_lengths, source_generator, routing_assessment

Optional: power_net_routing, decoupling_placement, ground_domains, current_capacity, thermal_analysis, layer_transitions, placement_analysis, silkscreen, dfm, board_metadata, dimensions, groups, net_classes, tombstoning_risk, thermal_pad_vias, copper_presence, trace_proximity

Key nested structures:

• net_lengths is a list (not dict): [{net, net_number, total_length_mm, segment_count, via_count, layers{}}, ...] sorted by length descending
• power_net_routing is a list: [{net, track_count, total_length_mm, min_width_mm, max_width_mm, widths_used[]}, ...]
• footprints[]: {reference, value, footprint, layer, pads[], sch_path, sch_sheetname, sch_sheetfile, connected_nets[], ...}
• statistics: {footprint_count, copper_layers_used, smd_count, tht_count, zone_count, via_count, routing_complete, ...}
• routing_assessment: {status, classification, routable, review_only, workflow, placement_preview, routing_complete, routing_status, pad_count, routable_net_count, has_copper, copper_item_count, source_generator, kicad_verified, verification_status, verification_reason, reason}. Treat review_only: true, routing_status: incomplete, or verification_status: unverified as a hard stop for verified-routing claims; Circuit Weaver placement previews intentionally have no authoritative pads. This analyzer performs static parsing, not a kicad-cli load or DRC check.

Gerber analyzer top-level keys:

statistics, completeness, alignment, drill_classification, pad_summary,
board_dimensions, gerbers, drills

Workflow: When analyzing a KiCad project, scan the project directory for all available file types and run every applicable analyzer — not just the one the user mentioned. A complete analysis uses all the data available:

1. Scan the project directory for .kicad_sch, .kicad_pcb, .kicad_pro, gerber directories, and .net/.xml netlist files
2. Run all applicable scripts — if the schematic exists, run analyze_schematic.py. If the PCB exists, run analyze_pcb.py. If gerbers exist, run analyze_gerbers.py. Run them in parallel when possible.
3. Sync datasheets (see Datasheet Acquisition below) — datasheets are required for proper verification, not optional. Get them before proceeding to verification.
4. Read the .kicad_pro project file directly (it's JSON) for design rules, net classes, and DRC/ERC settings
5. Cross-reference outputs between schematic and PCB (see section below) — this catches the most dangerous bugs (swapped pins, missing nets, footprint mismatches)
6. Verify each output against the raw files and datasheets before using the data in your report
7. Produce a unified report covering schematic analysis, PCB layout analysis, and cross-reference findings. See references/report-generation.md for the report template.

The more data sources you combine, the more confident the analysis. A schematic-only review misses layout issues; a PCB-only review misses design intent. Always use everything available.

Analysis Depth

Default to thorough analysis unless the user asks for a quick review. The reason: the bugs that kill boards are the ones that look correct at a glance. A spot-check might confirm 5 ICs are correct while the 6th has pins 3 and 4 swapped — and that's the one that kills the board. Thoroughness principles:

• Verify all components, not a sample. Pin-to-net errors on "simple" parts (reversed diode, wrong resistor in a divider, connector with wrong pin ordering) are just as fatal as swapped IC pins. Cover the full design.
• Use datasheets as ground truth. The analyzer and raw schematic tell you what the design says — the datasheet tells you what it should say. A library symbol with a wrong pin mapping is the most dangerous class of bug precisely because the design is internally consistent. See "Datasheet Acquisition" below.
• Assess plausibility, not just verifiability. When something can't be verified (missing MPN, missing datasheet), don't stop at "unverified." Use domain knowledge to assess whether the design choice aligns with common conventions or looks unusual. A 10kΩ I2C pull-up is unremarkable; a 100Ω I2C pull-up warrants a closer look even without a datasheet to check against. An SOT-23 NPN with BCE pinout matches the most common convention; one with CEB is unusual enough to flag. The goal is to distinguish "unverified but probably fine" from "unverified and suspicious." This applies to pinouts, passive values, circuit topologies, and component selection.
• Think beyond what the analyzer detects. The analyzer only finds patterns it's programmed for. When a section has no automated data, consider whether that's because the design doesn't need it (fine — say so briefly) or because the analyzer can't detect it (reason about it manually). Not every section needs a paragraph — "Not applicable: battery-powered, no mains input" is sufficient. But don't let empty data create blind spots in areas that matter for the specific design.

Datasheet Acquisition

Datasheets are what separate a consistency check from a correctness check. Without them, you can confirm the design agrees with itself — but not that it matches the real-world parts. Obtain datasheets early in the workflow.