52 lines
2.5 KiB
Markdown
52 lines
2.5 KiB
Markdown
---
|
|
name: cad-engine
|
|
description: 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.
|