54 lines
2.7 KiB
Markdown
54 lines
2.7 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. 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.
|