完善配方驱动的创作编排

为可重复技能补充参数校验与展示，统一配方、编排器和执行单元术语。

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

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

@@ -2,16 +2,21 @@
 # 各【导演】与编排都从这里选型。
 # id = modules/{id}/ 文件夹
 # name = 固定中文名（流程 JSON 的 name；同能力可多次时靠 step.id 区分）
-# declaration = 插入导演 / design-flow 提示词的短声明（选型用；勿塞全文）
+# declaration = catalog 短声明（可被 prompt.md ```meta 覆盖）
 # artifact = 执行期产物 tag（程序映射；不写进流程 JSON）
 # repeatable = true 时允许同能力多次编入增量 DAG（如生成规则、具体实例）
+# params = 可选；编排进 DAG 时 steps[].params 的声明（required 须在执行前钉齐）
 # opening = 可选；覆盖 prompt.md 里 ```opening 默认问题（一般只写在 prompt.md）
 #
+# 编排选型：程序会读取各 modules/{id}/prompt.md 的 meta
+# （declaration / when / when_not / boundary）注入 design-flow；勿只靠本表短声明。
+#
 # 标准范例：aesthetics-interaction（美学纲领与交互范式）
-# 后来写能力：同结构 prompt.md（含默认问题）+ 本表一行 declaration
+# 后来写能力：同结构 prompt.md（含默认问题）+ 本表一行索引
 #
 # 世界模拟器常用能力见下「体验→世界→机制→呈现→收成」；编排按需选用，勿默认全选。
 # 流程是可变增量 DAG：勿一次排完全程；可反复调用标了 repeatable 的能力。
+# 有编排参数的能力：DAG 步骤必须是带 params 的具体调用，禁止空壳进 design-step。
 
 modules:
   # —— 体验契约 ——
@@ -34,17 +39,44 @@ modules:
     name: 生成规则
     repeatable: true
     declaration: >-
-      钉内容如何生成/推进的可执行规则（触发、约束、节奏），非散文设定；
-      可按题材块反复调用（每次增量补规则）
+      仅当某类内容既对游玩重要、又无法凭世界基底稳定生成时使用：
+      定义严格 schema、生成约束与仅动态/仅预生成/预生成并动态三种生命周期；
+      可按生成对象反复调用
     artifact: 设计.生成规则
+    params:
+      - key: target
+        label: 生成对象
+        required: true
+        hint: 本轮为哪一类内容建规则；编排时 askUser 给选项+其它
+      - key: rule_id
+        label: 规则 id
+        required: false
+        hint: 建议英文 kebab-case；可执行时再最终钉死
+      - key: lifecycle_intent
+        label: 生命周期意图
+        required: false
+        hint: runtime_only | seed_only | seed_and_runtime；不明则 askUser
 
   - id: concrete-instances
     name: 具体实例
     repeatable: true
     declaration: >-
-      钉关键人物/地点/物件等具体实例，供开局与生成锚定；勿堆无关名单；
-      可按需反复调用（每次增量补实例）
+      执行一条要求预生成的生成规则，直接产出符合其 schema 与约束的具体实例；
+      仅动态规则不调用，可按 rule_id 或批次反复调用
     artifact: 设计.具体实例
+    params:
+      - key: rule_id
+        label: 调用规则
+        required: true
+        hint: 必须来自已验收生成规则中 seed_only/seed_and_runtime 的真实 rule_id；编排时给选项
+      - key: batch_goal
+        label: 批次目标
+        required: false
+        hint: 本批要锚定什么（如开局重要NPC）
+      - key: count
+        label: 数量
+        required: false
+        hint: 数字或「按规则」；contextual 时写清规模依据
 
   - id: narrative
     name: 叙事指南

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

@@ -1,6 +1,7 @@
 # 具体实例
 
-> **状态：待完善** — 块格式见 `docs/world-simulator-modules.md`；范例见 `aesthetics-interaction`。
+> 能力文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。  
+> 写法说明：`docs/world-simulator-modules.md`；范例：`aesthetics-interaction`。
 
 ## meta
 
@@ -8,51 +9,101 @@
 name: 具体实例
 id: concrete-instances
 artifact: 设计.具体实例
-declaration: 钉关键人物/地点/物件等具体实例，供开局与生成锚定；勿堆无关名单
-when: 需要可点名的人/地/物锚定开局或生成时
-when_not: 蓝图骨架未定时就堆长名单；用户明确只要即时生成、不要预置实例时
+declaration: >
+  执行一条要求预生成的生成规则，直接产出符合该规则的具体实例；
+  可按 rule_id 或批次反复调用
+when: |
+  「设计.生成规则」中已有生命周期为 `seed_only` 或 `seed_and_runtime` 的规则，
+  现在需要按该规则生成实际内容。
+when_not: |
+  规则生命周期为 `runtime_only` → 留到实际游玩中生成，本步不预生成。
+  没有对应生成规则，或规则缺少执行所需信息 → 返回「生成规则」补齐。
+  想修改 schema、约束或生命周期 → 返回「生成规则」，本步不改合同。
 boundary: |
-  本能力：具体可引用条目。
-  世界蓝图与人文地理：骨架与尺度，非逐条名片。
-```
-
-## opening
-
-```opening
+  本能力只做一件事：读取指定生成规则，按规则规定的数量、schema、生成步骤与约束，
+  生成可直接使用的实例。它不重新论证规则、不修改规则，也不扩写其它设计。
 ```
 
 ## task
 
 ```task
-钉清关键具体实例（人物/地点/物件等），写入 设计.具体实例。只保留服务体验与开局的条目。
-（待作者细写）
+你正在执行剧本中的「具体实例」步骤。产物写入「设计.具体实例」。
+
+本步只是「生成规则」的执行器：根据规则生成具体实例，不做第二轮设计。
+要执行的 `rule_id` 已在【本步参数】；禁止再问用户要生成什么或重新讨论规则。
+
+执行顺序：
+1. 从「设计.生成规则」找到 `params.rule_id` 对应规则。不存在、不是预生成生命周期或缺少执行所需信息时，停止并准确指出缺口。
+2. 确定本批数量：`params.count` 有明确数字时采用；否则完全按规则的「数量」决定。`params.batch_goal` 若有，只作为不违反规则的本批筛选条件。
+3. 按规则的「生成依据」和「生成步骤」生成实例。`records` 只使用规则 schema 声明的字段，填满所有必填字段，并遵守类型、枚举、边界、嵌套结构、硬约束、字段间约束、变化维度、禁止项和去重规则。
+4. 逐条按规则的「校验」检查；不合格的实例直接重生成，不把错误项或设计过程写进产物。
+5. 若已有「设计.具体实例」，按 `rule_id` 追加新批次；除非用户明确要求替换，不改动旧批次。
+6. 输出符合 output 的 JSON。
+
+若程序已发出默认问题：用户首答在「用户.worker答复」。禁止重复同一开场。
+
+summary：`具体实例 · {生成对象} · {本批数量}条`
 ```
 
 ## principles
 
 ```principles
-少而可用；每条要说清为何需要。
+1. 规则说什么就生成什么：不补字段、不改边界、不新增规则。
+2. 只交实例：`records` 放最终可用数据，不放 schema、解释、草稿或占位符。
+3. 先生成后自检：不合格项内部重做，只交通过规则校验的结果。
+4. 保持差异：在规则允许的变化维度内避免重复，不用变化破坏共同约束。
 ```
 
 ## probe
 
 ```probe
-（待作者细写）
+通常不追问，直接按规则生成。
+仅当规则使用 contextual 数量而现有参数和依赖无法算出数量时，询问缺失的地区、阶段或规模。
+若用户要求 schema 外内容，提示返回「生成规则」修改合同；不要在本步临时加字段。
 ```
 
 ## output
 
 ```output
 {
-  "人物": [{ "名": "…", "要点": "…", "为何需要": "…" }],
-  "地点": [],
-  "物件": [],
-  "其它": []
+  "batches": [
+    {
+      "batch_id": "稳定的英文 kebab-case id",
+      "rule_id": "来源生成规则 id",
+      "对象": "本批生成的内容类型",
+      "数量": 3,
+      "批次条件": ["本批额外筛选条件；没有则为空"],
+      "records": [
+        {
+          "这里直接使用来源规则的实际字段": "不得使用通用人物/地点/物件名片代替"
+        }
+      ]
+    }
+  ],
+  "增量说明": "本次新增或替换了哪个 batch_id"
 }
+
+`records` 的示意键必须被实际规则 schema 完整替换。不得把 schema 定义复制进 `records`。
 ```
 
 ## checklist
 
 ```checklist
-- [ ] 删掉某条会丢掉哪段体验？说不清则删
+- [ ] 是否执行了 params.rule_id 指向的预生成规则？
+- [ ] 数量是否来自 params.count 或规则本身？
+- [ ] records 是否完整符合 schema 及全部约束？
+- [ ] 是否只输出最终实例，没有混入规则解释或校验过程？
+- [ ] 是否保留未要求替换的已有批次？
+```
+
+## examples
+
+```examples
+好：
+- `heroine-design` 要求 1 条：直接生成 1 条完整女主记录，字段和值全部服从规则。
+- `major-npc` 要求 5 条：直接生成 5 名互不重复、满足阵营与地区约束的重要 NPC。
+
+坏：
+- 无视 schema，给实例补上“背景故事”等未声明字段。
+- 输出一段生成思路和校验报告，却没有直接给可用实例。
 ```

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

@@ -1,6 +1,7 @@
 # 生成规则
 
-> **状态：待完善** — 块格式见 `docs/world-simulator-modules.md`；范例见 `aesthetics-interaction`。
+> 能力文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。  
+> 写法说明：`docs/world-simulator-modules.md`；范例：`aesthetics-interaction`。
 
 ## meta
 
@@ -8,53 +9,184 @@
 name: 生成规则
 id: generation-rules
 artifact: 设计.生成规则
-declaration: 钉内容如何生成/推进的可执行规则（触发、约束、节奏），非散文设定
-when: 需要把「世界怎么动、内容怎么长出来」写成可执行约束时
-when_not: 仍在谈体验感受、尚未需要可执行规则时
+declaration: >
+  仅为重要且模型无法仅凭世界基底稳定生成的同类内容，定义可执行的生成规则、
+  严格数据格式与生命周期；可按生成对象反复调用
+when: |
+  上游体验、机制与世界基底已足以判断某类内容：
+  1. 它对实际游玩非常重要；并且
+  2. 模型仅凭现有上下文无法稳定产出符合期待、彼此一致且可供下游使用的结果。
+  两项同时成立时，才为该类对象建立专门生成规则。
+when_not: |
+  内容虽重要，但凭世界基底与常识即可稳定生成 → 不调用。
+  内容难生成，但只是装饰、偶尔出现或删掉不影响核心体验 → 不调用。
+  只想预先写一个普通人/地/物，且不需要先建立专门格式与生成约束 → 不调用。
+  只需定义变量在游玩中如何更新 → 变量设计与更新规则。
+  只需定义剧情、章节或世界如何推进 → 交给对应 Worker 或其它推进能力，不借本步泛化。
 boundary: |
-  本能力：触发、约束、节奏、可否随机等可执行规则。
-  变量设计与更新规则：字段与何时改值。
-  实现机制：落到哪些 worker/表来执行这些规则。
-```
-
-## opening
-
-```opening
+  本能力：为“一类格式相近的内容”定义生成合同，包括生成依据、字段 schema、
+  枚举值、数值上下界、约束、随机维度、校验方式与规则生命周期。
+  生成对象不限于人物，也可为怪物、装备、任务、职业、组织、事件等。
+  具体实例：执行本步中要求预生成的规则，产出符合合同的实际记录；本步不填实例数据。
+  世界蓝图与人文地理：提供可直接依赖的世界基底；本步不重写世界百科。
+  实现机制：说明某类内容为何支撑体验；本步先验证其必要性，再定义怎么生成。
+  变量设计与更新规则：定义游玩期状态如何变化；本步只约束实例生成时的数据类型与初始合法范围。
+  Worker 规格 / 细化终稿：决定谁在游玩期执行、哪些产物进入常驻上下文；本步只声明所需生命周期。
 ```
 
 ## task
 
 ```task
-钉清生成与推进规则，写入 设计.生成规则。须可被下游 worker/程序引用，禁止只写散文氛围。
-（待作者细写）
+你正在执行剧本中的「生成规则」步骤。产物写入「设计.生成规则」。
+
+本步不是泛用写作建议，也不是“凡是重要就做一张表”。调用目标已由编排期写入【本步参数】（至少含 target）；禁止再问「这一步生成什么」。
+
+执行顺序：
+1. 读取【本步参数】与依赖产物。`target` 决定本轮唯一生成对象族；不要顺手扩展到其它类别。若缺必填参数，停止产出并提示返回 design-flow 补参。
+2. 执行双门槛判断：
+   - 重要性门槛：没有专门生成合同，核心玩法、关键关系、长期一致性或必要数据接口是否会明显受损？
+   - 不可替代门槛：模型是否无法依靠世界基底、常识和普通提示稳定生成合格结果？
+   两项有任一不成立，输出“无需专门规则”的判断与理由，不为了完成步骤硬造 schema。
+3. 两项均成立时，从三种生命周期中选且只选一种（若 params.lifecycle_intent 已给且合理，优先采用；不合理则说明并 askUser）：
+   - `runtime_only`：仅游玩期动态生成。规则进入后续上下文，不要求「具体实例」预生成。
+   - `seed_only`：下一步由「具体实例」按规则生成；实例进入后续上下文，规则在完成生成与校验后丢弃。
+   - `seed_and_runtime`：下一步先生成种子实例；实例与规则都进入后续上下文，游玩期仍可按同一规则继续生成。
+4. 建立真正可执行的数据合同：
+   - 明确顶层 JSON 形状、单批数量或数量决定方式、每个字段是否必填。
+   - 每个字段固定类型。至少区分 `string`、`number`、`integer`、`boolean`、`enum`、`array`、`object`；不得只给示例值让下游猜类型。
+   - `enum` 必须同时给出允许值及各值含义；`number/integer` 必须给上下界，并说明边界含义或单位；`array` 必须定义元素类型与数量范围；`object` 必须继续定义子字段。
+   - 写清字段间约束、与世界基底的引用关系、禁止项、去重规则和一致性校验。
+5. 只有确实需要不可预测性时才定义随机维度；区分“允许变化的字段”和“不能随机破坏的约束”。随机不是省略设计。
+6. 若 params.rule_id 已给，优先用作本规则 id；否则生成稳定 kebab-case `rule_id`。若已有「设计.生成规则」，按 `rule_id` 增量更新或追加；不得无故重写其它对象的规则。
+7. 输出符合 output 的 JSON。规则本身不得夹带实际实例。
+
+若程序已发出默认问题：用户首答在「用户.worker答复」。禁止重复同一开场。只追问会改变必要性、生命周期或 schema 的信息。
+
+summary：
+- 建立规则：`生成规则 · {生成对象} · {仅动态|仅预生成|预生成并动态}`
+- 不建立规则：`生成规则 · {生成对象} · 无需专门规则`
 ```
 
 ## principles
 
 ```principles
-可执行优于文采；与体验禁忌对齐。
+1. 双门槛：必须“对游玩重要”且“基础上下文不足以稳定生成”同时成立。
+2. 反表格冲动：核心玩法是古董拍卖，不代表纯现代背景中的普通古董必须有专门规则；常识足够时直接生成。
+3. 一规则一对象族：怪物与装备若 schema、约束和用途不同，分次调用；不要做万能内容生成器。
+4. 格式也是规则：字段名、类型、枚举、上下界、嵌套结构与必填性都必须可校验。
+5. 生命周期先行：是否预生成、规则最终是否保留，必须在生成实例前决定。
+6. 规则服务差异：只固定影响体验和接口的字段；不要把所有可描写细节都结构化。
+7. 可追溯：每项关键约束应能指向世界基底、实现机制、体验禁忌或用户明确要求。
+8. 不混淆状态更新：好感度可在实例 schema 中规定为有界数字；何时增减、如何结算属于变量设计。
 ```
 
 ## probe
 
 ```probe
-（待作者细写）
+一轮 askUser 1～2 点；优先问会改变结论的分叉。禁止重问【本步参数】已钉的 target / rule_id。
+
+必要性不明：如果不做专门规则、只让模型按世界设定直接生成，最可能出现的不可接受结果是什么？
+生命周期不明且 params 未给：这些实例需要每局变化、固定为开局设定，还是固定一批后仍要继续随机补充？
+枚举不明：这个字段只能从哪些世界内类别中选择？是否允许“其它”？
+数值不明：上下界分别代表什么，生成时是否允许取到边界？
+数量不明：需要固定数量，还是由场景/规模决定？允许范围是多少？
+
+若用户的答案证明双门槛不成立，直接建议跳过，不再追问 schema。
 ```
 
 ## output
 
 ```output
 {
-  "触发": ["…"],
-  "约束": ["…"],
-  "节奏": "…",
-  "例外": ["…"]
+  "brief": "一句话：本轮判断与其服务的核心体验",
+  "必要性判断": {
+    "生成对象": "例：重要 NPC / 怪物 / 装备 / 任务 / 职业体系",
+    "对游玩的重要性": "没有专门规则会具体损失什么",
+    "基础生成的不足": "现有世界基底为何不足以稳定产出合格结果",
+    "结论": "建立专门规则|无需专门规则"
+  },
+  "rules": [
+    {
+      "rule_id": "稳定的英文 kebab-case id",
+      "对象": "该规则生成什么",
+      "生命周期": "runtime_only|seed_only|seed_and_runtime",
+      "上下文策略": {
+        "预生成实例": true,
+        "保留规则到游玩期": false,
+        "保留实例到游玩期": true
+      },
+      "生成依据": ["引用的上游产物、世界事实或用户要求"],
+      "数量": {
+        "模式": "fixed|range|contextual",
+        "值": 1,
+        "最小": 1,
+        "最大": 1,
+        "决定规则": "contextual 时必填"
+      },
+      "输出合同": {
+        "格式": "JSON",
+        "顶层": "array",
+        "schema": {
+          "字段名": {
+            "type": "string|number|integer|boolean|enum|array|object",
+            "required": true,
+            "description": "字段语义",
+            "allowed_values": [
+              { "value": "枚举值", "meaning": "含义与适用边界" }
+            ],
+            "minimum": 0,
+            "maximum": 100,
+            "items": { "type": "string" },
+            "min_items": 1,
+            "max_items": 3,
+            "properties": {}
+          }
+        }
+      },
+      "生成步骤": ["按什么顺序决定字段，如何利用上游依据"],
+      "硬约束": ["任何实例都不得违反的条件"],
+      "字段间约束": ["例：阵营=A 时，权限等级不得低于 3"],
+      "变化维度": ["允许随机或变化的部分；不需要随机则为空"],
+      "禁止项": ["即使随机抽到也不得出现的组合或内容"],
+      "去重规则": ["同批及跨批如何避免同质化或重复"],
+      "校验": ["类型、枚举、边界、世界一致性与体验一致性检查"]
+    }
+  ],
+  "增量说明": "相对已有规则新增或修改了什么",
+  "开放问题": ["仅保留会阻止规则执行的问题"]
 }
+
+当结论为「无需专门规则」时，省略 `rules`，并在 `brief` 中说明应直接依赖哪些现有世界基底生成。
+schema 中只保留实际字段适用的类型属性：例如非枚举字段不写 `allowed_values`，非数字字段不写 `minimum/maximum`。
 ```
 
 ## checklist
 
 ```checklist
-- [ ] 规则是否可被执行/检查，而非纯描写？
-- [ ] 是否与体验边界禁忌冲突？
+- [ ] 重要性与基础生成不足是否分别举证，且两项都成立？
+- [ ] 是否因为“玩法重要”就误给常识足够的内容建表？
+- [ ] 生命周期是否在三种模式中明确唯一，布尔策略与之相符？
+- [ ] 每个字段是否有明确类型、必填性和语义？
+- [ ] enum 是否给全允许值与含义，数字是否给上下界，嵌套类型是否定义完整？
+- [ ] 是否写清字段间约束、禁止项、去重与校验？
+- [ ] 是否把实际实例、变量更新规则、剧情推进规则或 Worker 规格混入本步？
+- [ ] 是否只覆盖本轮对象族，并保留其它已有 rule_id？
+```
+
+## examples
+
+```examples
+应建立：
+- 怪物是核心战斗资源，需要每局变化，且世界有独特生态与战斗接口；使用 `runtime_only`，固定属性 schema、生态枚举、数值边界与组合禁忌。
+- 单女主必须承载特定关系体验，直接写人设容易遗漏关键切面；使用 `seed_only`，下一步生成女主后丢弃规则。
+- 重要 NPC 需要开局已有一批，后续也会随地区开放继续出现；使用 `seed_and_runtime`。
+
+不应建立：
+- 纯现代都市拍卖玩法中的普通古董；即使古董很重要，只要现实常识与世界基底足以直接生成，就不值得专门维护规则。
+- 只在背景里出现一次的路边摊菜单；即使模型可能写得普通，也不影响核心体验。
+
+坏：
+- 只写“人物要立体、装备要有趣”，没有 JSON schema 与可校验约束。
+- 枚举字段写“阵营：字符串”，却不生成允许的阵营项。
+- 好感度写“0～100”，又在本步编写每轮加减公式，侵入变量更新能力。
 ```

skills/dialogue/world-simulator/modules/narrative/prompt.md

@@ -1,6 +1,7 @@
 # 叙事指南
 
-> **状态：待完善** — 块格式见 `docs/world-simulator-modules.md`；范例见 `aesthetics-interaction`。
+> 能力文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。  
+> 写法说明：`docs/world-simulator-modules.md`；范例：`aesthetics-interaction`。
 
 ## meta
 
@@ -8,49 +9,101 @@
 name: 叙事指南
 id: narrative
 artifact: 设计.叙事指南
-declaration: 世界/助手态度与体验边界（不等于文风；契约已写清的态度勿重复问卷）
-when: 需要钉世界/助手态度口径，且美学纲领与交互范式未写清或需单独收口时
-when_not: 契约里已写清态度/禁忌，仅重复问卷
-boundary: 不等于文风；呈现与站位优先读 设计.美学纲领与交互范式
+declaration: >
+  世界/助手态度与体验边界（不等于文风；契约已写清的态度勿重复问卷）
+when: |
+  需要单独钉清「世界/助手如何说话、如何取舍信息、如何对待用户情绪」时；
+  或美学纲领与交互范式里态度仍过粗、下游演员会飘时。
+when_not: |
+  美学纲领与交互范式已写清态度/禁忌，用户未要求加细 → 不要重复问卷。
+  用户只要文风辞藻样本、不要态度边界 → 可放入常驻上下文短句，不必强开本步。
+  排版/回复块结构 → 设计回复格式。
+boundary: |
+  本能力：态度、信息取舍、体验边界、焦点偏好（给转述/写手演员的稳定口径）。
+  不等于文风词典：少堆形容词；多写「遇到 X 时怎么处理」。
+  美学纲领与交互范式：站位、呈现、核心体验、轮转——已写清的勿重问。
+  生成规则：可执行推进规则；本步不定章结构算法。
+  设计回复格式：块结构与拼接顺序。
 ```
 
 ## opening
 
 ```opening
+用几句话说明「系统说话时该像什么人」（想到什么写什么）：
+
+1. 态度：冷静如实 / 偏袒主角 / 狠心推进 / 温柔留余地 / 其它？
+2. 信息：用户不知道的世界内情，默认藏多少？可以剧透结构吗？
+3. 边界：什么绝对不写或不怎么写？（已有禁忌可写「同体验契约」）
+
+若上游契约已够用，可回复「按美学纲领，只补……」。
 ```
 
 ## task
 
 ```task
-钉清世界/助手态度与体验边界。写入 设计.叙事指南。
-依赖已验收的美学纲领与交互范式时先读再写；已写清的勿重复问卷。
-（待作者细写）
+你正在执行剧本中的「叙事指南」步骤。产物写入「设计.叙事指南」。
+
+先读「设计.美学纲领与交互范式」：已写清的态度/禁忌直接继承，只补缺口。
+
+执行顺序：
+1. 复述已确认的体验内核与呈现；不重定站位。
+2. 钉态度、信息策略、焦点、边界；写成下游可挂载的短规则，而非散文赏析。
+3. 与体验禁忌冲突时以体验禁忌为准，并在产物里点明。
+4. 输出符合 output 的 JSON。
+
+若程序已发出默认问题：禁止重复同一开场。
+
+summary：`叙事指南 · …`（点题态度，非「文学性」空话）。
 ```
 
 ## principles
 
 ```principles
-（待作者细写）
+1. 态度是行为规则，不是形容词堆砌。
+2. 不重复问卷：契约已有的字段引用即可。
+3. 服务体验：狠心或温柔都必须能指向核心感受。
+4. 写手模式：可写「助手如何给大纲意见 / 如何改稿语气」，仍避免空泛文风课。
+5. 缩减：三条管用口径优于一页风格指南。
 ```
 
 ## probe
 
 ```probe
-（待作者细写）
+一轮 1～2 点。
+
+缺态度：失败时系统更像「如实报损」还是「帮用户找补救」？
+缺信息：用户是否允许「角色知道但用户暂不知」的悬置？
+与禁忌冲突：用户既要无虐又要残酷真实——以哪边为先？
 ```
 
 ## output
 
 ```output
 {
+  "brief": "一句话：叙事口径服务什么体验",
   "态度": "…",
+  "信息策略": "…",
+  "焦点": "…",
   "边界": ["…"],
-  "焦点": "…"
+  "遇到冲突时": "优先保全…",
+  "继承自体验契约": ["已直接采用的字段"],
+  "开放问题": ["…"]
 }
 ```
 
 ## checklist
 
 ```checklist
-- [ ] 与美学纲领与交互范式不重复、不矛盾
+- [ ] 与美学纲领与交互范式不重复盘问、不矛盾？
+- [ ] 是否可被演员当规则执行（非纯文风赏析）？
+- [ ] 是否误写成回复块结构或生成规则？
+```
+
+## examples
+
+```examples
+好：
+- 「如实推进代价；不替用户道德排雷；悬念可藏事实不可藏规则。」
+坏：
+- 「要有诗意、电影感、高级感……」无可执行口径
 ```

skills/dialogue/world-simulator/modules/refine/prompt.md

@@ -1,6 +1,8 @@
 # 细化终稿
 
-> **状态：待完善** — 块格式见 `docs/world-simulator-modules.md`。
+> 能力文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。  
+> 写法说明：`docs/world-simulator-modules.md`；规格字段见 `docs/skill-design-guide.md`。  
+> 本步产物 tag 为 **`设计.worker集`**（可进游玩的实例规格）。
 
 ## meta
 
@@ -8,28 +10,82 @@
 name: 细化终稿
 id: refine
 artifact: 设计.worker集
-declaration: 钉死关键前提、表与副作用，收成可进游玩的规格
-when: 前面步骤已大致谈清，需要收成可进游玩的 Worker 集时
-boundary: 产出设计.worker集 JSON；进 play 由用户手动
+declaration: >
+  钉死关键前提、表与副作用，收成可进游玩的规格
+when: |
+  前面能力已大致谈清（至少有体验契约，且演员职责可说清），
+  需要收成可进游玩的「设计.worker集」JSON 时；
+  编排应将本局流程 status 导向 closed。
+when_not: |
+  体验站位未定、或关键演员仍完全空白时，不要用本步代替上游。
+  用户只想改某一个演员细节 → 可先 Worker 规格，再本步合并。
+boundary: |
+  本能力：合并上游产物，钉死不能瞎发挥的前提，输出完整「设计.worker集」JSON（含 interaction、workers、resident_context、tables 等）。
+  进 play 由用户手动决定；本步不自动切游玩。
+  Worker 规格：分步钉演员；本步负责合并与终稿一致性。
+  美学纲领与交互范式等：只读引用，不重做问卷（矛盾处才问）。
+  开局·开场白：可选后续步骤，本步可用 design_end.opening 标记是否建议。
+```
+
+## opening
+
+```opening
+准备收成可进游玩的规格。请确认或补充：
+
+1. 还有没有「绝不能瞎发挥」的前提要钉死？（一句一条）
+2. 游玩时最少需要哪些演员上场？（用中文名即可）
+3. 要不要表/状态栏？（不要就写「不要」）
+
+若前面产物已经够用，可直接回复「按已有产物收成」。
 ```
 
 ## task
 
 ```task
-钉死关键前提；表/副作用；收成可进游玩的设计.worker集 JSON。
-（待作者细写）
+你正在执行剧本中的「细化终稿」步骤。产物必须写入 **设计.worker集**，且为 **JSON**（不要 YAML）。
+
+本步是收成，不是再开一场题材发明。优先合并：
+- 设计.美学纲领与交互范式 → interaction / experience_check / 呈现
+- 设计.worker规格 → workers[]
+- 设计.叙事指南 / 生成规则 / 具体实例 / 世界蓝图 / 实现机制等 → resident_context 挂载或 core_premises
+- 设计.变量* / 状态栏 / 拓扑 → tables / 显隐说明（有则写，无则省略）
+
+执行顺序：
+1. 忠实复述已确认的站位、体验内核、禁忌；矛盾处 askUser 1 点，勿静默覆盖。
+2. 组装 workers[]：每个含 ref、name（中文）、duty、rationale、acceptance；缺省 context/outputs 可标示留给模板合并，但 acceptance 必须写出。
+3. resident_context：把稳定长文（叙事态度、关键规则摘要、禁忌）挂到需要的 workers；不要把全过程聊天塞进去。
+4. tables：仅钉体验真正依赖的字段与副作用；无则 `tables` 省略或空 schemas。
+5. core_premises：不能瞎发挥的短列表。
+6. design_end：如 `{ "opening": "optional" }` 表示可随后跑开场白。
+7. 输出完整 JSON；summary：`细化终稿 · Worker集 · N 演员 · …`
+
+若程序已发出默认问题：禁止重复同一开场。
+
+进游玩不在本步完成；用户验收本产物后，由用户手动进入游玩。
 ```
 
 ## principles
 
 ```principles
-只钉不能瞎发挥又对体验关键的东西。
+1. 合并优于重写：上游已验收内容优先进入规格，禁止无故改写体验内核。
+2. 每个面向用户的可读终稿点必须有 acceptance（review）；中间层 continue。
+3. 正推缩减：能不建表就不建；能常驻一段话解决的不要新演员。
+4. 写手路径最小可运行：outline + chapter-writer（或用户只要分段写手）；扮演路径按已钉演员。
+5. 键名稳定：workers[].ref 英文 kebab；name 中文给人看。
+6. 禁止题材固定套件；禁止在本步发明新 tool。
+7. 未决进 open_questions，不要假完备。
 ```
 
 ## probe
 
 ```probe
-（待作者细写）
+一轮 1～2 点，只问会挡住收成的矛盾：
+
+- 上游演员列表与用户本轮说法冲突时，以谁为准？
+- 终稿演员是「每轮世界+叙事」还是「先纲后章」？
+- 有表需求但字段未定：先不要表，还是先钉 1～2 个关键字段？
+
+能按已有产物收成则不要为「完美」继续盘问。
 ```
 
 ## output
@@ -37,15 +93,81 @@ boundary: 产出设计.worker集 JSON；进 play 由用户手动
 ```output
 {
   "version": 1,
-  "interaction": {},
-  "workers": [],
-  "resident_context": [],
-  "tables": {}
+  "interaction": {
+    "user_stance": "…",
+    "system_role": "…",
+    "output": "…",
+    "turn_shape": "对话回合|助手分段|…"
+  },
+  "experience_check": {
+    "user_relation": "…",
+    "focus": "…",
+    "satisfaction_source": "…"
+  },
+  "workers": [
+    {
+      "name": "章节正文",
+      "ref": "chapter-writer",
+      "duty": "…",
+      "when": "…",
+      "rationale": "删掉则…",
+      "acceptance": "review",
+      "context": {
+        "static": ["设计.worker集", "大纲.当前"],
+        "dynamic": ["用户.最新输入"]
+      },
+      "outputs": ["正文.当前段", "正文.已完成"]
+    }
+  ],
+  "resident_context": [
+    {
+      "id": "experience-contract",
+      "position": "static",
+      "content": "从上游压缩的稳定句（体验/禁忌/态度）",
+      "mount": ["chapter-writer"]
+    }
+  ],
+  "tables": {
+    "schemas": [],
+    "side_effects": []
+  },
+  "core_premises": ["…"],
+  "narrative_guide": "可选短摘要；长文优先走 resident_context",
+  "input_protocol": {
+    "parens": "() 元要求",
+    "quotes": "\"\" 角色对白",
+    "bare": "无包裹按站位解释"
+  },
+  "design_end": {
+    "opening": "optional"
+  },
+  "open_questions": ["…"]
 }
 ```
 
+必须是可解析 JSON。无表可省略 tables 或留空数组。每个 workers[] 元素必须有 acceptance。
+
 ## checklist
 
 ```checklist
-- [ ] 验收复述含站位、体验核心、worker/表、为何没有某件
+- [ ] 是否 JSON 且可解析为设计.worker集？
+- [ ] interaction 站位/轮转是否与美学纲领一致？
+- [ ] 每个 worker 是否有 name、ref、duty、rationale、acceptance？
+- [ ] 删掉任一 worker 的 rationale 是否说得清？
+- [ ] 有没有把聊天过程塞进常驻上下文？
+- [ ] 有没有题材默认灌入用户未要的演员/表？
+- [ ] 验收复述能否一句话说清：站位、体验核心、演员、为何没有某件？
+```
+
+## examples
+
+```examples
+好：
+- 扩写：interaction.turn_shape=助手分段；workers=outline(continue/review)+chapter-writer(review)；resident 挂爽点与禁忌。
+- 扮演：world-simulator(continue)+narrator(review)；core_premises 含变造点。
+
+坏：
+- 输出 YAML 或半散文
+- workers 无 acceptance
+- 无视上游，按「标准世界模拟套件」重写
 ```

skills/dialogue/world-simulator/modules/worker-spec/prompt.md

@@ -1,6 +1,8 @@
 # Worker 规格
 
-> **状态：待完善** — 块格式见 `docs/world-simulator-modules.md`。
+> 能力文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。  
+> 写法说明：`docs/world-simulator-modules.md`；范例：`aesthetics-interaction`。  
+> 可选默认契约见 `worker-templates/`（缺省合并用，非本步全文）。
 
 ## meta
 
@@ -8,45 +10,126 @@
 name: Worker 规格
 id: worker-spec
 artifact: 设计.worker规格
-declaration: 钉一个游玩期执行单元（职责、读写、挂载）
-when: 需要钉清某个执行单元的契约时
-boundary: 一次一个为宜；终稿合并进 设计.worker集
+declaration: >
+  钉一个游玩期执行单元（职责、读写、挂载）；多演员时可多次调用
+when: |
+  已能说出「游玩时谁上场做什么」，需要把某一个演员钉成可调度契约时；
+  或多演员需分次钉清时（本能力可反复）。
+when_not: |
+  体验/机制仍混沌，还说不清删掉谁会坏体验时 → 先上游能力。
+  已在收成「细化终稿」且只需合并已有规格时 → 交给细化终稿，勿重复问卷。
+boundary: |
+  本能力：一次（或本步焦点内）钉清一个游玩期执行单元：中文名、ref、职责、何时上场、读写 tag、验收点、为何需要。
+  产物写入「设计.worker规格」（可含累积列表）；最终合并进「设计.worker集」由「细化终稿」完成。
+  细化终稿：收成完整 Worker 集、表、常驻上下文；本步不假装交终稿。
+  拓扑图谱：多演员依赖与数据流总图；本步可写本单元读写，不画全图。
+  生成规则 / 叙事指南：规则与态度正文；本步只声明挂载哪些 tag，不重写全文。
+```
+
+## opening
+
+```opening
+先点名「下一个要钉的演员」（一个即可）：
+
+1. 中文称呼：TA 在游玩里叫什么？（例：世界推进、叙事转述、大纲、章节正文）
+2. 职责一句话：删掉 TA 会丢掉哪段体验？
+3. 何时上场：每轮？用户点名写章时？某条件触发？
+
+若你已有多个演员想法，先写最核心的一个；其余可再跑本能力。
 ```
 
 ## task
 
 ```task
-一次钉一个游玩期执行单元：中文名、ref、职责、读写、挂载。写入 设计.worker规格。
-（待作者细写）
+你正在执行剧本中的「Worker 规格」步骤。产物写入「设计.worker规格」。
+
+一次 design-step 以钉清**一个**游玩期执行单元为主；若用户一次抛出多个且关系简单，可写入 `actors` 数组但须逐个写清 rationale，并在 summary 标明本步焦点。
+
+执行顺序：
+1. 读依赖产物与体验契约；正推「需要谁」——禁止题材默认演员套餐。
+2. 若已有「设计.worker规格」，增量：同 ref 更新；新 ref 追加；不要无故删除用户已验收条目（除非用户要求改）。
+3. 为该单元填写：name（中文）、ref（英文 kebab，可与 worker-templates 对齐）、duty、when、rationale、acceptance、context/outputs 建议。
+4. acceptance：面向用户的可读终稿倾向 `review`；纯中间裁决/整理倾向 `continue`；吃不准就 ask_user。
+5. ref 可参考包内模板（如 narrator、world-simulator、outline、chapter-writer），但必须以本局体验为准，勿强行两端都上。
+6. 输出符合 output 的 JSON。
+
+若程序已发出默认问题：禁止重复同一开场。
+
+summary：`Worker 规格 · {中文名} · …`
 ```
 
 ## principles
 
 ```principles
-（待作者细写）
+1. 删掉检验：说不清「丢掉哪段体验」的演员不要。
+2. 正推：体验 → 手段 → 演员；禁止「世界模拟就一定要 world-simulator + narrator」。
+3. 写手/分段常见最小集：大纲/细纲（outline）+ 章节正文（chapter-writer）；按需加减。
+4. 扮演/世界推进常见：世界裁决 + 叙事转述；能合并则问用户是否合并。
+5. name 给人看，ref 给机器；二者成对出现。
+6. 本步不写完整表 schema、不写整份 Worker 集终稿。
+7. 常驻上下文挂载只点名「需要挂哪些已有产物 tag」，不在本步粘贴长文。
 ```
 
 ## probe
 
 ```probe
-（待作者细写）
+一轮 1～2 点。
+
+缺验收点：本演员产出是「给用户读的一段」还是「给下一演员的中间结果」？
+缺 ref：更接近包内哪个模板职责？（给中文选项，勿逼用户记英文）
+多演员纠结：能否合并成一个？合并会损失什么？
+写手路径：是否需要「先大纲后正文」两个演员，还是只要分段写手？
 ```
 
 ## output
 
 ```output
 {
-  "name": "叙事转述",
-  "ref": "narrator",
-  "职责": "…",
-  "读取": ["…"],
-  "写入": ["…"],
-  "为何需要": "…"
+  "brief": "一句话：本步钉的演员如何服务体验",
+  "actors": [
+    {
+      "name": "叙事转述",
+      "ref": "narrator",
+      "duty": "…",
+      "when": "…",
+      "rationale": "删掉则…",
+      "acceptance": "review",
+      "context": {
+        "static": ["设计.worker集"],
+        "dynamic": ["用户.最新输入"]
+      },
+      "outputs": ["输出.用户展示"],
+      "presentation": {
+        "tone": "可选；转述类可填"
+      }
+    }
+  ],
+  "增量说明": "相对旧稿新增/改了哪个 ref",
+  "开放问题": ["…"]
 }
 ```
 
+`acceptance` 只能是 `review` 或 `continue`。未知字段省略。
+
 ## checklist
 
 ```checklist
-- [ ] 删掉该 worker 会丢掉哪段体验？
+- [ ] 每个演员能否通过删掉检验？
+- [ ] name/ref 是否成对？acceptance 是否写出？
+- [ ] 是否误交完整 设计.worker集 或表结构？
+- [ ] 是否题材默认套演员？
+- [ ] 增量是否误删已有条目？
+```
+
+## examples
+
+```examples
+好：
+- 扩写：先钉「大纲/细纲」outline（continue 或 review 按用户是否要验大纲），再另一步钉「章节正文」chapter-writer（review）。
+- 扮演：世界推进 continue + 叙事转述 review。
+
+坏：
+- 一次甩出 8 个演员且无 rationale
+- 只写英文 id 给用户看
+- 本步直接输出整份 version:1 Worker 集冒充终稿
 ```