writing-agent/skills/dialogue/world-simulator/modules/random-range/prompt.md

随机范围整理

技能文档。程序只切割下方 fence 块；## 标题仅供人读。
产物外壳：docs/context-fragment-design.md。
本步把上游已定的检定/对抗/掷骰需求，收成一份程序可插入的随机值范围表；不发明新裁定法则。
游玩期：程序按本表每轮往消息里塞备用随机数（前端折叠隐藏、用户看不见，发给 AI 时仍在上下文）；主世界层直接用表中本次数，不再单独「机遇裁定」槽。

meta

name: 随机范围整理
id: random-range
artifact: 设计.随机范围整理
declaration: >
  上游已有检定/对抗/掷骰需求时：汇总全部要用的随机项与取值范围（含表达式），供程序每轮插入备用随机数；排在正文组成之前
when: |
  机制/生成规则/变量/叙事等上游已出现需要随机数的内容（对抗、检定、抽签、伤害区间等），且尚未收成一份范围表。
  排在「正文组成」之前（通常紧挨其前；回复呈现可并行或略前）。
when_not: |
  全程不靠随机数推进 → 不排。
  还在定「怎么裁定 / 公式本身」→ 先「实现机制」「生成规则」或「变量设计与更新规则」；本步只汇总已定需求。
  只谈前端怎么藏、选壳美化 → 「正文组成」。
  只谈每轮可见区域与字数 → 「回复呈现」。
boundary: |
  本技能：一份清单——每项随机用途、范围或表达式（如力量*5～*10、敏捷检定 1～100）、本轮建议备用条数。
  不写新裁定法则、不写骰子剧情；法则来自上游，此处只整理成程序可读范围。
  游玩拓扑：不再开「机遇裁定」槽；真随机靠本表 + 程序插入上下文。
  正文组成：负责把隐藏备用区接到壳/消息里——本步只交「要插什么数」。
feeds: gm,narrator

opening

把本局所有要用的随机数收成一张表（想到什么写什么）：

1. 上游里哪些地方要掷 / 检定 / 抽区间？（对抗、伤害、事件抽签……）
2. 每一项的取值范围或表达式？（例：敏捷检定 1～100；攻击伤害＝力量×5～×10）
3. 每轮消息大概要预先塞几条备用？（够用即可，不要灌爆）

task

你正在执行「随机范围整理」。产物必须是 **context-fragment.v1** JSON，写入「设计.随机范围整理」。

本步只做一件事：把上游已定、游玩时会用到的随机需求，整理成程序可插入的范围表。
禁止重议「要不要检定」「公式对不对」——缺则追问上游或写进开放问题；本步不发明新法则。

执行顺序：
1. 扫机制 / 生成规则 / 变量 / 叙事 / 美学：列出所有「需要随机数才能裁定」的点。
2. 每项写清：用途短名、范围或表达式（相对变量/表字段时写清引用）、单位（整数 d100 / 闭区间等）。
3. 钉本轮建议备用条数（按项或全局）；够本轮最坏情况即可。
4. 无随机需求则本步不应被排；若误进：正文写空清单并说明「无需随机」。
5. 自评 + 追问；输出 JSON。

summary：`随机范围整理 · {项数或主要用途}`。

principles

1. 只汇总，不定新法。范围与表达式必须能追溯到上游已验收产物。
2. 表达式写给人与程序都能读：`力量*5～*10`、`1～100`、`池权重抽 1`——忌散文。
3. 一项一类用途；不要把「战斗」糊成一条却含三种掷法。
4. 备用条数服务「本轮上下文预插入」；宁少可补，勿一次塞上百。
5. 不输出机遇裁定槽、不写 chance tool 调用说明。

probe

每轮 1～2 点：某项范围是否仍是散文；表达式引用的变量/表是否未在上游出现；有无漏掉已声明的检定。
不追问：壳怎么藏、CSS、文风、要不要主世界层。
全程明显无随机：确认不排即可，不必硬凑表。

output

{
  "schema": "context-fragment.v1",
  "技能": "随机范围整理",
  "brief": "一句话：收了哪些随机项",
  "mount": ["world-simulator", "narrator"],
  "稳变": "stable",
  "正文": {
    "依据": ["上游机制/生成规则/变量/叙事中与随机相关的要点"],
    "插入意图": "程序按本表每轮往消息隐藏区插入备用随机数；裁决时只用上下文已有数，不另开机遇槽",
    "项": [
      {
        "id": "agility-check",
        "用途": "敏捷检定",
        "范围": "1～100",
        "表达式": null,
        "来源": "实现机制·… / 变量·…",
        "每轮备用条数": 3
      },
      {
        "id": "attack-damage",
        "用途": "攻击伤害",
        "范围": null,
        "表达式": "力量*5～*10",
        "来源": "变量设计·力量 / 机制·对抗",
        "每轮备用条数": 2
      }
    ],
    "全局备用上限": "可选；防止灌爆上下文的软上限"
  },
  "自评": {
    "维度": [
      { "名": "覆盖", "分数": 8, "说明": "上游随机点是否收齐" },
      { "名": "可执行", "分数": 8, "说明": "范围/表达式是否可直接插数" }
    ],
    "薄弱点": ""
  },
  "追问": { "导语": "", "题目": [] },
  "开放问题": []
}

硬规则：合法 JSON；项 可 []（仅当误排且确认无随机）；有项则每项须有用途 +（范围或表达式至少一者）；禁止 order；summary 见 task。

checklist

- [ ] 每项都能对上上游，没有本步新发明的裁定？
- [ ] 范围/表达式短且可插数？
- [ ] 未要求机遇裁定槽或 chance tool？
- [ ] 排在正文组成之前的意图是否写进 brief/插入意图？

examples

好：两项——敏捷 1～100（备用 3）；攻击伤害 力量*5～*10（备用 2）；插入意图写清隐藏备用区。
坏：在本步新写一套战斗规则；或只写「战斗要掷骰」无范围；或指引去开 play_slots.chance。