Files
cdsl-cad/backend/agent/skills/cad-engine/SKILL.md
T
2026-08-24 14:52:08 +08:00

2.5 KiB

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. Submit a complete DesignIntent before reading CDSL references or generating CDSL. It contains semantic structures and mappings, never sketch coordinates or raw CAD code. The backend records canonical selected part skills.
  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, using the accepted DesignIntent's feature IDs and mappings plus the part plan for intent and CDSL references for concrete schema expressions.
  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.
  • 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.