LTspice → KiCad Workflow

LTspice → KiCad Workflow

A Claude Code skill that takes a power-supply or analog-circuit idea all the way from an LTspice simulation to a verifiable KiCad project — schematic, PCB, footprints, and a clean kicad-cli ERC/DRC pass — while staying honest about what is verified versus inferred.

Distilled from a real 48V → 5V → 1V/10A two-stage µModule design (LTM8064 + LTM4658) and the bugs that surfaced building it.

Packaged as a Claude Code plugin inside a one-plugin marketplace so it installs in two commands.

---

What it does

The skill drives a 9-stage pipeline, gating each stage on a concrete check:

Stage	Output	Gate
1	Specs (V_in, V_out, I_load, protection envelope, layer count)	—
2	Part selection (ADI/LTC µModule demo-board match)	—
3	LTspice schematic (.asc, roles named, .meas lines)	converges
4	Sim validation (vbus_avg, vcore_avg, iload_avg)	within ±2% of spec
5	KiCad generation (symbols, footprints, sch, pcb, netlist)	loads in kicad-cli
6	Hardening pass (cap derating, input protection, 2→4 layer, real BGA pads)	—
7	kicad-cli verification (ERC, DRC, jumper-strip gate)	0 errors, 0 unconnected
8	Structural cross-check (ASC ↔ KiCad nets)	netlist_comparison.py passes
9	Document deferred work (README, verification log)	reality matches reports

The hardening pass and the jumper-strip DRC gate are the parts most naïve "ASC → KiCad" generators skip — they're where a board that looks routed turns out to have 90+ unconnected pads hidden behind virtual jumper flags.

When to use it

• You have (or want to create) an LTspice .asc for an analog/power circuit and intend to fabricate a board.
• You're hardening a prototype-review board for production: cap derating, input protection, layer-count upgrade, real datasheet footprints.
• You want to verify a KiCad project against its source .asc topology.
• You hit "Failed to load board" or DRC violations on a hand-edited .kicad_pcb.

Out of scope: gerber generation as an acceptance artifact, certification / compliance, mechanical/thermal proof, custom IC design, and pure-simulation work (hand off to an LTspice-only skill for that).

Requirements

• KiCad 10.x (the skill drives kicad-cli — paths assume C:\Program Files\KiCad\10.0\bin\kicad-cli.exe on Windows; adjust for your OS).
• LTspice (for stages 3–4).
• Python 3 (for the stage-8 netlist_comparison.py structural diff).

Install

In Claude Code:

/plugin marketplace add swangneu/ltspice-to-kicad-workflow
/plugin install ltspice-to-kicad-workflow@eda-power-skills

Or from the CLI:

claude plugin marketplace add swangneu/ltspice-to-kicad-workflow
claude plugin install ltspice-to-kicad-workflow@eda-power-skills

ltspice-to-kicad-workflow is the plugin name; eda-power-skills is the marketplace name (from .claude-plugin/marketplace.json).

Manual install (no plugin system)

Copy the skill folder into your personal skills directory:

# macOS / Linux
cp -r plugins/ltspice-to-kicad-workflow/skills/ltspice-to-kicad-workflow \
      ~/.claude/skills/

# Windows
Copy-Item -Recurse `
  "plugins\ltspice-to-kicad-workflow\skills\ltspice-to-kicad-workflow" `
  "$env:USERPROFILE\.claude\skills\"

What's inside

.
├─ .claude-plugin/
│  └─ marketplace.json                     # marketplace manifest (root)
├─ plugins/
│  └─ ltspice-to-kicad-workflow/
│     ├─ .claude-plugin/plugin.json         # plugin manifest
│     └─ skills/ltspice-to-kicad-workflow/
│        ├─ SKILL.md                        # the workflow itself
│        └─ references/
│           ├─ netlist_comparison.py         # stage 8 ASC ↔ KiCad structural diff
│           ├─ protection_symbols.kicad_sym  # Fuse + D_TVS symbol snippets
│           └─ four_layer_zones.kicad_pcb_snippet  # In1.Cu / In2.Cu zones
├─ README.md
├─ LICENSE
└─ .gitignore

Honesty model

The skill is explicit about the difference between behavioral evidence ("the values simulate to spec") and structural evidence ("the KiCad net topology matches the ASC"), and treats neither as a substitute for the other. Anything it can't auto-check — e.g. GND-by-convention BGA balls sampled rather than exhaustively verified — gets written into a verification log rather than silently asserted.

License

MIT © 2026 swangneu