优化agent

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.