claude-cad: Skill for Claude Code

CadQuery Modeling for Manufacturable CAD

This skill turns natural-language part requests into clean, verified, parametric CadQuery code whose STEP output reliably opens in SolidWorks. It encodes hard-won rules from real multi-part product design.

Core philosophy

1. Parametric first — every dimension is a named variable at the top of the file.
2. Verify before trusting — a script that printed [OK] is NOT proof of success. Always check geometry validity and solid count before declaring done.
3. Avoid OCC fragility — prefer simple primitives + boolean operations over fragile chained features. See references/occ_pitfalls.md.
4. One part, one file — each part is its own .py producing its own STEP/STL. Assemblies are done in SolidWorks, not baked into a single STEP.

Before creating anything: confirm where

Files land in whatever directory Claude Code was started in — that is the single thing that determines whether the user finds their STEP later. Before creating a project or the first part, state the absolute path you are about to write to, and stop to confirm if it looks wrong:

• a cloud-synced path (OneDrive, Dropbox, iCloud — note that on Windows the Desktop and Documents folders usually ARE OneDrive)
• Downloads, a home directory root, or a system folder
• the claude-cad toolkit repo itself
• a path containing spaces, parentheses, or non-ASCII characters

If any of those apply, say so and suggest a clean location such as C:\cad_project before writing files. Getting this wrong is silent: everything succeeds, and the user simply can't find the output.

The standard workflow

When the user asks for a part, follow this loop:

1. Match the questions to how specified the request is. Never invent a critical dimension — ask instead. Default to millimeters.
   • Underspecified (e.g. "a bracket to hold a 60 mm pipe"): don't guess, and don't refuse. Ask one focused batch of questions covering only what you truly can't proceed without — typically overall size, thickness/wall, the coordinate system/orientation, and any dimension that must match another part or a real component. Keep it short; propose sensible defaults the user can accept ("I'll assume 4 mm thick unless you say otherwise").
   • Fully specified: don't interrogate. Build it, and list any assumption you had to make in the final report.
   • If the user asks you to write a spec first, produce it as text (coordinate system, overall dimensions, every feature with size + position, interfaces) and get approval before writing code.
2. Write the part file following the structure in references/part_file_structure.md.
3. Run it and read the full terminal output, not just the last line.
4. Verify geometry validity, solid count, volume, and bounding box (see below).
5. Report the verification numbers to the user and note any assumptions made.