优化agent

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

@@ -13,15 +13,16 @@ Help an AI agent generate CAD models through the repository's CDSL engine.
 
 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.
+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, using the accepted
-   DesignIntent's feature IDs and mappings plus the part
-   plan for intent and CDSL references for concrete schema expressions.
+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.
@@ -29,7 +30,8 @@ Help an AI agent generate CAD models through the repository's CDSL engine.
 ## Part-skill boundary
 
 - User requirements and the CDSL schema/runtime override bridge guidance;
-  CDSL examples are lower-priority expression references.
+  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

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

@@ -1,40 +1,35 @@
-# DesignIntent Planning Recipe
+# CDSL Planning Recipe
 
 ## Requirement analysis
 
-1. Treat the backend-injected part-family skill as the selected family before
-   identifying structures. It provides planning guidance only.
-2. Decompose the requested part into structures with roles: `base`,
-   `reference`, `additive`, `subtractive`, `dressup`, or `pattern`.
-3. Every structure must state a purpose, structural dependencies, parameter
-   roles, selector roles, an executable CDSL atomic ID, and a named profile
-   type when its atomic needs a sketch.
-4. Put every structure exactly once in `feature_order`, after its dependencies.
-   Its `cdsl_feature_id` is the immutable ID that the later CDSL feature must use.
-5. Do not put coordinates, raw CDSL, Build123d, or low-level sketch data in a
-   DesignIntent.
-6. Missing essential dimensions are blocking `open_questions`. Unsupported
-   geometry is a `capability_gaps` item. A blocking item requires
-   `status: needs_clarification`; do not approximate silently.
+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. Never submit
-  `part_skill_ids`; the backend records the canonical selection for audit.
+- 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 only expression patterns. They never add or remove
-  a requested DesignIntent structure.
+- CDSL library examples show expression patterns only. They never override the
+  user's request or the CDSL schema/runtime.
 
 ## CDSL generation
 
-- Submit `propose_design_intent` before any library or CDSL-generation call.
-- After its ready result includes `intent_id`, inspect references and generate
-  complete CDSL. Use every planned `cdsl_feature_id` once, in `feature_order`.
-- Do not add undeclared CDSL features, delete planned features, change planned
-  atomics/profiles, or omit declared selector evidence.
+- 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.