AI-CAD：面向机械工程 CAD 的开源多 Agent 编排框架

AI-CAD 是你委托执行任务的一整个自主工程部门，

AI-CAD 不是一个需要你亲自操作的 CAD 建模工具。

只需提供一份自然语言需求说明或一张手绘草图，一支由 LLM Agent 组成的团队就能交付真实、可制造的零件和装配体：

• 规划：确定机器方案，并将其拆解为零件
• 编写：参数化 CadQuery Python 代码
• 渲染：将每个零件渲染为工程视图，并查看这些视图
• 评审：依据面向制造的设计和面向装配的设计规则审查几何结构
• 修复：持续修正并重新评判，直至设计通过审查并实现你的意图

Agent 会查看自己构建的内容，并围绕它展开争论，直至设计通过审查并实现你的意图

这一切均可在你选择的编码 Agent 中交互式完成，并可通过实时仪表盘查看全过程。

每次运行都会写出一个简单的文件目录；你可以像管理任何工程记录一样读取、比较差异并进行版本控制。

系统没有服务器，也没有数据库。AI-CAD 构建在你的编码 Agent之上。

你的工程部门正在工作：随着 Agent 交付成果，零件陆续出现、判定结果陆续发布，活动瀑布流实时追踪每个 Agent。

---

指导性设计原则

系统拒绝给出与设计意图和机器目标相矛盾的
泛化制造建议。

（参见那次“反驳回来”的运行。）

将机器组件设计为有状态的 Python 代码（而非不可变的网格道具）

与大多数生成网格模型的文生 3D 工具不同
（这些工具很适合游戏资产和概念设计），

AI-CAD 编写参数化 CAD 代码：
每个零件都是一个具有命名尺寸的 Python 程序，

可导出机加工车间或下游 CAD 系统接受的 STEP 和 STL 文件。



一套 DFM/DFA 规则手册会为每项设计评分；
会使评分变差的修复提案，将被带有完整可追溯性的回归门禁自动拒绝。



每个零件和装配体都会被渲染为 8 个工程视图
（前视 / 顶视 / 右视 / 等轴测，分别提供线框和清晰两种风格）。

具备视觉能力的评估 Agent 会查看这些渲染图：
几何结构从工程视角接受评判，而不只是被执行。



标准 Agent、技能和工具内容统一存放在 `.shared/` 中；
每个编排框架（`.claude/`、`.opencode/`）都只是通过符号链接连接的轻量外壳。



每次运行都会写出一个自描述项目目录：
目标、设计日志、各零件几何文件、协商记录、反思记录。
每个零件都会导出 STEP 和 STL。
没有用于隐藏事实的不透明数据库：
前端、回放和分析功能都读取同一批文件。



几何执行、渲染、DFMA 评估、规格验证、尺寸检查和导出，
都是可由 bash 调用的确定性 Python 工具。

验证独立于任何 LLM 进行。



如果编排 Agent 被终止，或耗尽上下文窗口，
一个新的 Agent 仅凭项目目录就能重建全部状态。

崩溃的运行也是以这种方式恢复：无需检查点数据库。



一次运行会通过写入结构化 `run_reflection.md` 到达终止状态：
其中记录哪些环节失败、运行过程为保护结果做了哪些临时调整，
以及如何让下一次运行变得更聪明。
Agent 遥测交付的是判断，而不只是日志。

完整的架构决策记录及各项决策所拒绝的替代方案位于：

docs/architecture-decision-records/

---

每个零件包含八个视图，并像工程图纸一样接受判断：这是视觉评估器在任何几何文件交付前所看到的内容。

一次设计运行会产出什么

输入一份需求说明，输出一棵自描述的工件目录树。

这是公开案例库中一次真实运行的目录树：一个在上止点位置设计的内燃机核心：

piston_crank

projects/piston_crank/
├── goals.md              # 需求说明，扩展为可衡量的成功标准
├── design_plan.md        # 零件、接口、锁定的尺寸链、构建顺序
├── design_log.md         # Agent 逐步构建日志
├── external/             # 目录零件的 BOM 与采购说明
├── assembly/
│   ├── piston/
│   │   ├── part.py       # Agent 编写的 CadQuery 源代码
│   │   ├── renders/      # 评估器查看过的 8 个工程视图
│   │   └── exports/      # piston.step + piston.stl
│   ├── crankshaft/           # ……每个零件均采用相同布局
│   ├── connecting_rod/
│   ├── gudgeon_pin/
│   ├── piston_ring/
│   └── renders/          # 装配机制的多视图渲染图
├── checkpoint.md         # 可选交接说明；恢复时仅根据文件重建状态
└── run_reflection.md     # 本次运行自身的复盘

---

实时仪表盘：观察机器思考

历时 2 小时的自主设计过程被实时追踪：上方是 Agent 瀑布流，下方装配体在四个工程视图中逐渐成形。

一个只读的本地仪表盘可渲染实时运行过程，包括工程图纸、装配协商记录和实时 Agent 活动瀑布流。

cd frontend
npm install
npm run dev
# 打开 http://localhost:5199

开发服务器特意固定使用端口 5199（strictPort）：它绝不会导入编排框架代码，也绝不会写入任何内容；它只读取 projects/。

参见 frontend/README.md。

---

部门成员名单。

每个角色均由一份指令文件定义：

• orchestrator - 运行整个部门。设计上具备抗中断能力：它可以在运行中途终止，继任者仅凭文件即可重建一切。
• planner - 将目标拆解为零件、接口和构建顺序，并标记哪些零件可通过 parallel_safe 并发构建。
• cad_designer - 编写 CadQuery 代码，改编已验证的 cookbook 模式，而不是临时拼凑原始 API 调用。
• validator - 以数值方式解决争议：结构检查和几何测量的优先级高于任何人的意见，包括视觉评估器的意见。
• dfma_inspector - 阅读渲染图，并依据 DFM/DFA 规则手册为设计评分。
• repair - 修复几何结构，但只能通过 part.proposal.py 提交；是否采用修复方案由回归门禁决定。
• assembly_resolver - 将零件装配在一起，并记录零件之间的协商过程。
• sourcing - 选择目录组件并捕捉目录陷阱（例如轴承比假定值薄 1 mm，或螺母标准会导致其超出安装座）。
• reviewer - 给出最终的交付或不交付结论。

Agent 所依赖的知识层。

技能是经过版本管理的文档，你可以准确了解系统“相信”什么。

• cadquery-cookbook - 包含 11 种可复用 CadQuery 模式、8 项设计原则和 6 种反模式；设计器会改编最接近的模式，而不是从原始 API 调用开始组合。
• cadquery-anti-hallucination - 收录 LLM 经常虚构、但实际不存在的 CadQuery 方法；为每个方法提供正确替代方案，并包含执行器使用的运行时错误到提示信息映射表。
• dfm-rules - 面向 Agent 的 DFM/DFA 规则手册摘要：包括每条规则的 ID、严重等级和修复提示，以及评分算法和规则提案 schema。
• run-reflection - 每次运行在终止状态写入的结构化自我复盘，其 schema 和质量标准。
• engineering-handbooks 和 sourcing-tables - 为机械设计手册和组件表预留的占位内容，明确标为暂定，以免任何 Agent 将空白位置误认为权威依据。

系统中确定性的另一半：

可通过 bash 调用的 Python 模块（uv run python -m tools.<name>），用于测量、渲染、评分和导出。

Agent 负责决策；工具负责验证。

• cadquery_executor - 运行生成的 CadQuery 代码；--subprocess 标志会隔离原生 OCCT 崩溃，以免一次错误的内核调用导致整次运行失败。
• renderer - 为每个零件和装配体生成 8 个工程视图（4 个视图乘以 2 种风格），分别输出为独立 PNG 文件。
• dfma_evaluator - 按规则手册为设计评分，并以按严重性加权的评分评判修复提案（严重=10，主要=5，轻微=1）；提高评分的提案会被自动拒绝，并保留完整可追溯性。
• dimension_checker - 基于确定性的包围盒与约束对比进行验证：尺寸必须测量，而不能仅靠声明。
• spec_validator - 扫描项目状态并检查结构化工件；恢复运行时也通过它重建运行进度。
• exporter - 将完成的零件导出为可制造格式（STEP、STL）。
• placeholder_detector - 在任何人将渲染和视觉评估周期花费在某个文件上之前，回答“这个 part.py 是真实设计还是脚手架占位文件？”

DFMA：作为生成零件代码的单元测试套件

DFM/DFA 规则以 JSON 形式存放在 rules/ 中，并配有 .proposed 同级文件和生命周期日志。

规则并非冻结不变的教条：它们可以随时间被提议、晋升或弃用；每一份修复提案都会由 dfma_evaluator 中的回归门禁依据这些规则进行评判。可以将 DFMA 视为零件的单元测试套件。

这一生命周期为何采用当前形态，以及哪些方案被拒绝，参见：决策记录 0007：核心规则生命周期。

---

真实、未经编辑的设计运行记录位于公开案例库：ai-cad-labs/ai-cad-example-projects。每次运行均附带其规格、计划、逐步设计日志、各零件几何文件、多视图渲染图、STEP/STL 导出文件及其自身复盘。其中没有任何几何结构由人工编写。

运行	构建内容	数据	实际耗时
impeller_assembly	根据手绘草图构建的皮带驱动离心压缩机核心（案例研究）	6 个组件（3 个设计件、3 个目录件）· 以五种方式测得 0.8000 mm 间隙 · 6 个 10.5° 后掠叶片 · reviewer 结论：交付	约 2 小时 12 分钟
piston_crank	处于上止点位置的 5 零件内燃机核心	7 实例装配体 · 锁定的尺寸链全程保持有效 · 运行中途自检查点与冷恢复	71.3 分钟
spur_gear	一对相互啮合的渐开线齿轮	确定性啮合证明：在正确的半齿相位下干涉为 0.00 mm³ · 0 次修复循环	约 49.8 分钟
treasure_chest	对照基线：一个由 4 个零件组成的宝箱	13 个 Agent、0 次失败、0 次修复 · 3 项发现经书面理由说明后延期处理	32.8 分钟

案例研究：叶轮装配体：那次“反驳回来”的运行

根据一张手绘草图端到端设计： _一

AI-CAD : An OSS multi-agent harness for Mech. Eng. CAD

AI-CAD is an autonomous engineering department you commission,

AI-CAD is not a CAD modeling tool you operate.

Give it a plain-English brief or a hand-drawn sketch, and a team of LLM agents delivers real, manufacturable parts and assemblies:

• Plans : the machine and decomposes it into parts
• Writes : parametric CadQuery Python code
• Renders : every part to engineering views, and looks at them
• Critiques : the geometry against design-for-manufacturing and design-for-assembly rules
• Repairs : and re-judges until the design survives review and delivers your intent

Agentslooking at what they built, and argue about it until it survives review and delivers your intent

All of this interactively inside your coding agent of choice, and with visibility in a live dashboard.

Every run writes a simple directory of files that you can read, diff, and version like any other engineering record.

There is no server and no database. AI-CAD is built on top of your coding-agent.

Your engineering department at work: parts land as agents deliver, verdicts post, and theactivity waterfall traces every agent in real time.

---

Guiding Design Principles

The system refuses generic manufacturing advice
that contradicts the intent and machine goals.

(See the run that argued back.)

Design machine components as stateful Python code (not immutable mesh props)

Unlike most text-to-3D tools that generate meshes
(excellent for game assets and concept art),

AI-CAD writes parametric CAD code:
every part is a Python program with named dimensions,

exporting STEP and STL that a machine shop or downstream CAD system accepts.



A DFM/DFA rulebook scores each design;
repair proposals that worsen the score are automatically rejected
by a regression gate with full traceability.



Every part and assembly is rendered to 8 engineering views
(front / top / right / iso, in wireframe and clean styles).

A vision-capable evaluator agent sees those renders:
geometry is judged from engineering lenses, not just executed.



Canonical agent, skill, and tool content lives once in `.shared/`;
each harness (`.claude/`, `.opencode/`) is a thin symlinked shell over it.



Every run writes a self-describing project directory:
goals, design log, per-part geometry, negotiation records, reflections.
Exports STEP and STL for every part.
No opaque database for facts to hide behind:
the frontend, replay, and analysis all read the same files.



Geometry execution, rendering, DFMA evaluation, spec validation, dimension checks, and export
are deterministic bash-callable Python tools.

Validation happens independently of any LLM.



If the orchestrator agent is killed, or runs out of context window,
a fresh one reconstructs all state from the project directory alone.

That is also how a crashed run resumes: no checkpoint database needed.



A run reaches terminal state by writing a structured `run_reflection.md`:
what failed, what the run improvised to protect the result,
and what would make the next run smarter.
Agentic telemetry ships judgment, not just logs.

The full set of architecture decision records, with the alternatives each one rejected, lives in

docs/architecture-decision-records/

---

Eight views per part, judged like a drawing sheet: this is what the vision evaluator sees before any geometry ships.

What a Design run produces

One brief in, one self-describing artifact tree out.

This is the real tree of the run in the public gallery, an IC-engine core designed at top-dead-center:

piston_crank

projects/piston_crank/
├── goals.md              # the brief, expanded into measurable success criteria
├── design_plan.md        # parts, interfaces, the locked dimension chain, build order
├── design_log.md         # the agents' step-by-step build log
├── external/             # BOM + sourcing notes for catalog parts
├── assembly/
│   ├── piston/
│   │   ├── part.py       # the CadQuery source the agents wrote
│   │   ├── renders/      # the 8 engineering views the evaluator looked at
│   │   └── exports/      # piston.step + piston.stl
│   ├── crankshaft/           # ... same layout per part
│   ├── connecting_rod/
│   ├── gudgeon_pin/
│   ├── piston_ring/
│   └── renders/          # multi-view renders of the assembled mechanism
├── checkpoint.md         # optional handover note; resume rebuilds from files alone
└── run_reflection.md     # the run's own debrief

---

Live Dashboard : Watch the machine think

2 hours of autonomous design, traced live: the agent waterfall above, the assembly taking shape in four engineering views.

A read-only local dashboard renders live runs: drawing sheets, assembly negotiations, and a live agent activity waterfall.

cd frontend
npm install
npm run dev
# open http://localhost:5199

The dev server is pinned to port 5199 (strictPort) on purpose: it never imports harness code and never writes; it only reads projects/.

See frontend/README.md.

---

The department roster.

Each role is defined by one instructions file

• orchestrator - Runs the department. Mortality-proof by design: it can end mid-run and a successor rebuilds everything from files alone.
• planner - Decomposes a goal into parts, interfaces, and build order, and marks which parts are parallel_safe to build concurrently.
• cad_designer - Writes the CadQuery, adapting proven cookbook patterns instead of improvising raw API calls.
• validator - Settles disputes numerically: structural checks and geometry measurements that outrank anyone's opinion, including the vision evaluator's.
• dfma_inspector - Reads the renders and scores the design against the DFM/DFA rulebook.
• repair - Fixes geometry, but only via part.proposal.py; the regression gate decides whether the fix ships.
• assembly_resolver - Fits the parts together and records the negotiations between them.
• sourcing - Selects catalog components and catches catalog traps (a bearing 1 mm thinner than assumed, a nut standard that would overhang its seat).
• reviewer - The final ship or no-ship verdict.

The knowledge layer the agents draw on.

Skills are versioned documents ,you can read exactly what the system believes.

• cadquery-cookbook - 11 reusable CadQuery patterns, 8 design principles, and 6 anti-patterns; designers adapt the closest pattern rather than composing from raw API calls.
• cadquery-anti-hallucination - A catalog of CadQuery methods that do not exist but LLMs keep inventing, each with the correct alternative, plus the runtime error-to-hint table the executor applies.
• dfm-rules - The agent-readable digest of the DFM/DFA rulebooks: every rule's id, severity, and fix hint, plus the scoring arithmetic and the rule-proposal schema.
• run-reflection - The schema and quality bar for the structured self-debrief every run writes at terminal state.
• engineering-handbooks and sourcing-tables - Reserved stubs for machine-design playbooks and component tables, labeled provisional so no agent mistakes an empty slot for authority.

The deterministic half of the system:

bash-callable Python modules (uv run python -m tools.<name>) that measure, render, score, and export.

Agents decide; tools verify.

• cadquery_executor - Runs generated CadQuery code; a --subprocess flag isolates native OCCT crashes so one bad kernel call cannot take the run down.
• renderer - Produces the 8 engineering views per part and assembly (4 views by 2 styles) as individual PNGs.
• dfma_evaluator - Scores designs against the rulebook and judges repair proposals with severity-weighted scoring (critical=10, major=5, minor=1); proposals that raise the score are auto-rejected with full traceability.
• dimension_checker - Deterministic bounding-box-versus-constraints verification: dimensions are measured, never asserted.
• spec_validator - Project state scanner and structural artifact checks; also how a resumed run reconstructs where it was.
• exporter - Exports finished parts to manufacturable formats (STEP, STL).
• placeholder_detector - Answers "is this part.py a real design or a scaffold stub?" before anyone spends a render and a vision cycle on it.

DFMA as a unit-test suite for generate part code

DFM/DFA rules live as JSON in rules/, with .proposed siblings and a lifecycle log.

Rules are not frozen doctrine: they can be proposed, promoted, or retired over time, and every repair proposal is judged against them by the regression gate in dfma_evaluator. Think of DFMA as a unit-test suite for parts.

How the lifecycle got this shape, and what was rejected: decision record 0007, the central rules lifecycle.

---

Real, unedited design runs live in the public gallery: ai-cad-labs/ai-cad-example-projects. Every run ships its spec, plan, step-by-step design log, per-part geometry, multi-view renders, STEP/STL exports, and its own debrief. No geometry there was human-authored.

Run	What it built	The numbers	Wall clock
impeller_assembly	A belt-driven centrifugal compressor core, from a hand-drawn sketch (the case study)	6 components (3 designed, 3 catalog) · 0.8000 mm clearance measured five ways · 6 backswept blades at 10.5° · reviewer verdict: ship	~2h12m
piston_crank	The 5-part IC-engine core at top-dead-center	7-instance assembly · a locked dimension chain that held end-to-end · mid-run self-checkpoint and cold resume	71.3 min
spur_gear	A meshing involute gear pair	Deterministic mesh proof: 0.00 mm³ interference at the correct half-tooth phase · 0 repair cycles	~49.8 min
treasure_chest	The control baseline: a 4-part chest	13 agents, 0 failures, 0 repairs · 3 findings deferred with written reasoning	32.8 min

Case Study : Impeller Assembly : the run that argued back

Designed end-to-end from a single hand-drawn sketch: a six-component impeller rig assembly, rendered from the design run's assembly geometry.

Details: the impeller_assembly run in the public gallery.

The best argument for the architecture is a run where the system disagreed with its own tooling and was right. Every claim below is on file in the public exhibit:

impeller_assembly.

The input was a hand-drawn cross-section sketch and a five-bullet brief: a belt-driven centrifugal compressor core with backswept blades.

Moments from that run show what a manufacturing gate with judgment looks like:

• The system defended the user's design intent against its own evaluator. Mid-run, the DFM evaluator (judging the wheel under a mis-selected 3-axis milling ruleset) recommended cutting the impeller to 4 blades and straightening them into flat radial walls. That advice would have quietly destroyed exactly what the brief asked for. Both orchestrator generations refused it, recorded the refusal in open_issues.md, and passed an explicit do-not-comply guard downstream so no later agent could obey it by accident.
• The headline requirement shipped as a machined dimension. The brief asked for 0.5 to 1.0 mm of running clearance; the run delivered 0.8000 mm, confirmed by five independent measurements and realized structurally in a part, not left to an assembly stack-up that can drift.

User intent held as a first-class constraint, not one voice in a negotiation the tooling usually wins. The full record, refusals included, is public and unedited:

6 STEP/STL exports, fourteen agent spawns across 2 sessions, roughly 2h12m of autonomous work, one repair cycle, reviewer verdict: ship.

The complete provenance chain, from sketch to brief to per-part geometry to the run's own debrief, is public: impeller_assembly run_reflection.md.

Read the full exhibit | Browse all runs

---

Get Exploring : Quickstart

Harness and platform support

Platform	Linux	macOS	Windows
AI-CAD	✅	✅	✅ *

The repo depends on in-repo symlinks.

Clone with git clone -c core.symlinks=true (Developer Mode or admin rights)

Or work inside WSL

Harness	Status	Notes
Claude Code	✅ Supported (default)	The claude CLI carries its own authentication
OpenCode	🚧 In progress	The .opencode/ symlinked shell ships; the parallel build is open work
Other harnesses	🗺️ Planned	.shared/ holds all canonical content, so a new harness is a thin adapter

• Python 3.13+ and uv (dependency + venv manager).

• Claude Code , the default harness. No API keys and no .env: the claude CLI carries its own authentication.

• cairo : the renderer converts SVG to PNG via cairosvg, which needs the system cairo library. macOS: brew install cairo (the renderer auto-sets DYLD_FALLBACK_LIBRARY_PATH for Homebrew). Debian/Ubuntu: apt-get install libcairo2.

• Windows : clone with git clone -c core.symlinks=true (requires Developer Mode or admin rights), or work inside WSL. The repo relies on in-repo symlinks (tools, .claude/agents, .claude/skills point into .shared/); a default Windows clone materializes them as plain text files, which breaks Python imports and agent discovery.

  git clone https://github.com/ai-cad-labs/ai-cad.git cd ai-cad uv sync # creates .venv and installs the tool layer uv run pytest -q # ~163 tests should pass: confirms the CAD/DFMA engine works

Open the repo in Claude Code and prompt as such:

create a project with a `goals.md` for <YOUR IDEA>
and dispatch the orchestrator to design it to completion.

Watch projects/<name>/ fill in as the agents work, or open the live dashboard. The filesystem is the source of truth: goals, design plan, per-part CadQuery source, renders, measurements, exports.

Relaunch with an entry prompt that says RESUMING and names the project directory; the fresh orchestrator reconstructs state from the files alone.

---

AI-CAD writes CadQuery, the parametric Python CAD system that makes code-as-geometry possible. Rendering goes through cairosvg and the system cairo library. The default harness is Claude Code, and the dashboard stands on Vite, React, and Tailwind.

• Questions and problems : open an issue on github.com/ai-cad-labs/ai-cad.
• "What should healthy output look like?" : study a complete run in the run gallery before changing pipeline behavior.
• Conventions and internals : AGENTS.md is the canonical map for anyone (human or agent) working in the repo.
• Why the system is built this way : docs/README.md indexes the documentation layer: the glossary of domain language and the architecture decision records that carry each design decision and the alternatives it rejected.
• CadQuery itself : the reference/ directory ships five distilled CadQuery reference documents, which are all the system needs at runtime. For deeper work, docs/dev/local-setup.md lists the nine upstream CadQuery ecosystem repos worth cloning locally.

Contributions are welcome, and we want you to feel welcome making them.

You do not need to be a CAD veteran or a machine-learning engineer to have a big impact: documentation, DFM/DFA rule improvements, gallery runs, and issue reports all move the project forward.

Channel	Best for
Issues	Bugs and defects
Discussions	Show your runs, ask questions, propose machines

Reporting a bug :

open an issue answering three questions. Your environment (OS, Python, harness version), what you asked for (the prompt or the run's goals.md), and what happened (attach the tail of design_log.md, open_issues.md, and run_reflection.md if the run wrote one). The project directory is the reproduction case: it usually contains everything a maintainer needs.

Suggesting a feature or a rule :

open an issue describing the change and why it matters. DFM/DFA rule proposals are a first-class contribution surface: the rulebooks in rules/ have a documented proposal schema (see the dfm-rules skill), and rules can be proposed, promoted, or retired over time (the DFMA Rulebook Mechanism above).

Do I need API keys or a.env?

No. The claude CLI carries its own authentication, and the repo ships no .env by design.

(Decision record: 0008, one model engine, no keys.)

What CAD outputs does it produce?

Per part: parametric CadQuery source (part.py), STEP and STL exports, and 8 engineering-view PNG renders. Assemblies additionally get multi-view assembly renders and assembly-level exports where present.

Can it run unattended?

Yes. Runs launch headless via claude -p, and the mortality-proof orchestrator design means a crashed run resumes from the project directory alone: no checkpoint file is needed.

(Decision record: 0012, the mortal orchestrator.)

How do the agents coordinate?

Through the filesystem. Nine roles read and write one self-describing project directory: goals, plan, design log, per-part geometry, negotiation records, reflections. Nothing hides in a database, and the frontend, replay, and analysis all read the same files.

(Decision record: 0004, the filesystem is the message bus.)

Is the legacy PydanticAI repo maintained?

It is frozen and kept for its research value. Feature work happens in this repo.

Why the project moved from that implementation to a coding-agent harness is the founding decision record: 0001, Claude Code as the agent runtime.

Does it work on Windows?

Yes: clone with git clone -c core.symlinks=true (requires Developer Mode or admin rights), or work inside WSL. A default Windows clone materializes the repo's symlinks as plain text files, which breaks Python imports and agent discovery.

Can I run it on a harness other than Claude Code?

That is the design intent. Canonical agent, skill, and tool content lives once in .shared/, and each harness directory (.claude/, .opencode/) is a thin symlinked shell over it. Claude Code is the tested default today; the OpenCode build is open work.

(Decision record: 0002, the shared canonical layer.)

---

Licensed under the Apache License 2.0.

See NOTICE for attribution; the NOTICE attribution travels with every redistribution.

@software{ai_cad,
  title   = {AI-CAD: a multi-agent mechanical CAD harness},
  author  = {{Saif Raja on behalf of the ai-cad-labs project}},
  year    = {2026},
  url     = {https://github.com/ai-cad-labs/ai-cad},
  license = {Apache-2.0}
}

---

If you read this far, open an issue with the machine you want designed,
and it will get run.

⭐ If AI-CAD is useful to you, please consider giving it a star! It helps⭐

---