/kicad-review

name: kicad-review
description: |
  Design review and validation workflow for KiCAD projects via MCP tools. Triggers on: "review my design",
  "check for errors", "audit", "DRC", "ERC", "find problems", "design review", "is this ready",
  "validate", "check my schematic", "check my PCB", "what's wrong", "run checks", "pre-fab review".
argument-hint: "[what to review]"

KiCAD Design Review & Validation Workflow

This skill guides Claude through systematic design review of a KiCAD project using MCP tools. ALL checks are performed through MCP tools — never parse .kicad_sch or .kicad_pcb files directly.

---

Toolset Loading

Load the required toolsets for design review:

load_toolset('sch_analysis')     # find_orphan_items, find_shorted_nets, find_single_pin_nets
load_toolset('verification')     # run_drc, check_clearance, get_design_rules
load_toolset('sch_export')       # run_erc
load_toolset('pcb_export')       # get_drc_violations
load_toolset('manufacturing')    # validate_for_manufacturing
load_toolset('design_review')    # audit_decoupling, audit_connections, audit_power_rails, etc.

Optional (for deeper analysis):

load_toolset('sch_analysis')     # get net info, trace connections, inspect components
load_toolset('pcb_routing')      # query_traces, get_nets_list

Always call `get_active_toolsets()` first to see what is already loaded.

Evidence hierarchy

Judge findings in this order:

1. Exact design requirements and manufacturer datasheets. 2. Direct KiCad ERC/DRC and saved or exported connectivity. 3. Direct Konnect net, short, pad, trace, via, unrouted, and inventory evidence. 4. Aggregate review and manufacturing summaries. 5. Heuristic orphan, single-pin, decoupling, protection, and best-practice findings.

A weaker finding may ask a question; it does not override stronger contradictory evidence. Any required check that did not run, returned impossible coverage, or remains inconsistent with stronger evidence makes the verdict `INCOMPLETE`.

DRC violation items carry `owner` and `ownership_status`. That is direct evidence, not a heuristic: `owner.kind: "footprint"` means the offending geometry belongs to `owner.reference`'s own artwork, so the remedy is a footprint or rule change rather than a placement change — the finding itself stands either way. When `ownership_status` is not `"resolved"`, ownership is unknown and `owner` is `null`; corroborate with `list_board_footprint_graphics` rather than assuming the board owns it.

References by review branch

• Read [`references/design-checklist.md`](references/design-checklist.md) for a

comprehensive or pre-fabrication review. Mark an item only from evidence collected in this run.

• Read [`references/error-taxonomy.md`](references/error-taxonomy.md) when

classifying a finding or assigning the final verdict. Direct ERC, DRC, and connectivity evidence outrank heuristic classifications.

---

Quick Checks (Escalating Severity)

Run these first — they are fast and catch the most critical issues.

Level 1: Structural Integrity

find_orphan_items()

Finds floating wires, labels, and symbols not connected to anything. Treat the result as a heuristic candidate list and corroborate it with direct connectivity or ERC before calling an item a defect.

Level 2: Critical Net Issues

find_shorted_nets()

Detects nets that are connected together but should not be. A shorted net means:

• Two different net labels on the same wire
• Power rails bridged unintentionally
• Signal nets merged by accident

A confirmed unintended short is critical. Resolve disagreement with requirements or direct ERC/connectivity evidence before assigning severity.

Level 3: Suspicious Connections

find_single_pin_nets()

A one-pin net is a heuristic review candidate:

• Incomplete wiring (forgot to connect the other end)
• Orphan net labels (typo in name, so it does not match)
• Leftover stubs from deleted components

---

Formal Checks

ERC — Electrical Rules Check

run_erc()

Checks schematic-level rules:

• Pin type conflicts (output driving output, unconnected inputs)
• Power pin connections
• Missing no-connect flags
• Duplicate reference designators
• Missing net connections

Review each violation. Some can be waived (e.g., intentional unconnected pins marked with no-connect flag).

DRC — Design Rules Check

get_drc_violations()

Checks PCB-level rules:

• Clearance violations (copper-to-copper, copper-to-edge)
• Minimum trace width violations
• Minimum drill size violations
• Unrouted connections (incomplete routing)
• Zone fill issues
• Courtyard overlaps

**Every DRC error must be resolved or explicitly justified before manufacturing.**

---

Design Audits

These go beyond rule checking — they evaluate design quality and best practices.

The standalone schematic audits and `check_bom_health` default to the supplied file only. When the supplied file is a hierarchy root, pass `schematic_scope: "hierarchy"` to cover every reachable sheet instance. Read `status`, `coverage`, and `diagnostics` before interpreting a hierarchy result; missing or cyclic child references make the result incomplete. Reused child files have one result per KiCad sheet instance, identified by the `sheet_instance_path` response field.

Decoupling Audit

audit_decoupling(schematic, schematic_scope="hierarchy")

Checks:

• Every IC power pin has a bypass capacitor
• Capacitor is placed close to the pin (PCB proximity)
• Appropriate capacitor values (100nF ceramic minimum)
• Bulk capacitance present for high-current ICs

Connection Audit

audit_connections(schematic, schematic_scope="hierarchy")

Checks:

• All expected connections are made
• No nets with unexpected fan-out
• Signal integrity basics (termination on long traces)
• Pull-up/pull-down resistors where required (I2C, reset pins, enable pins)

Power Rail Audit

audit_power_rails(schematic, schematic_