Summary
The /openscad skill currently jumps straight from a natural-language prompt to model_001.scad. I'd like to propose adding an explicit step that first writes a spec file (e.g. model_spec.md) that the skill then references throughout the iterate-and-render loop. This could draw on CLAUDE.md and/or an "engineering-spec" doc as a template.
Motivation
I've been using the skill to design a 3D-printable drone, and I've found that starting the session with a spec file makes the skill significantly better at one-shotting the CAD. When the requirements (dimensions, tolerances, clearances, mounting points, constraints, print orientation, etc.) are written down first, the agent has a stable reference to check each iteration against, instead of re-deriving intent from the chat history every render. The result is fewer wasted iterations and CAD that's far closer to correct on the first pass.
Right now the workflow is: /openscad → model_001.scad → preview → iterate
Proposed workflow is: /openscad → model_spec.md → model_001.scad → preview → check against spec → iterate
Proposed change
Add a step near the top of the openscad SKILL.md workflow (before "Create the Versioned .scad File"):
- Capture/confirm a spec. If a spec file for the model doesn't already exist, generate one from the user's prompt — pulling structure from
CLAUDE.md or an engineering-spec template doc if present — and confirm key parameters with the user (overall dimensions, tolerances/clearances, interfaces and mounting points, material/printer constraints, print orientation, and any hard requirements vs. nice-to-haves).
- Persist it as e.g.
<model-name>_spec.md alongside the versioned .scad files.
- Reference it on every iteration. In the compare/iterate step, evaluate the rendered preview against the spec, not just against the previous version, so the agent self-corrects toward documented requirements.
Optionally, the repo could ship a short engineering-spec template (or a section in CLAUDE.md) describing the fields a good spec should contain, so the generated spec is consistent across sessions.
Why this fits the skill
The skill already leans on a written, versioned artifact (the .scad files) plus a visual feedback loop. A spec file extends the same philosophy to intent: it gives the validation/iteration loop a ground truth to measure against, which is exactly where more complex multi-part designs (like a drone frame) currently drift.
Happy to put up a PR for the SKILL.md change and a sample spec template if that'd be useful.
Summary
The
/openscadskill currently jumps straight from a natural-language prompt tomodel_001.scad. I'd like to propose adding an explicit step that first writes a spec file (e.g.model_spec.md) that the skill then references throughout the iterate-and-render loop. This could draw onCLAUDE.mdand/or an "engineering-spec" doc as a template.Motivation
I've been using the skill to design a 3D-printable drone, and I've found that starting the session with a spec file makes the skill significantly better at one-shotting the CAD. When the requirements (dimensions, tolerances, clearances, mounting points, constraints, print orientation, etc.) are written down first, the agent has a stable reference to check each iteration against, instead of re-deriving intent from the chat history every render. The result is fewer wasted iterations and CAD that's far closer to correct on the first pass.
Right now the workflow is: /openscad → model_001.scad → preview → iterate
Proposed workflow is: /openscad → model_spec.md → model_001.scad → preview → check against spec → iterate
Proposed change
Add a step near the top of the openscad SKILL.md workflow (before "Create the Versioned .scad File"):
CLAUDE.mdor an engineering-spec template doc if present — and confirm key parameters with the user (overall dimensions, tolerances/clearances, interfaces and mounting points, material/printer constraints, print orientation, and any hard requirements vs. nice-to-haves).<model-name>_spec.mdalongside the versioned.scadfiles.Optionally, the repo could ship a short
engineering-spectemplate (or a section inCLAUDE.md) describing the fields a good spec should contain, so the generated spec is consistent across sessions.Why this fits the skill
The skill already leans on a written, versioned artifact (the
.scadfiles) plus a visual feedback loop. A spec file extends the same philosophy to intent: it gives the validation/iteration loop a ground truth to measure against, which is exactly where more complex multi-part designs (like a drone frame) currently drift.Happy to put up a PR for the SKILL.md change and a sample spec template if that'd be useful.