review-all-gdds

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

审查所有 GDD

此技能会同时读取所有系统 GDD，并进行两项互为补充的审查。这两项审查无法通过单独审查每份 GDD 完成：

1. 跨 GDD 一致性 — 文档之间的矛盾、过时引用和归属冲突
2. 游戏设计整体性 — 只有将所有系统放在一起考察时才会显现的问题：主导策略、失衡的经济系统、认知过载、设计支柱偏移、相互竞争的成长循环

这与 /design-review 不同，后者会审查单份 GDD 的内部完整性。此技能审查的是所有 GDD 之间的关系。

运行时机：

• 所有 MVP 级别的 GDD 均已单独获批后
• 生产过程中，任何 GDD 有重大修订后
• /create-architecture 开始前（架构若建立在不一致的 GDD 之上，也会继承这些不一致）

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

参数模式：

关注范围： $ARGUMENTS（留空 = full）

• 无参数 / full：同时进行一致性和设计理论审查
• consistency：仅检查跨 GDD 一致性（更快）
• design-theory：仅检查游戏设计整体性
• since-last-review：仅审查上次审查报告之后修改过的 GDD（基于 git）

---

每份 GDD 的 workflow（依据 .claude/docs/workflow-modes.md）：每份 GDD 都根据其有效级别进行验证——项目级别的值，并由 system_overrides 中该系统对应的行覆盖（若该块列出了该行）。级别为 full 时，验证所有 GDD 的全部 8 个章节。级别为 standard 时，验证 5 个必需章节；可选章节（玩家幻想、调优参数、有条件的公式）仅作为建议列出。级别为 minimal 时，此技能不适用（没有 GDD）。

阶段 1：全部加载

现在读取 references/1-load.md 并按其中说明操作——此阶段的步骤位于该文件中，而非此处。如果在此阶段对话经过压缩或恢复，请重新读取该文件。

并行执行

阶段 2（一致性）和阶段 3（设计理论）互相独立——它们读取相同的 GDD 输入，但生成各自独立的报告。应同时将二者作为并行 Agent 智能体启动，而不是等阶段 2 完成后再开始阶段 3。撰写合并报告前，先收集两者的结果。

应将两者均作为 game-designer 子智能体（subagent_type: game-designer）启动——GDD 一致性和设计理论审查属于其专业领域。

启动阶段 2 和阶段 3 智能体时，始终传入：

• 各阶段所需的已加载 GDD 内容——不要传文件路径。粘贴相关章节；子智能体拥有独立的上下文，无法重新读取阶段 1 的结果，因此传入路径会迫使其重新完整读取（也违反了下方的“不要重新读取”规则）。只传入该阶段所需的部分：阶段 2（一致性）需要每份 GDD 的依赖项、详细设计/规则、公式、调优参数和验收标准；阶段 3（设计理论）需要玩家幻想、成长/奖励结构和游戏支柱。
• 如果在阶段 1b 中加载了完整的实体注册表内容（design/registry/entities.yaml）（请粘贴注册表文本，而不仅是文件路径）
• 分配给该智能体阶段的具体检查清单条目（阶段 2 获取 2a–2f；阶段 3 获取 3a–3g）
• 引擎名称和版本——project.yaml 中的 engine.name 和 engine.version，分别解析这两个字段（如果键缺失或为空，则使用 .claude/docs/technical-preferences.md）——以及 docs/engine-reference/[engine]/VERSION.md

不要依赖子智能体重新读取这些文件——它拥有独立的上下文窗口，除非在 Agent 提示中明确传入，否则无法访问阶段 1 的结果。

---

阶段 2：跨 GDD 一致性

现在阅读 references/2-consistency.md 并遵循其中的要求——本阶段的步骤在该文件中，而不在此处。如果对话在本阶段被压缩或恢复，请重新阅读该文件。

阶段 3：游戏设计整体性

现在阅读 references/3-design-holism.md 并遵循其中的要求——本阶段的步骤在该文件中，而不在此处。如果对话在本阶段被压缩或恢复，请重新阅读该文件。

阶段 4：跨系统场景演练

现在阅读 references/4-scenarios.md 并遵循其中的要求——本阶段的步骤在该文件中，而不在此处。如果对话在本阶段被压缩或恢复，请重新阅读该文件。

阶段 5：输出审查报告

现在阅读 references/5-report.md 并遵循其中的要求——本阶段的步骤在该文件中，而不在此处。如果对话在本阶段被压缩或恢复，请重新阅读该文件。

阶段 6：撰写报告并标记 GDD

现在阅读 references/6-write.md 并遵循其中的要求——本阶段的步骤在该文件中，而不在此处。如果对话在本阶段被压缩或恢复，请重新阅读该文件。

阶段 7：交接

现在阅读 references/7-handoff.md 并遵循其中的要求——本阶段的步骤在该文件中，而不在此处。如果对话在本阶段被压缩或恢复，请重新阅读该文件。

错误恢复协议

首先，验证产物。 如果返回约定指定了路径，请在将阶段视为完成之前检查该路径是否存在——指定的产物若未写入磁盘，该阶段就算失败，无论回复写得多么流畅。 Agent 可能耗费整个阶段，只返回看似合理的前言，却什么也没写；这既不属于 BLOCKED，也不是错误或“未能完成”，因此下方的触发条件永远不会生效。应通过指出尚未满足的约定来恢复；上下文通常仍然存在。

如果任何生成的 Agent 返回 BLOCKED、出错或未能完成：立即说明，不要越过其阻塞的依赖继续执行，并始终生成部分报告（此处的重试范围 = 更少的 GDD / 单个系统）。完整流程见：.claude/docs/error-recovery-protocol.md。

---

协作协议

在 collaborative 模式下（默认模式）。 关于 guided 和 autonomous 模式，请参阅 .claude/docs/automation-modes.md。在 autonomous 模式下，仍会打印并记录 PASS/CONCERNS/FAIL 判定——仅跳过结尾的交接组件。

1. 静默阅读——在展示任何内容之前，加载所有 GDD
2. 完整展示——在询问采取任何行动之前，呈现完整的一致性和设计理论分析
3. 区分阻塞项与建议项——并非每个问题都需要阻塞架构；请明确说明哪些问题会造成阻塞
4. 不要做设计决策——指出矛盾和选项，但绝不要擅自决定哪个 GDD“正确”
5. 写入前先征求同意——写入报告或更新系统索引前，先确认
6. 具体明确——每个问题都必须指出涉及的具体 GDD、章节和文本；不要给出含糊的警告