cdsl-cad/backend/agent/skills/cad-engine/SKILL.md

name, description

name	description
cad-engine	Generate and revise executable CDSL CAD models through the local schema, runtime, library references, and injected part-family planning bridges.

CAD Engine Skill

Purpose

Help an AI agent generate CAD models through the repository's CDSL engine.

Required workflow

1. Use any injected CDSL part-skill bridge to establish the part structure, parameter roles, and feature order. It is planning guidance only.
2. Record a concise natural-language design brief before reading CDSL references or generating CDSL. The brief captures the intended structures, dependency order, key dimensions, and explicit assumptions. It is reference context only, never an executable CAD contract.
3. Read the engine README, profile_schema.json, and cdsl_schema.json, then search the official CDSL library for schema-valid profiles and feature expressions. cdsl_schema.json is the executable input contract.
4. Produce parameterized CDSL in feature dependency order. CDSL is the sole authoritative and executable model: choose its feature IDs, profiles, selectors, and schema-valid expressions directly from the CDSL contract.
5. Call the generation tool only when every chosen feature is executable by the current schema and runtime. Validate through the cdsl_only path, then generate STEP and GLB artifacts.

Part-skill boundary

• User requirements and the CDSL schema/runtime override bridge guidance; CDSL examples are lower-priority expression references. The textual design brief is planning context and is never validated against the CDSL.
• Do not expose upstream source skills directly or treat them as code. Use only the injected CDSL bridge content.
• Never emit build123d source or invent an atomic, profile, selector, or capability that the local contract does not support.
• Express circular bolt layouts as explicit circles when supported; preserve thread intent as a cylindrical-bore approximation; omit fillets/chamfers without a unique selector. These decisions must be recorded in the build audit rather than hidden in generated geometry.

Hard constraints

• Prefer named profiles and discrete semantic parameters over raw coordinates.
• Do not use compiler_context as the final source of missing training data.
• Keep the generated CDSL self-sufficient whenever the supported shape generators can express the geometry.
• Use only the feature operations, profile types, parameter names, and nested value shapes in cdsl_schema.json. In particular, hole positions must be objects such as {"mm": [u_mm, v_mm, w_mm]}, never bare coordinate arrays.
• Preserve the original CDSL and write revisions as separate artifacts.