cdsl-cad/backend/agent/skills/cad-engine/planning-recipe.md

CDSL Planning Recipe

Requirement analysis

1. Treat the backend-injected part-family skill as planning guidance only.
2. Write a concise natural-language brief describing the requested structures, dependency order, key dimensions, and explicit assumptions.
3. Ask the user one concise clarification question when an essential dimension or requested outcome is unknown. Do not silently fabricate it.
4. Keep the brief free of feature IDs, selector bindings, profile bindings, sketch coordinates, raw CDSL, and Build123d source. Those implementation choices belong only in the final CDSL document.
5. The brief is not stored or validated as a CAD artifact. It is reference context for the model while it writes the one authoritative CDSL document.

Part family boundary

• Use only the backend-injected primary and support skills. The backend records the canonical selection for audit.
• Explicit user requirements override part skills. The executable CDSL schema/runtime overrides both part skills and library examples.
• The current primary family is inherited during revisions unless the user explicitly asks to replace the whole part. A family conflict needs a concise clarification before a ready plan can be submitted.
• CDSL library examples show expression patterns only. They never override the user's request or the CDSL schema/runtime.

CDSL generation

• Submit describe_design_intent before any library or CDSL-generation call.
• After the text brief is returned, inspect references and generate complete, schema-valid CDSL. CDSL controls its own feature IDs, atomics, profiles, and selectors; it is not checked for agreement with the brief.
• Keep cdsl_only as the only build path. Never use compiler_context or a legacy fallback.