kicad-tools: Command for Claude Code

Tapeout

Produce a complete, orderable manufacturing package for a routed .kicad_pcb, or refuse and exit non-zero. This skill is the deliverable-completeness counterpart to sign-off: /kct:manufacturing-readiness proves the copper is manufacturable; tapeout proves the package you are about to upload is complete and orderable.

The contract is exactly: tapeout returning 0 (with a manifest written) means "upload this output directory to the fab as-is." Anything less writes no manifest and exits non-zero, naming the gate that failed.

The kct namespace. This skill lives in .claude/commands/kct/ — the kicad-tools-native, harness-agnostic agent-tool namespace, invoked as /kct:tapeout. It runs from inside a consumer repo that depends on kicad-tools as a uv dependency (kct ... and kicad-cli ... are on PATH via the venv). It does not assume the current directory is the kicad-tools repo, and it hardcodes no board path, no fab-tier list, and no CI-workflow context.

Prerequisite

The native router/DRC backend must be built in the active checkout before this skill is meaningful (Epic #4054 convention #1). Run once per checkout / worktree:

uv run kct build-native --check   # expect: "C++ backend: available"
# if "not installed":
uv run kct build-native

uv sync does not build the native extension. A fresh checkout or git worktree needs this step explicitly.

kicad-cli must be on PATH — it is required by both the mandatory DRC cross-gate (Gate 2, delegated) and the drawing-export gates (Gates 5–6). If kicad-cli is missing, tapeout refuses (see Refusal conditions); there is no partial-package fallback.

Model selection

suggestedModel: sonnet. Like /kct:manufacturing-readiness, this is deterministic checklist execution — run gates in order, read exit codes and reports, and refuse on any failure or unresolved BOM line. It does not require frontier judgment.

One open question worth flagging rather than silently resolving: the BOM-resolution gate (Gate 4) can involve a judgment call when the part matcher returns an ambiguous candidate (multiple plausible LCSC parts) rather than a clean hit or a clean miss. This skill treats ambiguity conservatively — an ambiguous line is an unresolved line (human selection required), never an auto-accepted guess — so sonnet remains appropriate. If a future consumer needs the skill to adjudicate ambiguous matches, that is a reason to revisit the model, and it should be raised as a follow-up rather than papered over here.