copperhead README

The project's README from github.com/copperheadhq/copperhead. As one markdown file: README.md.

copperhead

npm CI license

Cursor for circuit boards. An AI agent that designs, documents, and validates real PCBs from a prompt, working directly on existing KiCad repositories.

copperhead agent shell demo

Status: early. Phase 1 is implemented and the CLI runs. The technical specification is the source of truth; expect the surface to move before 1.0.

Full documentation lives at docs.copperhead.sh.

What it is

An AI product-development agent for hardware: from a product brief to manufacturable files, firmware, and a build plan.

It reads and edits real .kicad_sch / .kicad_pcb files (s-expression text), maintains markdown design docs as memory, propagates every change across all artifacts that reference it, and verifies its own work by running kicad-cli ERC/DRC until the checks pass.

Install

[!TIP] Most users should not install copperhead by hand. If you are working inside an AI coding assistant (like Claude Code, Cursor, or Codex), you can install and configure copperhead automatically for your repository by pasting this single line:

Install copperhead for this repo using https://raw.githubusercontent.com/copperheadhq/copperhead/main/agent-install-prompt.md

If you prefer to install manually:

npm install -g copperhead   # or: npx copperhead check

Bootstrap script (macOS and Linux)

Prefer a one-command setup? install.sh checks the prerequisites below, installs copperhead (globally via npm, or built from source when run inside a checkout), and verifies the result with copperhead doctor:

./install.sh                # interactive: asks before installing anything
./install.sh --yes          # assume yes to the install prompts
./install.sh --check-only   # report what is missing, install nothing

The script is conservative by design: it never runs sudo and never edits shell config; whenever it cannot act safely on its own it prints the exact command for you to run instead. Rerunning is safe: on a ready machine it installs nothing and exits 0.

Requirements

Quick start

In an existing KiCad repository:

export ANTHROPIC_API_KEY=...   # or OPENAI_API_KEY; optional: with no key, `copperhead` offers a model picker
copperhead init                # scaffold docs/ from the schematic; idempotent
copperhead                     # interactive agent shell (Claude Code–style REPL)
copperhead demo --tour          # what the agent does (no LLM)
copperhead demo --model cursor # full USB-C breakout create pipeline
# or one-shot:
copperhead do "add reverse-polarity protection on VIN"
copperhead check               # ERC + DRC + doc drift; no LLM, CI-safe

Starting from nothing instead? Write a product brief and run copperhead create --brief brief.md. The examples/ directory has ready-made briefs sorted by difficulty, plus a note on which one is designed to fail.

Use your existing Codex login

No model API key is needed when Codex CLI is already authenticated:

npm install -g @openai/codex-sdk   # optional adapter, loaded only for --model codex
codex login status
copperhead do "rename net KEY_DAH to KEY_DASH" --model codex

Plain codex follows your Codex model configuration. Use codex:<model-id> for an explicit model. If the executable is not on PATH, set COPPERHEAD_CODEX_PATH=/absolute/path/to/codex. The optional SDK also installs a compatible launcher; for a global install, use COPPERHEAD_CODEX_PATH="$(npm root -g)/@openai/codex/bin/codex.js" as a fallback.

Codex's read-only sandbox prevents native writes but does not confine native reads. Copperhead instructs Codex not to use its own filesystem tools, but the CLI can technically read files such as .env. Codex also keeps session logs under ~/.codex/sessions/; those files are outside Copperhead's transcript-redaction boundary and should be protected according to your local data-retention policy.

How it works

It's a loop, and it looks a lot like pair-programming, except the codebase is a circuit board.

  1. Start from the docs. Every decision lives in the design docs, so the agent reads those first and knows the whole design, not just the part in front of it.
  2. Talk through the change. Describe what you want ("add an external key jack", "cut the sleep current"). The agent proposes the parts and circuit; you push back until the reasoning holds up.
  3. Edit the real files. The agent writes changes straight into the KiCad schematic and the design docs, using the same part names and net names everywhere so nothing drifts.
  4. Propagate. Change one value, like a charge current or a pin, and it carries across every doc and schematic that references it. The boring, easy-to-get-wrong step is the one the agent is best at.
  5. Check the work. The agent runs ERC/DRC, reads the errors back, and fixes them. Nothing is "done" until the tools agree.
  6. Write down why. Every real decision gets a one-line reason next to it, so the next change doesn't quietly undo it.

Two invariants make this trustworthy:

  1. Nothing starts without a spec. The agent cannot touch a KiCad file until a validated change proposal exists; the edit tools are structurally unavailable until it does. Every edit is traceable to a documented intent.
  2. Nothing is "done" until the tools agree. Every file mutation is followed by an ERC/DRC run before the agent reports success.

Spec-gated in, verification-gated out: the design can't drift from its requirements, because drift is a build failure.

CLI

copperhead init [--path hardware/]   # scaffold docs/ from an existing schematic; idempotent
copperhead do "<change request>"     # the core loop: propose, edit, verify, propagate, commit
copperhead skill list                # registered skills (no LLM)
copperhead skill run generate-report # read-only design report (needs a model)
copperhead check                     # ERC + DRC + doc-drift + spec validation; no LLM calls (alias: verify)
copperhead doctor                    # env preflight: node, kicad-cli, git, openspec, provider credential; no LLM/network
copperhead sync [--dry-run]          # verify the whole design state, resolve drift
copperhead create --brief brief.md   # brief → full output package
copperhead export bom --supplier jlcpcb   # supplier-ready ordering file from docs/BOM.md
copperhead mcp                       # EXPERIMENTAL: serve the gated pipeline to MCP hosts over stdio

Global flags: --repo <path> (default: cwd) and --json for machine-readable output. --model is available on do, sync, create, skill run, and doctor; --interactive only on do and create; do also takes --dry-run, --max-turns, and --allow-dirty.

copperhead create still uses its own hardcoded stages; those are not yet skills.

--model accepts gpt-5 (OpenAI), claude / claude-<id> (Anthropic API), claude-code / claude-code:<id> (Claude Code, saved login), cursor / cursor:<id> (Cursor Agent CLI, saved login), and codex / codex:<id> (Codex CLI, saved login). Routing is by prefix; claude-code is matched before the claude prefix. compat:<id> targets any OpenAI-compatible endpoint (Groq, OpenRouter, Gemini, or a local Ollama) via COPPERHEAD_BASE_URL and COPPERHEAD_API_KEY_ENV - worked examples for each in .env.example and the configuration reference.

Saved login (Cursor Agent)

--model cursor drives the Cursor Agent CLI with your saved login from agent login, so you can run copperhead with no OPENAI_API_KEY or ANTHROPIC_API_KEY. Cursor is used purely as a reasoning backend in plan mode: the agent loop, safety gates, and every file edit stay inside copperhead.

agent status
copperhead do "add reverse-polarity protection on VIN" --model cursor

If agent is not on PATH, set COPPERHEAD_CURSOR_PATH to the CLI binary (also available as cursor-agent on some installs). Cursor's JSON schema does not report token usage, so run summaries show 0 tokens for --model cursor.

Saved login (Claude Code)

--model claude-code drives Claude Code through the Claude Agent SDK and reuses your saved login (the CLAUDE_CODE_OAUTH_TOKEN from claude setup-token), so a Claude subscription runs copperhead with no ANTHROPIC_API_KEY. Claude Code is used purely as a reasoning backend: the agent loop, its safety gates, and every file edit stay inside copperhead, identical to the other providers.

claude setup-token                          # while logged into Claude Code
export CLAUDE_CODE_OAUTH_TOKEN=...           # the token setup-token printed
copperhead do "add reverse-polarity protection on VIN" --model claude-code

The Claude Agent SDK ships as an optional dependency, so a normal install pulls it in. copperhead loads it only when you select claude-code, and prints an actionable error if it is missing (for example after npm install --omit=optional), telling you to add it with npm i @anthropic-ai/claude-agent-sdk.

copperhead never reads, copies, or logs the credential; the CLI owns authentication. A missing dependency or an unauthenticated install fails with an actionable message and touches nothing.

Ordering (export bom)

copperhead export bom turns the drift-checked docs/BOM.md into a file a supplier accepts without hand-editing. It is deterministic, LLM-free, and network-free, safe anywhere check is, and it reads BOM.md (never the schematic) so it inherits the drift guarantee; it refuses to export while BOM.md disagrees with the schematic.

copperhead export bom --supplier jlcpcb                 # JLCPCB assembly CSV → outputs/jlcpcb-bom.csv
copperhead export bom --supplier digikey --boards 25    # DigiKey cart CSV, quantities for 25 boards
copperhead export bom --supplier mouser --spares 15     # Mouser cart CSV, 15% spare parts

docs/BOM.md may carry optional Manufacturer and LCSC columns beyond the base Refdes | Value | Footprint | MPN | Rationale; the exporter matches columns by header, so add them when you want them populated in supplier files; init scaffolds the base columns only. Only appending columns is safe: keep Refdes | Value | Footprint first and in that order, because the drift check (check/sync, which the exporter gates on) reads those three by position, so reordering them makes it compare the wrong cells and refuse the export with a spurious drift message.

Nothing is a black box: decisions land in an append-only docs/DECISIONS.md, every run writes a human-readable summary next to its transcript, and a per-run docs/CHANGELOG.md narrates the design history.

MCP server (experimental)

Coding agents are already pointed at KiCad repos through generic file tools, which means a host agent can rewrite a .kicad_sch with no spec gate, no verification, and no rollback. copperhead mcp closes that: it serves the gated pipeline to any MCP host as five opaque, outcome-level tools — copperhead_check, copperhead_do, copperhead_sync, copperhead_init, copperhead_doctor — and nothing finer. There is no file-edit tool, no raw KiCad tool, and no partial-loop tool to reach around, so a host agent cannot skip spec-gating or verification by any sequence of calls.

// .mcp.json
{
  "mcpServers": {
    "copperhead": {
      "command": "copperhead",
      "args": ["mcp", "--repo", "/absolute/path/to/your/kicad/project"]
    }
  }
}

The surface is experimental and unstable. It declares a 0. protocol major: tool names, inputs, and result shapes may change in any release, and there is no registry listing until the stabilization criteria are met. Host configuration for Claude Code and generic stdio hosts, the companion skill, the Codex gap, and those criteria are all in integrations/.

copperhead_check, copperhead_init and copperhead_doctor need no credential; copperhead_do and copperhead_sync with resolve: true refuse with a typed error naming the missing environment variable. The server opens no network transport of its own — stdio only, and LLM calls happen exactly where the CLI already makes them.

What it is not

Simple demo

From a checkout of this repo, run the smallest create-pipeline demo with the USB-C power breakout brief:

npm run demo:simple

The script creates or resumes a git repo at demo-runs/usb-c-breakout/ and runs:

copperhead create --brief examples/simple/usb-c-breakout.md

Pass normal create flags after --, for example npm run demo:simple -- --model claude. If a stage fails, rerun the same command; the demo repo keeps a baseline commit and ignores run transcripts so retries start from the last committed design state.

More briefs, including medium and hard tiers, live in examples/.

Maturity

Honest read of where the current release stands, so you can calibrate before pointing this at a board you care about:

Open source

The entire tool (agent core, prompts, tools) is public under Apache-2.0, built on an open stack (KiCad, kicad-cli, OpenSpec). Everything it produces is plain markdown and JSON in your own repo: no proprietary formats, no lock-in. This is a Chouhan Industries project, and the same commitment that puts every hardware schematic in public applies to the tool that designs them.

Contributing

Contributions are welcome; see CONTRIBUTING.md for setup and workflow. Note that your first pull request requires signing the Contributor License Agreement; a bot posts instructions on the PR and signing is a one-time comment.

Project layout

License

Apache-2.0

copperhead (copperheadhq/copperhead)

Searching Database…

这是做什么用的?Copperhead 是一个面向硬件产品开发的 AI 智能体:你给它一份自然语言写的产品需求,它会生成电路原理图、PCB 布局、可投产的 Gerber 文件、固件脚手架和一份制作计划,并且直接在你的 KiCad 项目里工作。
它是取代 KiCad,还是和 KiCad 配合使用?它是一个命令行智能体,不是新的编辑器:它把你的 .kicad_sch/.kicad_pcb 文件当作文本直接读写,用 markdown 设计文档作为自己的记忆,把每一处修改同步到所有引用它的文件,并通过运行 kicad-cli 的 ERC/DRC 检查来验证自己的修改,直到全部通过为止。
怎么安装和运行?大多数用户会把一行安装提示词粘贴到 AI 编程助手(Claude Code、Cursor、Codex)里完成安装。如果手动安装,运行 install.sh,它会检查环境依赖,通过 npm 全局安装 copperhead(也可以在源码目录里自行编译),最后用 'copperhead doctor' 验证结果。
运行之前需要准备什么?支持哪些 AI 后端?你需要 Node.js 20+ 和 KiCad 8+(kicad-cli 要在 PATH 里),另外还需要一个模型后端:已登录的 Codex CLI、已登录的 Cursor Agent CLI、已登录的 Claude Code,或者配置 ANTHROPIC_API_KEY/OPENAI_API_KEY。
能直接用在我在意的那块板子上吗?不能——项目明确处于早期阶段:第一阶段已经实现,命令行也能跑起来,但规格文档(spec)仍然是唯一依据,接口在 1.0 正式发布前预计还会变动。智能体的循环逻辑本身已经完成,但它的验收测试还没在真实模型上完整跑通过。
能在 Windows 上运行吗,还是只支持 Mac/Linux?初始化安装脚本只针对 macOS 和 Linux,但 copperhead 本身也能在 Windows 上运行,并且会自动检测 Windows 上 KiCad 的常见安装位置。
用 Codex 后端会泄露我本地的文件吗?Codex 的沙箱只拦截写入、不拦截读取,所以命令行工具在技术上能读取 .env 这类文件;而且 Codex 会在 Copperhead 的对话脱敏边界之外保留自己的会话日志——这些日志应当按照你自己的数据保留策略来处理。
copperhead 明确不做什么?它不是自动布线器(布线仍然由人来完成或另行委派),不是替代编辑器(你的 KiCad 仍然是编辑器),也不是最终担责的工程师——必须由人来签字确认,因为它只能保证设计'ERC/DRC 检查通过',而不能保证可以直接投产。
BOM 导出给供应商是怎么工作的?copperhead export bom 会读取经过漂移校验的 docs/BOM.md(从不直接读原理图),并生成适合 JLCPCB、DigiKey 或 Mouser 下单的订单文件;如果 BOM 和原理图不一致,它会拒绝导出。
实验性的 MCP 服务器是做什么用的?copperhead mcp 会向任何 MCP 宿主开放五个受管控的、面向结果的工具(check、do、sync、init、doctor),让宿主里的编程智能体可以使用由规格管控的完整流程,而不用拿到能绕过验证的原始文件编辑工具。
如果智能体把设计改坏了会怎样?每一次文件修改都在一个 git 快照里进行,如果 ERC/DRC 验证没通过会自动回滚,所以最坏情况也只是一个没有任何改动的提交,而不是一份被改乱的原理图。
Size
71.4 MB
Stars
597
Age
3mo
Commits · 90 Days