design-review

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,workflow,system_overrides

已在上方解析——照此使用；--review 会覆盖 review_mode。--depth 是同一标志在 1.1 之前的名称：将 --depth <mode> 与 --review <mode> 完全等同处理，并说明它已更名一次。若两者同时出现，以 --review 为准，忽略 --depth——请说明这一点。没有配置块 → 使用 .claude/docs/config-resolution.md 中的默认值。

设计评审

阶段 0：解析参数

完整的检查模式请参阅 .claude/docs/director-gates.md。各项门禁的定义位于 .claude/docs/director-gates/[gate-id].md — 派生的 Agent 会读取自己的门禁文件；不要在父会话中读取。

每次调用 AskUserQuestion 都遵循 .claude/docs/automation-modes.md （协作模式始终询问 · 引导模式仅询问重大事项 · 自主模式记录后继续； automation_always_ask 类别始终询问）。

workflow 指正在评审的 GDD 所用的工作流——如果配置块列出了 <system> 的 system_overrides 行，则使用该行；否则使用项目值。验证范围依照层级：

• full — 验证全部 8 个章节；任何缺失章节都会阻止批准。
• standard — 缺失以下 5 个必需章节时会阻止批准：Overview、Detailed Rules、Edge Cases、 Dependencies、Acceptance Criteria；仅当系统定义了数值规则（速率、曲线、阈值、成本等）时，Formulas 才是必需章节（类别仅作提示，并非判断依据）；Player Fantasy 和 Tuning Knobs 仅提供参考（发出警告，但绝不阻止批准），除非 workflow_overrides 要求提供。
• minimal — 不要求提供 GDD；如果存在，则以建议性方式验证这 5 个标准章节。

解析后的模式决定本次评审的详尽程度：

• full：完整评审 — 所有阶段 + 委派给专家 Agent（阶段 3b）
• lean：所有阶段，不使用专家 Agent — 更快，单会话分析
• solo：仅阶段 1-4，不委派、不提示阶段 5 后续步骤 — 用于从另一项技能内部调用时

---

阶段 1：加载文档

先检查是否有更新——重新评审未更改的文档需要完整成本，却会得出相同结论。 运行：

Bash: bash .claude/scripts/review-receipts.sh check "design/gdd/reviews/[doc-name]-review-log.md" "[target-doc-path]" "design/registry/entities.yaml" ".claude/skills/design-review/SKILL.md"

检查中包含注册表，是因为本次评审会参考它来核对跨文档事实——针对已更改的注册表评审未更改的 GDD，可能得出不同结论，因此只有在每一行都显示 UNCHANGED 时，跳过才安全（从未存在过的注册表不会出现在输出中，也不会妨碍跳过）。检查中也包含此技能文件，因为技能文件发生更改会导致评审方式不同。检查还会比较日志中记录的其他所有文件——先前评审读取的相关 GDD、概念文档或简报，以及叙事文件——并对不再存在的文件打印 GONE:。

然后读取最新条目的 Review mode: 行。只有当该条目的模式与当前解析出的模式相同或更深入（full > lean > solo），且工作流相同或更深入（full > standard > minimal）时，该评审才涵盖本次运行。没有此行的条目是在该行存在之前写入的，不涵盖任何内容。

• 全部为 UNCHANGED，且日志的最新条目包含评审结论——请将其告知用户： “本文档与上次于 [date] 进行的评审字节完全一致（[mode] 评审，结论：[verdict]）。” 如果该结论为 APPROVED，且该评审涵盖本次运行，请通过 AskUserQuestion 提供选项： [A] 使用之前的评审结论（推荐） / [B] 仍然重新评审 — guided 选择 [A] 并注明；autonomous 通过 log_decision 记录并使用之前的评审结论。如果结论为 APPROVED，但当前要求的评审比日志中的评审更深入，请说明——“之前进行的是 [mode] 评审，工作流 [tier]；本次要求进行 [tier] 级别的 [mode] 评审。”——并提供选项 [A] 按 [mode] 重新评审（推荐） / [B] 使用之前的 [mode] 评审结论；guided 和 autonomous 均重新评审（autonomous 通过 log_decision 记录）。如果结论为 NEEDS REVISION 或 MAJOR REVISION NEEDED，请明确说明：自评审未通过后，文档没有发生变化——之前的发现仍然成立；下一步应修改文档，而不是重新评审。提供选项以显示日志中的之前发现。
• 目标文档和本技能的文件均为 UNCHANGED，只有注册表或其他带戳的跨文档文件为 CHANGED、NEW 或 GONE——除了跨文档事实之外，之前的结论仍然成立：根据变更文件重新核实文档中的值，并重新给出结论；如果出现冲突，或之前的评审不涵盖本次运行，则升级为完整重新评审。
• 目标文档或本技能的文件为 CHANGED 或 NEW，或 RECEIPT: NONE——按下文进行完整评审。不要提供跳过阅读或重新分析未变更部分的局部／增量重新评审。 仅针对某个部分进行重新评审会漏掉完整评审能够发现的缺陷，而且几乎省不了时间。 “自上次评审后未变更”仅表示与当时评审的内容字节完全一致——这并不能说明上次评审本身是否完整；即使指示要求扫描全部内容，注意力仍会局限于标记出的变更。

完整阅读目标设计文档。本步骤需要完整的 GDD：使用 Grep 工具按标题分段阅读（通过内容模式查找 ^#），因为超过 40 KB 的整文件 Read 会被拒绝。阅读 CLAUDE.md，了解项目背景和标准。

核实跨文档事实时，优先查阅注册表，而不是其他 GDD。 如果 design/registry/entities.yaml 存在，且列出了该系统的条目，请对其运行 grep——这些是已确立的事实，本 GDD 不得与之矛盾；查阅这些条目可以替代阅读其他 GDD 来重新查找事实：

Grep pattern="source: design/gdd/[system].md" path="design/registry/entities.yaml" output_mode="content" -A 6
Grep pattern="design/gdd/[system].md" path="design/registry/entities.yaml" output_mode="content" -B 8

第一条命令查找该系统所属的条目——-A 6 上下文会包含它们的 referenced_by: 块。第二条命令查找引用该系统的条目——referenced_by: 是一个块序列（键及其路径位于不同的行），因此要使用 -B 8 上下文匹配路径，以便看到所属条目，而不是使用 referenced_by.*name 这种单行写法（它永远无法匹配块形式）。

如果 design/registry/entities.yaml 不存在，或未列出该系统的任何条目——该文件随项目提供时是空存根，因此在 /design-system 填充它之前，这就是默认情况——请改为阅读目标文档 Dependencies 部分中列出的相关 GDD。阅读范围仅限这些文档，不要扩展到所有“可能相关”的内容。不要对 design/gdd/ 进行通配符读取。

依赖图验证： 对 Dependencies 部分列出的每个系统，使用 Glob 检查其 GDD 文件是否存在于 design/gdd/ 中。标记尚不存在的文件——这些是下游作者会遇到的失效引用。

世界观／叙事一致性： 如果 design/gdd/game-concept.md（或在 rigor: minimal 时使用一页式概要 design/game-brief.md）或 design/narrative/ 中的任何文件存在，请阅读。注意本 GDD 中与既定世界规则、基调或设计支柱相矛盾的机制选择。在 Phase 3b 中将这些背景信息传递给 game-designer。 先前审查检查： 检查 design/gdd/reviews/[doc-name]-review-log.md 是否存在。如果存在，阅读最新条目——记录给出的结论和列出的阻塞项。本次会话是复审；请跟踪先前的问题是否已解决。

---

第 2 阶段：完整性检查

步骤 2a——确定性地收集各章节是否存在（不读取文档）：

Bash: bash .claude/scripts/gdd-structure-check.sh [target-doc-path]

它会打印一个 PRESENT: 列表，并在适用时打印 ABSENT: 列表和 PLACEHOLDER: 列表（存在但仅包含 [To be designed] 的章节：尚未撰写，因此在清单中应视为缺失）。它只报告 是否存在，不判断 REQUIRED/ADVISORY——这是步骤 2b 的工作。它已接受 ## Detailed Design 满足 Detailed Rules 要求，因此不要将其标记为缺失。

步骤 2b——应用层级。 使用步骤 2a 的列表，根据以下设计文档标准清单进行评估。根据阶段 0 中确定的工作流层级，将每个章节标记为 REQUIRED 或 ADVISORY。 缺失的 REQUIRED 章节会阻止批准；缺失的 ADVISORY 章节会作为建议提出，但不会阻止批准。

步骤 2a 报告为 PRESENT 的章节仍可能因标题下没有内容而无法通过审查——对结论实际取决于的章节进行抽查阅读。

• 包含 Overview 章节（单段摘要）——所有层级均为 REQUIRED
• 包含 Player Fantasy 章节（期望营造的感受）——在 full 层级为 REQUIRED；在 standard 层级为 ADVISORY
• 包含 Detailed Rules 章节（明确无歧义的机制）——在 full/standard 层级为 REQUIRED。GDD 模板将此章节命名为 ## Detailed Design（其中包含 Core Rules / States / Interactions 子标题）；接受任一标题作为满足此要求——当存在 ## Detailed Design 章节时，不要将 “Detailed Rules” 标记为缺失。
• 包含 Formulas 章节（使用变量定义所有数学公式）——在 full 层级为 REQUIRED；在 standard 层级，当系统定义数值规则（比率、曲线、阈值、成本、伤害、掉落权重）时为 REQUIRED，否则为 ADVISORY。系统的 Category 仅供参考，并非判断依据——不能仅凭类别标记就判定此项符合要求
• 包含 Edge Cases 章节（处理特殊情况）——在 full/standard 层级为 REQUIRED
• 包含 Dependencies 章节（列出其他系统）——在 full/standard 层级为 REQUIRED
• 包含 Tuning Knobs 章节（标明可配置值）——在 full 层级为 REQUIRED；在 standard 层级为 ADVISORY，但 workflow_overrides.tuning_knobs 除外
• 包含 Acceptance Criteria 章节（可测试的成功条件）——在 full/standard 层级为 REQUIRED

---

第 3 阶段：一致性与可实现性

内部一致性：

• 公式算出的值是否符合所描述的行为？
• 边界情况是否与主要规则相矛盾？
• 依赖关系是否是双向的（另一个系统是否了解此系统）？

可实现性：

• 规则是否足够精确，程序员无需猜测即可实现？
• 是否有缺少细节的“含糊带过”部分？
• 是否考虑了性能影响？
• 每条验收标准是否都可以独立测试？标记出任何不可独立测试的标准，并引用原文——“感觉平衡”“运行正常”“性能良好”都不算标准——同时给出可衡量的改写。在 full 模式下，qa-lead 也会检查这些内容（第 3b 阶段）；在 lean 和 solo 模式下，不会运行专业审查，因此本次主审查是唯一的检查。

跨系统一致性：

• 这是否与任何现有机制冲突？
• 这是否会与其他系统产生意料之外的交互？
• 这是否符合游戏既定的基调与核心理念？

GDD 中出现的注册表值，无论位于何处。 表格、目录条目或变体说明中重述的值，如果与注册表不符，就和《详细规则》中的值一样构成矛盾；按章节阅读容易略过这些内容。列出注册表中的条目名称（grep -E '^ - name:' design/registry/entities.yaml），然后在整个目标文档中一次性搜索所有这些名称及其包含的数值键，不区分大小写，并将每个 _ 写成 [_ ]，这样 goblin_scout 也能匹配“Goblin scouts”：

grep -n -i -E 'goblin[_ ]scout|iron[_ ]sword|health|value[_ ]gold' [target-doc-path]

检查搜索输出的每一行，并与注册表核对，无论该行位于哪个章节。如果某行给出的条目值不同，即使差异只涉及一个房间、变体、等级或例外，也与所属 GDD 相矛盾：将其与行号、本文档中的值和注册表中的值一起列在“实现前必须完成”下。如果注册表中没有条目，则对相关 GDD 定义的实体和值运行相同的搜索。

---

第 3b 阶段：对抗式专业审查（仅限 full 模式）

在 lean 或 solo 模式下跳过此阶段。

在 full 模式下，此阶段为必做项。不得跳过。

在启动任何 Agent 之前，打印以下通知：

"Full review: spawning specialist agents in parallel. This typically takes 8–15 minutes. Use --review lean for faster single-session analysis."

步骤 1 — 识别 GDD 涉及的所有领域

使用已在第 1 阶段加载的 GDD——不要重新读取——识别其中涉及的每个领域。GDD 可以同时涉及多个领域，请全面检查。常见信号：

如果 GDD 包含……	启动这些 Agent
成本、价格、掉落、奖励、经济系统	economy-designer
战斗属性、伤害、生命值、DPS	game-designer、systems-designer
AI 行为、寻路、目标选择	ai-programmer
关卡布局、刷怪、波次结构	level-designer
玩家成长、XP、解锁	economy-designer、game-designer
UI、HUD、菜单、面向玩家的显示	ux-designer、ui-programmer
对话、任务、故事、背景设定	narrative-director
动画、手感、时机、爽感	gameplay-programmer
多人游戏、同步、复制	network-programmer
音频提示、音乐触发条件	audio-director
性能、绘制调用、内存	performance-analyst
引擎专属模式或 API	主要引擎专家（根据 engine.name 选择 <engine>-specialist——Godot→godot-specialist、Unity→unity-specialist、Unreal→unreal-specialist；若无法确定，则采用 technical-preferences.md 中 ## Engine Specialists 的 Primary 条目）
验收标准、测试覆盖率	qa-lead
数据架构、资源结构	systems-designer
任何游戏玩法系统	game-designer（始终启动）

对于所有描述游戏机制或面向玩家规则的 GDD，都要启动 game-designer。 对于所有包含公式或系统交互规则的 GDD，都要启动 systems-designer。 这是最常见的基础组合，但纯 UI 规格、音频规格或背景设定文档不必如此。请根据上方领域表判断哪些专家真正相关。

步骤 2 — 并行启动所有相关专家

重要：此技能中的 Agent 会启动一个子 Agent——一个拥有独立上下文窗口的独立 Claude 会话。它不是任务跟踪工具。不要在内部模拟专家视角。不要自行推演各领域的观点。你必须实际调用 Agent。模拟评审不算专家评审。

同时发出所有 Agent 调用。不要逐个启动。

以质疑的方式向每位专家发出提示词：

“这是 [system] 的 GDD，以及主评审目前发现的结构性问题。 你的任务不是验证这项设计，而是找出问题。 请运用你的领域专业知识，质疑设计选择。有哪些地方有误、说明不充分、可能引发问题，或完全缺失？ 请具体、严谨地指出问题。欢迎提出与主评审不同的意见。 按章节阅读 GDD：使用 Grep 工具（内容模式，匹配模式 ^#）查找标题，再使用带有 offset 和 limit 的 Read 工具读取相应范围。”

针对各类 Agent 的补充说明：

• game-designer：以本 GDD B 节中所述的玩家幻想为评审依据。这项设计是否真正实现了该幻想？玩家能否体验到预期感受？指出任何为了便于实现而制定、却削弱预期体验的规则。

• systems-designer：针对 GDD 中的每个公式，代入边界值（可能输入的最小值和最大值）。报告是否有输出在极端情况下变得异常——例如负值、除以零、无穷大或不合逻辑的结果。

• qa-lead：评审每一项验收标准。指出所有无法独立测试的标准——例如“感觉平衡”“正常工作”“性能良好”等措辞都不属于验收标准。对于不符合此要求的标准，请提出具体的改写建议。

步骤 3 — 资深负责人评审

所有专家回复后，启动 creative-director 作为资深评审者：

• 提供：GDD、所有专家的发现，以及他们之间的任何分歧
• 询问：“综合这些发现。最重要的问题是什么？你同意专家的意见吗？你对这项设计的总体结论是什么——APPROVED、NEEDS REVISION 还是 MAJOR REVISION NEEDED？”
• creative-director 的综合意见将成为第 4 阶段的最终结论，使用此技能中的结论用语——绝不要使用 READY 或 REJECT 之类的负责人关卡用语。

步骤 4 — 明示分歧

如果专家彼此之间或专家与 creative-director 之间存在分歧，不要悄悄选取其中一种观点。在第 4 阶段明确呈现分歧，让用户裁定。

为每项发现标注来源：[game-designer]、[economy-designer]、[creative-director] 等。

---

第 4 阶段：输出评审

## Design Review: [Document Title]
Specialists consulted: [list agents spawned]
Re-review: [Yes — prior verdict was X on YYYY-MM-DD / No — first review]

### Completeness: [X/N sections present, where N is the count REQUIRED at this project's `modes.workflow`]
[List only sections missing that are REQUIRED at this tier. Mark ADVISORY gaps
separately as "advisory at `standard`" — do not list them as missing.]

> **N is not 8 unless `workflow: full`.** The tier table earlier in this skill is
> authoritative: 8 required at `full`, 5 at `standard` (+ Formulas when the system
> defines numeric rules), 0 at `minimal`. Do not hardcode `/8` here: reporting a
> `standard` project as "5/8 missing Player Fantasy, Formulas, Tuning Knobs"
> warns about three sections that project's own configuration says it does not
> need, which trains the reader to ignore the review.

### Dependency Graph
[List each declared dependency and whether its GDD file exists on disk]
- ✓ enemy-definition-data.md — exists
- ✗ loot-system.md — NOT FOUND (file does not exist yet)

### Registry Values
[The whole-document search from Phase 3: the terms searched, how many lines it
printed, and each conflict with its line number. With nothing to search, say so:
"No registry entries or related-GDD values: values not cross-checked."]

### Required Before Implementation
[Numbered list — blocking issues only. Each item tagged with source agent.]

### Recommended Revisions
[Numbered list — important but not blocking. Source-tagged.]

### Specialist Disagreements
[Any cases where agents disagreed with each other or with the main review.
Present both sides — do not silently resolve.]

### Nice-to-Have
[Minor improvements, low priority.]

### Senior Verdict [creative-director]
[Creative director's synthesis and overall assessment.]

### Scope Signal
Estimate implementation scope based on: dependency count, formula count,
systems touched, and whether new ADRs are required.
- **S** — single system, no formulas, no new ADRs, <3 dependencies
- **M** — moderate complexity, 1-2 formulas, 3-6 dependencies
- **L** — multi-system integration, 3+ formulas, may require new ADR
- **XL** — cross-cutting concern, 5+ dependencies, multiple new ADRs likely
Label clearly: "Rough scope signal: M (producer should verify before sprint planning)"

### Verdict: [APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED / NOT ASSESSED]

> **`NOT ASSESSED` when the review could not actually be performed.**
> The other three verdicts are all claims about the design's quality, so each one
> asserts that the document was read and judged. Use `NOT ASSESSED` instead when
> the target document is absent, unreadable, or empty of the sections being
> reviewed, or when a document it depends on is missing so the criteria cannot be
> applied. **Name what was unavailable and which skill produces it.**
>
> `APPROVED` is the dangerous default here: a review that could not find its
> input has not approved anything, and this verdict is consumed downstream as a
> sign-off. `NOT ASSESSED` outranks `APPROVED` in any aggregate — it does not
> outrank the two revision verdicts, because a known problem is more actionable
> than an unknown one.

此技能为只读技能——第 4 阶段不会写入任何文件。

---

第 5 阶段：后续步骤

所有收尾交互都使用 AskUserQuestion。绝不要使用纯文本。

第一个控件 — 接下来要做什么：

如果结果为 APPROVED（首次评审通过，无需修改），直接进入系统索引控件、评审日志控件，然后进入最终收尾控件。不要单独显示“接下来要做什么”控件——最终收尾控件会涵盖后续步骤。

如果结果为 NOT ASSESSED，则表示尚未进行评审：不提供跟踪记录更新，直接进入最终收尾控件，并首先提供能生成缺失输入的技能（例如，对于尚不存在的 GDD，提供 /design-system [system]）。

如果结果为 NEEDS REVISION 或 MAJOR REVISION NEEDED，根据发现的问题制定选项：

• [A] 现在修改 GDD — 一并解决所有阻塞项
• [B] 到此为止 — 在单独的会话中修改
• [C] 按原样接受并继续 — 仅当所有发现都属于建议项时提供（Required Before Implementation 为空）。只要存在任何阻塞项，就仅提供 [A] 和 [B]。

如果用户选择 [A] — 现在修改：

处理所有阻塞项；只有在无法仅凭 GDD 和现有文档解决问题时，才询问设计决策。进行任何编辑之前，将所有设计决策问题汇总到一个多标签页 AskUserQuestion 中——不要在修改过程中针对每个阻塞项逐一打断用户。

所有修改完成后，显示摘要表（阻塞项 → 已应用的修正），并使用 AskUserQuestion 显示修改后收尾控件：

• 提示：“修改已完成 — 已解决 [N] 个阻塞项。接下来怎么做？”
• 注明当前上下文使用量：如果上下文使用量超过约 50%，添加：“（建议：重新评审前使用 /clear — 本次会话已使用 X% 的上下文。完整评审会运行 5 个 Agent，需要干净的上下文。）”
• 选项：
  • [A] 在新会话中重新评审 — 执行 /clear 后运行 /design-review [doc-path]
  • [B] 暂时接受修改 — 在系统索引中标记为 In Review；重新评审后再决定是否为 Approved
  • [C] 进入下一个系统 — /design-system [next-system]（设计顺序中的第 #N 项）
  • [D] 到此为止

在协作模式和引导模式中，修改流程结束时绝不要使用纯文本——始终以此控件收尾。在自主模式中，总结结果并通过 log_decision 记录。

第二个控件 — 跟踪记录（APPROVED 路径合并处理）：

结果为 APPROVED 时，使用一个 AskUserQuestion，并设置 multiSelect: true，将两项跟踪记录更新合并处理：

• 提示：“结论：APPROVED。我现在可以更新跟踪记录。请选择希望我完成的更新：”
• 选项：
  • 将 systems-index.md 中 [system] 的状态更新为 'Approved'
  • 将批准记录追加到 design/gdd/reviews/[doc-name]-review-log.md

如果选择了评审日志选项，则按下方相同的格式追加。在显示最终收尾控件之前，执行所有选中的操作。

结果为 NEEDS REVISION 或 MAJOR REVISION NEEDED 时，仍像之前一样分别使用控件： 使用第二个 AskUserQuestion：

• 提示："May I update design/gdd/systems-index.md to mark [system] as [Needs Revision / In Review]?" — 在修订尚未完成时使用 Needs Revision（该字符串必须完全一致），修订完成并等待重新审核后使用 In Review。此提示绝不提供 Approved：修订判定并不代表批准。
• 选项：[A] Yes — update it / [B] No — leave it as-is

使用第三个 AskUserQuestion：

• 提示："May I append this review summary to design/gdd/reviews/[doc-name]-review-log.md? This creates a revision history so future re-reviews can track what changed."
• 选项：[A] Yes — append to review log / [B] No — skip

如果选择是，按以下格式追加一条记录：

## Review — [YYYY-MM-DD] — Verdict: [APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED]
Review mode: [full / lean / solo] · Workflow: [full / standard / minimal]
Scope signal: [S/M/L/XL]
Specialists: [list]
Blocking items: [count] | Recommended: [count]
Summary: [2-3 sentence summary of key findings from creative-director verdict]
Prior verdict resolved: [Yes / No / First review]
Findings:
- [BLOCKING] [section]: [one-line finding]
- [RECOMMENDED] [section]: [one-line finding]
[output of: Bash: bash .claude/scripts/review-receipts.sh hash "[target-doc-path]" "design/registry/entities.yaml" ".claude/skills/design-review/SKILL.md" [every other file this review read for cross-document facts: the related GDDs in design/gdd/, design/gdd/game-concept.md or design/game-brief.md, the design/narrative/ files] — a file that does not exist prints `not stamped, no such file` and is left out]

评审结果规则：每条结果占一行，并以其所在章节命名；如果判定没有任何结果，则写 - none。这些记录是供阅读修订历史的人查看的文档，不是此技能回读的机制。

哈希行是回执，Phase 1 会在下一次运行时读取它，以检测字节完全相同的重新评审——这是唯一安全的跳过方式，因为输入已被证明相同，而非仅仅认为先前评审已充分覆盖。为评审读取的每个文件都加上戳记：Phase 1 的检查会在下一次运行时比较每个加戳记的文件，无论哈希行是否列出该文件。无论判定结果如何，都始终包含哈希行——如果先前评审未通过，那么文档未发生变化恰恰是跳过冗余重新评审最有价值的情况（先前的评审结果仍逐字有效）。

---

最终收尾组件——所有文件写入完成后始终显示：

系统索引和评审日志组件均已回答后，检查项目状态并显示最后一个 AskUserQuestion：

在构建选项之前，读取：

• design/gdd/systems-index.md — 查找状态为 In Review 或 Needs Revision 的系统（刚刚评审过的系统除外）。按章节读取：使用 Grep 工具查找标题（模式 ^#，内容模式），再用 offset 和 limit 读取对应范围。
• 统计 design/gdd/ 中的 .md 文件数量（不包括 game-concept.md、systems-index.md），以确定是否值得提供 /review-all-gdds（≥2 个 GDD）
• 按设计顺序查找下一个状态为 Not Started 的系统

动态构建选项列表——只包含确实是下一步的选项：

• [_] Run /design-review [other-gdd-path] — [system name] is still [In Review / Needs Revision]（如果另一个 GDD 需要评审，则包含）
• [_] Run /consistency-check — verify this GDD's values don't conflict with existing GDDs（只要至少存在另一个 GDD，就始终包含）
• [_] Run /review-all-gdds — holistic design-theory review across all designed systems（如果存在至少 2 个 GDD，则包含）
• [_] Run /design-system [next-system] — next in design order（始终包含，并写明实际系统名称）
• [_] Stop here

仅为已包含的选项分配字母 A、B、C……。将最能推进流程的选项标记为 (recommended)。

在协作模式和引导模式下，文件写入完成后，绝不要以纯文本结束技能——始终以此组件收尾。在自主模式下，打印下一步并通过 log_decision 记录。