New Model

Ask questions in batches of 2-4 using the AskUserQuestion tool. Continue asking until you have a clear mental model of the part. It's fine to ask 10+ questions for complex designs — the user prefers thoroughness.

Step 2: Study Existing Models

Before generating code, read ALL .scad files in the repository to deeply understand the user's coding style:

find . -path '*/src/*.scad' -not -name '*.v[0-9]*'

Read each file. Pay attention to:

• Parameter naming conventions (snake_case, grouped with // --- Group ---)
• How modules are structured and named
• Design patterns used (profile extrusion, offset tricks, boolean ops)
• Level of parametric detail
• Comment style and density
• How computed values are derived

Also reference the CLAUDE.md conventions for the canonical .scad file structure.

Step 3: Generate Files

Create the project directory and all files:

src/{name}/
├── src/
│   ├── {name}-simple.scad   # Lo-fi version: basic geometry, correct shape
│   └── {name}.scad           # Hi-fi version: refined with fillets, textures, safeguards
├── README.md
└── CHANGELOG.md

.scad Files

Both files must follow the repository's .scad conventions exactly:

/** Header — 1-3 line description */

// --- Parameter Group ---
param = value; // [mm] Inline description

// --- Computed ---
derived = expression;

module helper() { ... }

module assembly() { ... }

assembly();

Simple version ({name}-simple.scad):

• Core geometry only — get the shape right
• All key parameters defined and annotated
• Minimal modules, straightforward construction
• Should be valid and renderable

Detailed version ({name}.scad):

• Full parametric design using the repo's design patterns
• Dual-fillet offset trick where appropriate
• Geometric safeguards (min/max clamping)
• Side-profile extrusion if the part suits it
• Additional features: chamfers, textures, tolerances
• Should be valid and renderable

Both files must share the same parameter names and groups so the user can compare them directly.

README.md

Follow the pattern from existing projects:

# {Title}

{1-2 sentence description of what it does and why}

## Features

- {feature list}

## Printing

- **Orientation**: {how to place on bed}
- **Material**: {recommended material}
- **Infill**: {percentage}
- **Supports**: {yes/no and why}

## Customization

| Parameter | Default | Description |
| --- | --- | --- |
| `param_name` | `value` | What it controls |

CHANGELOG.md

# Changelog

## [0.1.0] - {today's date YYYY-MM-DD}

### Added
- Initial generated design with simple and detailed variants
- {list key features}

Step 4: Render

Run the render script to generate the 3x3 composite preview image for the detailed version:

cd /Users/justin/Git/cad && ./cad.ts --render {name}

This generates src/{name}/render.png with the 3x3 composite view.

Also render the simple version manually for comparison:

cd /Users/justin/Git/cad
openscad --preview --projection=ortho \
  --imgsize="1024,1024" --viewall --autocenter \
  --colorscheme="Starnight" \
  --camera="0,0,0,54.74,0,315,0" \
  -o src/{name}/render-simple.png src/{name}/src/{name}-simple.scad

Step 5: Open in OpenSCAD

Open both versions in the OpenSCAD GUI so the user can inspect them:

openscad /Users/justin/Git/cad/src/{name}/src/{name}.scad &
openscad /Users/justin/Git/cad/src/{name}/src/{name}-simple.scad &

Step 6: Present Results

Show the user:

1. The render images (use the Read tool to display render.png and render-simple.png)
2. A brief summary of the two versions and their key differences
3. Ask which version they'd like to use as the starting point for iteration
4. Once they choose, offer to delete the other version and rename if needed

Guidelines

• Never generate geometry you haven't reasoned about — if unsure about a dimension or approach, ask
• Prefer additive construction (union) over subtractive (difference) where possible
• Use $fn = 100 for curved surfaces unless the user specifies otherwise
• All parameters should have // [unit] annotations
• Clamp radius/tolerance values with min()/max() to prevent self-intersection
• The file must end with the top-level assembly call, no trailing comments or headers
• Test that your generated code is syntactically valid OpenSCAD before writing it