Add capability-probed structured outputs and a prototype/instance creation graph.

Probe API profiles for json_schema/tools, flatten worker artifacts onto a strict schema, and let users spawn or revise graph nodes instead of a one-shot DAG.

Co-authored-by: Cursor <cursoragent@cursor.com>

skills/dialogue/world-simulator/README.md

@@ -25,7 +25,7 @@ worker-templates/
 ```text
 选导演（recipes）→ design-flow → 验收近期 设计.创作流程（status=open）
   → 反复 design-step（注入 modules/{id}/prompt.md）
-  → 不够则再 design-flow（可追加 repeatable 新建，或 mode=revise 回头修改）→ closed
+  → 不够则再 design-flow（可追加 repeatable 新建）→ closed
   → （可选）opening-generator → 手动进 play
 ```
 

skills/dialogue/world-simulator/modules/aesthetics-interaction/prompt.md

@@ -51,7 +51,8 @@ feeds: design_only
 与用户一起钉清一份「体验契约」：给玩家什么感受、如何参与、正文如何呈现、何时等待用户。
 
 产物必须是 **context-fragment.v1** JSON，写入 tag「设计.美学纲领与交互范式」。
-业务字段全部放在「正文」内；须含 schema / 技能 / brief；建议填 mount 与稳变（本步不写数字 order）。
+业务字段全部放在「正文」内（三柱为**对象**，不要写成一段散文）；须含 schema / 技能 / brief；建议填 mount 与稳变（本步不写数字 order）。
+由运行时按模型能力做 schema/tool 投递，不要再口头包一层 outputs 字符串。
 
 一次 design-step、一场对话、一次验收。参与方式与美学内容在同一步内交叉追问，不要先交「半份交互」再开「半份美学」。
 用户已答过追问：把答复写入正文三块，`追问.题目` 优先 `[]`；禁止在「交互范式」与「美学纲领」之间轮流补洞拖验收。核心体验与权限边界够用即可收。
@@ -193,17 +194,18 @@ feeds: design_only
 
 硬规则（公共三段 + 本技正文）：
 1. 合法 JSON；必含 `schema` / `技能` / `brief` / `正文` / `自评` / `追问`（题目可 `[]`）。
-2. **公共三段**：`正文`＝产物主体；`自评`＝完备度打分（**分数 0–10 十分制，禁止百分数**）；`追问`＝导语+题目（建议选项/示例）。禁止用散文代替这三段。
-3. **本技正文三块**：`设定逻辑`（参与/内容维度/区域/复杂性/完备度）+ `交互范式` + `美学纲领`。未知省略或「未定」，禁止编造百科。
-4. `mount` 建议挂主世界层+转述；**禁止**写数字 `order`。`稳变` 定稿后多为 `stable`。
-5. `追问.题目` 一次宜 1～3 题；有建议选项与示例；允许「其它」。已答清的不要再问。题目只写在「追问」，askUser 为 null。
-6. summary：`美学纲领与交互范式 · {brief 缩略}`。
+2. **公共三段**：`正文`＝产物主体；`自评`＝打分（**分数 0–10 十分制，禁止百分数**）；`追问`＝导语+题目（建议选项/示例）。禁止用散文代替这三段。
+3. **正文深度**：三柱（设定逻辑 / 交互范式 / 美学纲领）为对象。柱下到「条目」为止：条目是短字段、string[]，或诊断三元组 `{结论, 依据, 完备度}` / `{已知, 待探, 完备度}`。诊断里的结论/依据/已知/待探必须是字符串。禁止把整柱写成一段 text；禁止在诊断或短字段里再套对象。
+4. **本技三柱**：`设定逻辑`（变造 + 参与方式 + 内容维度 + 区域/复杂性/完备度）+ `交互范式`（前置配置/视角/权限/后果）+ `美学纲领`（体验内核 + 呈现要点）。未知省略或「未定」，禁止编造百科。
+5. `mount` 建议挂主世界层+转述；**禁止**写数字 `order`。`稳变` 定稿后多为 `stable`。
+6. `追问.题目` 一次宜 1～3 题；有建议选项与示例；允许「其它」。已答清的不要再问。题目只写在「追问」，askUser 为 null。
+7. summary：`美学纲领与交互范式 · {brief 缩略}`。
 
 ## checklist
 
 ```checklist
 - [ ] 含 schema / brief / 正文 / 自评 / 追问 三段外壳？
-- [ ] 正文含设定逻辑 + 交互范式 + 美学纲领？自评有交互/美学/协调维度？
+- [ ] 正文三柱是对象（非一段散文）？设定逻辑里诊断有结论/依据/完备度？自评有交互/美学/协调维度？
 - [ ] 未写 order、未输出执行单元列表？
 - [ ] brief 能点题核心体验？变造/代入/满足来源清楚或已标未定？
 - [ ] 交互范式权限与美学纲领互相保护、不矛盾？
@@ -215,11 +217,12 @@ feeds: design_only
 
 ```examples
 好：
-- brief 点题「垄断生存资源的绝对掌控感」；正文三块齐（设定逻辑含完备度/待探、交互范式锁权限、美学纲领写体验内核）；自评打分；追问带建议选项打薄弱点。
-- 内容质感可参考「权力孤岛」类长描写，但必须落在上述 JSON 键里，不要输出 XML/自定义标签壳。
+- brief 点题「垄断生存资源的绝对掌控感」；正文三柱为对象（设定逻辑含诊断三元组、交互范式锁权限、美学纲领写体验内核）；自评打分；追问带建议选项打薄弱点。
+- 内容质感可参考「权力孤岛」类长描写，但必须落在上述 JSON 键里，不要输出 XML/自定义标签壳，也不要把三柱收成一段 text。
 
 坏：
 - 只有散文纲领，无 JSON / 无自评 / 无追问结构
+- 三柱是 sections[].text 一段话，验收卡无法切开诊断与契约
 - 百科式背景堆砌，无满足来源与权限边界
 - 输出 workers[] 或 order 表
 - 追问空洞「你想要什么体验？」无选项

skills/dialogue/world-simulator/modules/catalog.yaml

@@ -5,7 +5,7 @@
 # declaration = catalog 短声明（可被 prompt.md ```meta 覆盖）
 # artifact = 执行期产物 tag（程序映射；不写进流程 JSON）
 # repeatable = true 时允许同能力多次**新建**编入增量 DAG（如生成规则、具体实例）。
-# 回头修改已完成节点不是 repeatable：DAG 用 mode=revise + revises，继承旧产物。
+# 回头修改已完成节点不是 repeatable：用户在图上点该节点重进，不要排 mode=revise。
 # closer = true 时为创作终节点：选定后程序落库、关 DAG、保存定稿
 # auto = true 时为程序步：不抛默认问题、不经「同意并开始」，提案后直接执行（产物仍验收）
 # kind = 节点特性。缺省=普通执行步。prior-artifact=先验产物（须先定写什么；params 是规划产物，不拦执行）
@@ -21,7 +21,7 @@
 #
 # 世界模拟器常用能力见下「体验→世界→机制→呈现→收成」；编排按需选用，勿默认全选。
 # 流程是可变增量 DAG：勿一次排完全程；可反复调用标了 repeatable 的能力（每次=彻底新建）。
-# 已完成节点要改：编排 mode=revise（继承旧稿），不要再排一条 fresh。
+# 已完成节点要改：用户在图上点该节点重进（继承旧稿），不要再排一条 fresh 或 mode=revise。
 # 有编排参数的普通能力：DAG 步骤必须是带 params 的具体调用，禁止空壳进 design-step。
 # 〔先验产物〕例外：params 是规划产物，可空；「写什么」在步内钉。
 
@@ -77,7 +77,7 @@ modules:
         hint: 本批要锚定什么（如开局重要NPC）
       - key: count
         label: 数量
-        hint: 数字或「按规则」；contextual 时写清规模依据
+        hint: 同批时本批条数；规则「一次生成」为单条时忽略（本步只交 1 条）
 
   - id: narrative
     name: 叙事指南与故事推进

skills/dialogue/world-simulator/modules/concrete-instances/prompt.md

@@ -28,10 +28,10 @@ feeds: gm
 
 ```opening
 先认定本批按哪条规则生成：
-- 若【规划产物】已有 rule_id，以此为起点；要换规则就在本步改（须仍是已验收的预生成规则）。
+- 若【本步对象】已有 rule_id，以此为起点；要换规则就在本步改（须仍是已验收的预生成规则）。
 - 若规划为空，从已验收生成规则里选出一条预生成规则。
 
-有批次目标或数量偏好可一句带过；否则直接「按规则生成」。
+读规则「一次生成」：同批则本步一次交齐互有关系的多条；单条则本步只交 1 条。有批次目标可一句带过。
 ```
 
 ## task
@@ -41,12 +41,15 @@ feeds: gm
 
 本步 = 规则执行器。禁止重议对象族、生命周期、schema 或描写方法。
 
-本步是〔先验产物〕：先定调用哪条规则，再生成 records。读【规划产物】当起点；规划可空。
+本步是〔先验产物〕：先定调用哪条规则，再生成 records。读【本步对象】与【原型建议】；在本步钉「写什么」。
 
 执行顺序：
 1. 认定 `rule_id`：规划有则采用（用户要换则以最新为准，须仍是已验收的预生成规则）；空则先从依赖产物里选出。不要停下来让编排器补参。非预生成生命周期或缺信息 → 停止并指出缺口。
-2. 数量：规划 `count` 有数字用数字，否则用规则「数量」；`batch_goal` 只作不违反规则的筛选。
-3. 完全按规则的「生成与描写」+「产物格式」+「池」生成 `records`（单层 JSON；键=schema 顶层字段）。
+2. 条数：先读规则「一次生成」。
+   - `单条`：本批 `records` 恰好 1 条；规划 `count` 即使写成多条也忽略。
+   - `同批`：一次交齐互有关系的多条。条数：规划 `count` 有数字用数字，否则用规则「数量」。生成时先对齐「一次生成.关系」（各条如何互指、对立、同场），再填各条字段。
+   `batch_goal` 只作不违反规则的筛选。缺「一次生成」时按「数量」/ `count` 交 `records[]`（可多条）。
+3. 完全按规则的「生成与描写」+「产物格式」+「池」生成 `records`（始终是数组，单条也是长度为 1 的数组；键=schema 顶层字段）。
 4. 按规则自检；不合格内部重做。已有产物则追加批次（除非用户要求替换）。
 5. 输出 JSON；追问通常 `[]`。
 
@@ -56,15 +59,16 @@ summary：`具体实例 · {对象} · {n}条`
 ## principles
 
 ```principles
-1. 只按规则来：方法、格式、池、数量、约束——规则有什么用什么；没有的不发明。
-2. 只交 records：单层 JSON；不交解释、草稿、schema 副本、整池粘贴。
-3. 要改合同 → 回「生成规则」，本步不加字段、不改枚举。
+1. 只按规则来：方法、格式、池、数量、一次生成、约束——规则有什么用什么；没有的不发明。
+2. 同批先钉记录间关系再填各条；单条不虚构同场关系。始终交 `records[]`。
+3. 只交 records：单层 JSON；不交解释、草稿、schema 副本、整池粘贴。
+4. 要改合同 → 回「生成规则」，本步不加字段、不改枚举。
 ```
 
 ## probe
 
 ```probe
-通常不追问。仅当 contextual 数量算不出时问一句规模依据。
+通常不追问。仅当 contextual 数量算不出、或同批「关系」写了但本批对象对不齐时，问一句。
 用户要 schema 外内容 → 提示回「生成规则」。
 ```
 
@@ -110,7 +114,7 @@ summary：`具体实例 · {对象} · {n}条`
 硬规则：
 1. 合法 JSON；含 `schema` / `技能` / `brief` / `正文` / `自评` / `追问`。
 2. 正文键固定：`rule_id` / `本批数量` / `批次条件` / `batch_id` / `records` / `增量说明`。
-3. `records` 每条必须是规则约定的单层 JSON；`本批数量 === records.length`。
+3. `records` 始终为数组；每条必须是规则约定的单层 JSON；`本批数量 === records.length`。规则「一次生成」为单条时长度为 1；为同批时 ≥2 且关系对齐。
 4. 自评仅「合规模」一维。禁止改规则、写 `order`、输出执行单元列表。
 5. summary：`具体实例 · {对象} · {n}条`。
 
@@ -118,6 +122,7 @@ summary：`具体实例 · {对象} · {n}条`
 
 ```checklist
 - [ ] 按本步认定的 rule_id（规划或步内钉）的预生成规则执行？
+- [ ] 一次生成已遵守（单条=1 条；同批=多条且关系对齐）？records 始终是数组？
 - [ ] records 单层、键值符合产物格式与全部约束？
 - [ ] 自评为合规模？未改合同？
 ```
@@ -125,6 +130,8 @@ summary：`具体实例 · {对象} · {n}条`
 ## examples
 
 ```examples
-好：规则要 3 条怪物 → 交出 3 条单层 record，字段与池用法全服从规则。
+好：规则一次生成=同批、关系=开局仇敌二人 → 本批 2 条，对立在两条里对齐。
+好：规则一次生成=单条 → 本批 1 条；还要更多就再点原型。
+坏：同批规则却只交 1 条，或分多步把有关系的人拆开写。
 坏：加规则没有的字段；输出一段「我是怎么想的」却没有 records；本步改 schema。
 ```

skills/dialogue/world-simulator/modules/generation-rules/prompt.md

@@ -37,13 +37,14 @@ feeds: gm,auditor
 
 ```opening
 先认定本轮规则写哪一类内容：
-- 若【规划产物】已有对象，以此为起点；要改对象就在本步改。
+- 若【本步对象】/【原型建议】已有对象提示，以此为起点；要改对象就在本步改。
 - 若规划为空，先钉对象族，再谈规则。
 
 然后谈：
 1. 若不做专门规则、只靠世界设定临场写，最怕出现什么不可接受的结果？
 2. 更需要：开局先钉一批、游玩中再随机补，还是只在游玩期动态生成？
-3. 哪些产物字段需要「池」？（池挂在 JSON 字段上，如气质标签池→`气质`；可多个；没有就说没有）
+3. 这类实例彼此有没有必须同场钉死的关系（如互为亲属、对立、同场搭档）？有 → 一次同批生成；彼此独立 → 一次一条。
+4. 哪些产物字段需要「池」？（池挂在 JSON 字段上，如气质标签池→`气质`；可多个；没有就说没有）
 
 想到什么写什么；完整规则在正式产物里钉。
 ```
@@ -59,7 +60,7 @@ feeds: gm,auditor
 3. **池**（可选）：每个池挂在产物格式里的某个字段（变量）上，供该字段抽取/组装/枚举；
    一条规则可多个池；无则 `池: []`。
 
-本步是〔先验产物〕：先定本轮对象族，再写规则。读【规划产物】当起点；规划可空。禁止顺手扩到其它族。
+本步是〔先验产物〕：先定本轮对象族，再写规则。读【本步对象】与【原型建议】；在本步钉「写什么」。禁止顺手扩到其它族。
 
 执行顺序：
 1. 认定对象族：规划有 `target` 则采用（用户要改则以最新为准）；规划为空则先钉对象。不要停下来让编排器补参。
@@ -68,14 +69,17 @@ feeds: gm,auditor
    - `runtime_only`：仅游玩期动态生成；不要求「具体实例」。
    - `seed_only`：由「具体实例」预生成；规则用完可丢。
    - `seed_and_runtime`：先种子实例；规则与实例都保留，游玩期仍可按同规则生成。
-4. 写满规则三块：生成与描写（可较长）+ 产物格式（**单层 JSON**：每条产物是一层键值，无嵌套对象）+ 池（需要才填；绑顶层字段）。
-5. 逐字段过筛：每个属性都要能回答「对本对象族是否必要」。冗余字段删掉（如女主规则里的「性别」）；对象族必需字段不得漏（如 D&D 怪物的等级、攻击骰）。
-6. `rule_id`：规划已给则用；否则稳定 kebab-case。已有产物按 rule_id 增量。
+4. 钉「数量」与「一次生成」（两件不同的事）：
+   - **数量**：这类对象总共要有几条（fixed / range / contextual）。
+   - **一次生成**：点一次「具体实例」交几条。彼此有必须同场对齐的关系 → `同批`（一次交出并对齐关系）；彼此独立 → `单条`（一次只交 1 条，要更多就再点原型）。产物形状始终是 `records[]`，不因单条改成单对象。
+5. 写满规则三块：生成与描写（可较长）+ 产物格式（**单层 JSON**：每条产物是一层键值，无嵌套对象）+ 池（需要才填；绑顶层字段）。
+6. 逐字段过筛：每个属性都要能回答「对本对象族是否必要」。冗余字段删掉（如女主规则里的「性别」）；对象族必需字段不得漏（如 D&D 怪物的等级、攻击骰）。
+7. `rule_id`：规划已给则用；否则稳定 kebab-case。已有产物按 rule_id 增量。
    若本步对象与规划不一致，以最新对象为准并重钉对应英文 rule_id，禁止沿用旧 id。
-7. 按自评三维打分并填追问；输出 JSON。禁止夹带最终实例 records。
+8. 按自评三维打分并填追问；输出 JSON。禁止夹带最终实例 records。
 
 若程序已发默认问题：禁止重复开场；在首答上补洞。
-summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生成并动态}`；跳过 → `生成规则 · {对象} · 无需专门规则`。
+summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生成并动态} · {单条|同批}`；跳过 → `生成规则 · {对象} · 无需专门规则`。
 ```
 
 ## principles
@@ -90,7 +94,8 @@ summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生
    类型/必填/枚举/上下界必须可校验；禁止只给示例让下游猜类型。
 6. 池绑顶层字段名（如 `气质`、`攻击花招`）；一条规则可多池。池条目是该字段材料，不是整条 record。
 7. 生命周期先行；未定前不假装可执行「具体实例」。
-8. 不写变量更新公式、不写剧情推进、不填最终实例。
+8. **一次生成**看关系，不看「想不想一次多写」：有必须同场钉死的关系（亲属、对立、同场搭档等）→ `同批`；彼此独立 → `单条`。`同批` 至少 2 条，否则改 `单条`。不要把「总共要几个」（数量）和「这一次交几条」（一次生成）混成一件事。
+9. 不写变量更新公式、不写剧情推进、不填最终实例。
 ```
 
 ## probe
@@ -98,7 +103,7 @@ summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生
 ```probe
 每轮 1～2 点。规划已钉且用户未改对象时，禁止重问 target / rule_id。规划为空或用户要换对象时，先问本轮生成什么。
 
-优先：整条规则是否必要；某字段该不该进表（冗余 vs 漏接口）；单层格式类型/枚举/边界；哪些字段要池。
+优先：整条规则是否必要；实例彼此有无必须同场对齐的关系（一次生成：同批 vs 单条）；某字段该不该进表（冗余 vs 漏接口）；单层格式类型/枚举/边界；哪些字段要池。
 若双门槛不成立 → 建议跳过，停追问字段与格式。
 不追问：最终实例正文、变量增减公式、其它对象族、完整世界百科。
 ```
@@ -141,6 +146,10 @@ summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生
           "最大": 1,
           "决定规则": "contextual 时必填，可较长"
         },
+        "一次生成": {
+          "模式": "单条|同批",
+          "关系": "同批必填：本批记录之间必须一起钉的联系；单条写「彼此独立」"
+        },
         "生成与描写": {
           "依据": ["可较长；引用上游产物或用户要求"],
           "方法": ["可较长：生成顺序、如何组装、描写口径、语气/切面、如何用池"],
@@ -236,7 +245,7 @@ summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生
 1. 合法 JSON；必含 `schema` / `技能` / `brief` / `正文` / `自评` / `追问`（题目可 `[]`）。
 2. **公共三段**：正文＝规则主体；自评＝必要性/属性妥当/格式准确（**分数 0–10 十分制**）；追问＝导语+建议选项。
 3. **正文键固定**：本步参数、必要性判断、rules、增量说明。
-4. **每条 rule 必含**：生成与描写、产物格式；**池可空数组**。有池时 `绑定字段` 必须是单层 schema 的顶层键。
+4. **每条 rule 必含**：生成与描写、产物格式、数量、一次生成；**池可空数组**。有池时 `绑定字段` 必须是单层 schema 的顶层键。`一次生成.模式` 为同批时 `关系` 必填且本批至少 2 条；为单条时一次只交 1 条。
 5. **产物格式强制单层**：`schema` 的 `type` 不得为 `object`；`array` 的 `items` 不得为 object。禁止 `外貌.发色` 这类嵌套路径。
 6. 结论为「无需专门规则」时：`rules` 必须 `[]`。上下文策略布尔须与生命周期一致。
 7. 池条目≠最终实例；禁止输出具体实例 `records`、变量更新规则、执行单元列表。
@@ -248,7 +257,7 @@ summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生
 - [ ] 含 schema / brief / 正文 / 自评 / 追问？
 - [ ] 自评为必要性 / 属性妥当 / 格式准确？
 - [ ] 整条规则必要性有举证？不成立时 rules=[]？
-- [ ] 建立时：逐字段无冗余无漏接口？产物为单层 JSON 且类型可校验？
+- [ ] 建立时：逐字段无冗余无漏接口？产物为单层 JSON 且类型可校验？数量与一次生成已分清（总共几个 vs 这一次交几条）？同批有关系、单条写彼此独立？
 - [ ] 池：无则 []；有则绑顶层字段、未写成最终实例表？
 - [ ] 未夹带最终实例、变量公式、其它对象族、百科？
 ```
@@ -259,11 +268,15 @@ summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生
 好：
 - D&D 怪物：单层含 名称/等级/攻击骰/……；池可绑 `气质`；自评属性妥当高（未漏战斗接口）。
 - 女主规则：不设「性别」字段；关系切面进表；池可空。
+- 互为仇敌的两名开局 NPC：一次生成=同批，关系写清对立如何对齐；数量=2。
+- 可互换的酒馆路人：一次生成=单条，关系写「彼此独立」；要 5 个就点 5 次。
 - 事件钩子：池绑顶层 `钩子`；方法写抽 1～2 条写入该字段。
 - 普通古董 → 无需专门规则（必要性维度说明跳过理由）。
 
 坏：
 - 产物写成 `{ "外貌": { "发色": "…" } }` → 非单层，前端表格/投影难对接。
 - 女主规则塞「性别」；或怪物规则只有「名字+性格」没有等级/攻击骰。
+- 有亲属关系的三人却标成单条，分三次各写一条，关系对不上。
+- 把「总共要 5 个」写成一次生成=同批，但彼此并无必须同场的关系。
 - 把写好的 NPC 整份塞进池当最终实例。
 ```

skills/dialogue/world-simulator/orchestrator.md

@@ -46,7 +46,7 @@ uiPrompt: |
 
 你只负责读取 `设计.创作流程` DAG，并选择下一个创作节点：
 
-- 没有 DAG 或 DAG 需要追加节点：`design-flow`
-- DAG 已给出下一个可执行节点：`design-step`
+- 没有 DAG、需要追加节点，或用户要求补前序节点（即使下一步已是收口）：`design-flow`
+- DAG 已给出下一个可执行节点、且用户没有要求改排：`design-step`
 
 节点如何执行、何时等待、验收、返工、结束和运行状态变化均由 Runtime 与节点自身处理。

skills/dialogue/world-simulator/workers/design-flow/SKILL.md

@@ -3,8 +3,8 @@ id: design-flow
 skill: world-simulator
 name: 创作 · 流程编排
 description: >-
-  【编排】以用户已选配方为起点，从能力池排出近期工序与依赖，
-  产出/修订可变增量 DAG（设计.创作流程）。本步不写美学/机制正文，不写 Worker 集。
+  【编排】以用户已选配方为起点，从能力池排出近期 DAG 骨架（节点 + 依赖 + 原型槽位 + 建议）。
+  不决定执行顺序；用户在图上点选。本步不写美学/机制正文。
 version: 1
 stage: design
 inputTags:
@@ -40,70 +40,101 @@ contextSegments:
 
 # 创作 · 流程编排
 
-你只做一件事：根据【用户要求】编排或**增量修订**一份剧本流程（可变 DAG）。要求按先后都有效，冲突时以较新的为准。
+你只做一件事：根据【用户要求】编排或**增量修订**一份 **DAG 骨架**。要求按先后都有效，冲突时以较新的为准。
+
+**你不决定**用户下一步先跑哪个——用户在分层图上点选。你只产出：有哪些节点、depends_on、原型槽位（repeatable 能力）、以及建议。
 
 上下文里会有：
 
-1. **【流程进度】**（程序钉死）：已完成哪些步、草案里已有哪些步、哪些能力才允许再编入。必须先读完再排。  
-2. **【用户已选配方】**：该方法的适用、核心思路、设计流程与原则 + 近期起点 steps——**不是**锁死流水线；**禁止**替用户改选其它配方  
-3. **【能力 · 可选工序】**：固定中文名 + 声明 + **何时用 / 何时不用 / 边界**（来自各能力 meta）+（若有）编排参数——步骤只能从这里选；标〔可反复〕的可多次**新建**编入；已完成节点要改用回头修改（mode=revise）  
-4. **【已有剧本草案】/【已验收步骤】**：若有，在其上追加或改未验收步，**不要**推倒重来
-
-开局说明：程序可能已按配方 `steps` 写入近期起点（用户已坐在 DAG 第一步，例如「美学纲领与交互范式」）。此时**不要**把开局步再规划一遍；仅追加缺口。listed 步已齐仍需扩写时，保留已完成 id，只加新步。
+1. **【流程进度】**（程序钉死）：已完成哪些步、草案里已有哪些步、原型槽位。必须先读完再排。  
+2. **【用户已选配方】**：方法论 + 近期起点——**不是**锁死流水线  
+3. **【能力 · 可选工序】**：步骤只能从这里选  
+4. **【已有剧本草案】/【已验收步骤】**：在其上追加，**不要**推倒重来
 
 ## 增量 DAG（核心）
 
-**禁止**一次排完全程固定长链。每次只排出**近期要做**的步骤（通常 1～4 步），`status` 默认 `"open"`。
+**禁止**一次排完全程固定长链。每次只排出**近期 horizon**（通常 1～4 个节点 + 若干原型），`status` 默认 `"open"`。
 
-选型规则：
+### 节点类型
 
-- **跟配方方法论**：用配方的 core / process / principles 理解整局怎么设计、何时收成。  
-- **跟能力 meta**：某步该不该排，看能力的「何时用 / 何时不用 / 边界」；**不要**在配方里找各能力调用条件，也不要凭题材默认全选。  
-- 〔先验产物〕（生成规则、具体实例）：可提前规划「写什么」写入 params；执行时程序注入【规划产物】。规划可空——对象在步内钉。提前规划多条（不同对象/批次）是正确的。**禁止**为钉「生成什么 / 调用哪个规则」而 askUser 拦在确认开干前。  
-- 其它有「编排参数」的能力：写入 DAG 时可先留空壳；**确认开干前**必须钉齐必填 params。  
-- 用户先认可**下一节点**，再进入执行；用户提出新要求时，再调本 worker 修订未验收步或追加新步。
+| 类型 | JSON | 谁跑 |
+|------|------|------|
+| 普通一步 | 缺省（无 role） | 用户点上直接 design-step |
+| **原型槽位** | `"role": "prototype"` | 用户点上 → 程序增殖 instance → design-step |
+| **实例** | `"role": "instance"`, `"from": "<原型 id>"` | 仅程序增殖，**禁止**你在编排层预排 |
 
-同能力**可以**多次出现。必须分清两种：
+**禁止**排 `mode=revise` / 回头修改节点。已完成节点要改：用户在图上点该节点重进，不在 DAG 里加修订步。
 
-- **彻底新建**（〔可反复〕如生成规则、具体实例）：`mode` 缺省或 `"fresh"`，新 id + 新 params。每一次都是新对象/新批次，**不要**改旧条。id 应尽量带上调用目标，如 `生成规则·怪物`，避免无信息的 `#2`。
-- **回头修改**：用户要改**已经做过**的节点（漏了、谈浅了、后来发现要改）→ 追加新 id，`"mode": "revise"`，`"revises": "<原步 id>"`。程序会注入既有产物，在旧稿上改。非反复技能**禁止**再排一条 fresh；只能 revise。插在最近已验收步之后、尚未执行的步之前。
+### 〔可反复〕= 原型，不是多条 instance
+
+生成规则、具体实例等 catalog 标〔可反复〕的能力：
+
+- 在 `steps` 里写 **`role: "prototype"`** 一条即可（id 通常与 name 相同，如 `"生成规则"`）  
+- 写 **`suggestion`**：建议这条原型将来生成什么（短句，给用户和实例步参考）  
+- **禁止**在原型上写 `params`  
+- **禁止**预排 `role: "instance"` 或 `生成规则#2` 这类实例——用户在图上点原型，程序增殖
+
+### `suggestions`（流程级）
+
+除 `steps` 里的原型外，可在顶层写 **`suggestions`**：建议用户**还可以**追加哪些原型（尚未编入 steps 时展示在图上）。
+
+```json
+"suggestions": [
+  {
+    "name": "生成规则",
+    "suggestion": "怪物种群与 NPC 两套规则，各开一条",
+    "depends_on": ["美学纲领与交互范式"]
+  }
+]
+```
+
+若已把该能力编入 `steps` 为 prototype，不必在 suggestions 重复。
+
+### 〔先验产物〕
+
+生成规则、具体实例：**「写什么」在实例步内钉**，不在编排层 params。原型只带 `suggestion`。
+
+### 选型规则
+
+- 跟配方 core / process / principles  
+- 跟能力 meta 的何时用/不用  
+- 用户要补节点 → 插在未验收步之前、收口之前，`status: "open"`
 
 ## 产出（唯一）
 
-写入 tag `设计.创作流程`，必须是 JSON 对象，形状：
+写入 tag `设计.创作流程`。根对象就是下面这份 JSON（必须含 `steps`），不要改写成 `artifact.flat.v1` 的 sections。
 
 ```json
 {
-  "brief": "一句话复述用户要的体验（可选）",
+  "brief": "一句话体验（可选）",
   "status": "open",
+  "suggestions": [
+    {
+      "name": "具体实例",
+      "suggestion": "开局 2～3 个重要 NPC",
+      "depends_on": ["生成规则"]
+    }
+  ],
   "steps": [
     { "id": "美学纲领与交互范式", "name": "美学纲领与交互范式", "depends_on": [] },
     {
-      "id": "生成规则·怪物",
+      "id": "生成规则",
       "name": "生成规则",
-      "params": {
-        "target": "怪物",
-        "rule_id": "monsters",
-        "lifecycle_intent": "runtime_only"
-      },
+      "role": "prototype",
+      "suggestion": "先写怪物种群生成规则",
       "depends_on": ["美学纲领与交互范式"]
     },
     {
-      "id": "具体实例·重要NPC·开局",
+      "id": "具体实例",
       "name": "具体实例",
-      "params": {
-        "rule_id": "major-npcs",
-        "batch_goal": "开局重要NPC",
-        "count": "按规则"
-      },
-      "depends_on": ["生成规则·重要NPC"]
+      "role": "prototype",
+      "suggestion": "锚定 1～2 个开局 NPC",
+      "depends_on": ["生成规则"]
     },
     {
-      "id": "美学纲领与交互范式·改",
-      "name": "美学纲领与交互范式",
-      "mode": "revise",
-      "revises": "美学纲领与交互范式",
-      "depends_on": ["实现机制"]
+      "id": "开场白与开场变量",
+      "name": "开场白与开场变量",
+      "depends_on": ["美学纲领与交互范式", "具体实例"]
     }
   ]
 }
@@ -111,44 +142,20 @@ contextSegments:
 
 规则：
 
-1. `steps` 数组顺序 = **建议执行顺序**（依赖须指向更前的步骤）
-2. `name` = 能力池里的固定中文名（可重复）
-3. `id` = 本局步骤唯一键；同 name 多次时必须不同；新建优先语义化（`生成规则·{对象}`）；回头修改用 `{原id}·改`
-4. `depends_on` = 其它步骤的 **id**（若某 name 在本流程唯一，也可写该 name）
-5. `params` = 本步调用参数（对象）。〔先验产物〕：此处是规划产物（可空；已知对象就填，便于区分多条）。其它能力目录声明了编排参数时，**必填项必须写出**；可选则能推断就写。回头修改可省略，程序会从 `revises` 那步继承
-6. `status`：`"open"` = 还可能追加；`"closed"` = 不再扩步（可走收成）
-7. 已验收步骤的 id **必须保留**；只能追加新步，或改未验收步的依赖/顺序/params
-8. 已完成的**非反复**技能禁止再排一条 `mode=fresh`；要改旧稿只能追加 `mode=revise` + `revises`。〔可反复〕再编入新 id 且 fresh = 彻底新建（新对象/新批次），不是改旧条；改旧条同样用 revise
-9. 配方建议 steps 只作近期起点；按能力 meta 按需选用，勿默认全选、勿一次排满
-10. **禁止**把「交互」与「美学」拆成两步
-11. **禁止**在本步写能力正文、自由 Worker 列表、表结构
-12. **禁止**编排「反复发明执行单元」；收成链：确认「游玩拓扑」→（上下文已多时）「上下文投影排序」→「细化终稿」→（可开玩时）「开场白与开场变量」。挂谁可早、排第几须晚，勿让中段技能写死 order
-13. 「开场白与开场变量」标〔收口〕：排在细化终稿之后作为最后一步；排入后不要再追加其它步，可将 `status` 设为 `closed`。选定开场由程序落库并保存定稿，不必再调 opening-generator
-14. 参数或选型不够时，用 askUser 问 1～2 点（**优先带 options，并允许其它**）。
-    只许问**排布层**的事：下一步排哪个能力、普通节点的必填 params 取什么值、是新建还是回头修改哪一步。
-    〔先验产物〕的「生成什么 / 调用哪个规则」在步内钉，**不要**为此 askUser。
-    **禁止**问体验偏好、设定细节、口味倾向等能力正文问题——那是 design-step 的活；
-    已验收步骤里问过的题，**禁止**再抛一遍（用户会读成「那一步要重做」）
-15. 依赖真实产物的步骤（如具体实例依赖某条生成规则）须等上游验收后再编排，并从产物中列出可选项供用户选
-16. `summary`：`流程 · N 步 · open|closed · …`
-17. **改对象必须改后台 id**：用户把「生成规则」从女租客改成丧尸怪物时（编排修订或步内改规划），须同步改
-    `params.target`、`params.rule_id`（对应英文 kebab-case，如 `zombies`）、以及步骤 `id`（如 `生成规则·丧尸怪物`）。
-    **禁止**只改中文对象却沿用旧 `rule_id` / 旧步骤 id。
-    这是**改这条规则的对象**（回头修改或改未验收步），与「再来一条新的生成规则」不是一回事。
+1. `steps` 顺序 = 建议阅读顺序；`depends_on` 须指向更前步骤 id  
+2. `name` = 能力池固定中文名  
+3. `id` = 本局唯一；原型 id 稳定（如 `生成规则`）；实例 id 由程序增殖（`生成规则#1`…）  
+4. **禁止**在编排层为 repeatable 预排 instance 或写 params  
+5. 已验收 id **必须保留**  
+6. 非反复已完成 → 禁止再排新建，**禁止**排 `mode=revise`  
+7. 收口「开场白与开场变量」排最后；选定前用户补节点 → 插收口前、`status: "open"`  
+8. askUser 只问排布：补哪个原型、改依赖。**禁止**问体验正文，**禁止**问要不要回头修改  
+9. `summary`：`流程 · N 步 · open|closed · …`
 
 ## 自检
 
-- 用户是否已选配方？（未选则不要硬编）
-- 是否只排了近期 horizon，而不是假固定全图？
-- 是否误排了多次「发明 Worker」？应改为至多一次「游玩拓扑」
-- 每步是否按能力 meta 的何时用/不用判断过，而非题材默认？
-- 每步 name 都在【能力】里？同名多次是否都有不同 id？
-- 有编排参数的普通步骤，必填 params 是否已钉齐？缺参是否应先 askUser 而不是产出空壳？
-- 〔先验产物〕是否误把「生成什么」当成确认开干前必填？规划可空；已知对象才写入 params
-- depends_on 是否都指向更靠前的步骤 id？
-- 已验收 id 是否都还在？
-- 【流程进度】里已完成的非反复技能，是否误当成 fresh 又排了一次？要改旧稿应 mode=revise
-- askUser 是否只问了排哪步 / 填哪个参数 / 新建还是回头修改，而不是体验偏好等正文问题？
-- 需要反复补同类内容时，是否用了新 id + 新 params + fresh 追加（彻底新建），而不是改写旧步？
-- 用户要改已完成节点时，是否用了 mode=revise + revises，而不是再排一条 fresh？
-- 收成前是否把 `status` 设为 `closed`？
+- 只排了骨架，没有替用户决定顺序？  
+- repeatable 是否都是 `role=prototype` + suggestion，没有 instance/params？  
+- suggestions 是否简短、可执行？  
+- depends_on 是否合法（具体实例原型依赖生成规则原型 = 至少一条规则实例验收后才可增殖）？  
+- 已验收 id 是否都在？

skills/dialogue/world-simulator/workers/design-step/SKILL.md

@@ -42,14 +42,14 @@ contextSegments:
 同能力可多次出现（不同 id）：
 
 - **新建**（mode 缺省 / fresh）：只写这一次应增量补上的新内容；可合并既有同 tag 内容，但不改旧条、不假装在做别的步骤。〔可反复〕的「再来一次」属于这种。
-- **回头修改**（mode=revise）：以【既有产物 · 继承修改】为底稿，改用户点名的部分，保留其余；不从零另起，不再走开场询问。
+- **回头修改**（程序注入【既有产物 · 继承修改】）：用户从图上点已完成节点重进。以底稿继续改用户点名的部分，保留其余；不从零另起，不再走开场询问。
 - **按意见修改**（验收底栏）：以【待改底稿】（最新产物）为底。用户要求按先后都有效，冲突时以较新的为准；未点名推翻的旧条仍须留在产物里。禁止原样交回。
 
 ## 执行
 
 1. 认定本步要钉的事项：读【本步方法】里 `task` 开头（钉什么、写到哪个 tag）和 `meta.boundary` 的「本技能：」行。
 2. 读【用户要求】与依赖产物。若有默认问题：程序已发出，首答在「用户.worker答复」——在其答复上继续，不重复开场白。
-3. 按方法正文填产物。〔先验产物〕读【规划产物】当起点（可空、可在步内修订）；其它节点编排参数见【本步参数】，直接采用。
+3. 按方法正文填产物。〔先验产物〕读【本步对象】在本步与用户钉「写什么」；可参考【原型建议】。其它节点编排参数见【本步参数】，直接采用。
 4. 产物用简洁 JSON 或结构化中文，少写机器变量名。`summary`：`{本步能力名} · …`
 
 ## 缺料时
@@ -62,4 +62,4 @@ contextSegments:
 - 〔先验产物〕规划为空：先在本步钉「写什么」，再填产物。不要退回编排器补参。
 - 普通节点【本步参数】缺必填项或与目录不符：停止产出，提示返回流程编排补参。
 
-需要追加「再来一次」或回头修改其它步时，由编排器再调流程编排。
+需要追加「再来一次」时，由编排器再调流程编排。已完成节点要改：用户自己在图上点该节点，不要让编排器加修订步。