architecture-review

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

架构审查

架构审查用于验证完整的架构决策集是否涵盖所有游戏设计要求、内部是否一致，以及是否正确针对项目锁定的引擎版本。这是技术设置与预制作之间的质量关卡。

参数模式：

• 无参数 / full：完整审查——所有阶段
• coverage：仅追踪性——哪些 GDD 需求没有 ADR
• consistency：仅检测 ADR 之间的冲突
• engine：仅审计引擎兼容性
• single-gdd [path]：审查某个特定 GDD 的架构覆盖情况
• rtm：需求追踪矩阵——扩展标准矩阵，加入故事文件路径和测试文件路径；输出 docs/architecture/requirements-traceability.md，其中包含完整的 GDD 需求 → ADR → 故事 → 测试链路。适用于故事和测试文件已存在的制作阶段。

---

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

workflow（参见 .claude/docs/workflow-modes.md）：

• full — 覆盖所有 GDD 和所有 ADR 的完整追踪矩阵。
• standard — 缩小范围：仅检查架构文档和关键 ADR。
• minimal — 不适用（无需架构文档）。

阶段 1：加载所有内容

现在阅读 references/1-load.md 并遵循其中的说明——本阶段的步骤位于该文件中，而不是此处。如果在本阶段对话经过压缩或恢复，请再次阅读。

阶段 2：提取每个 GDD 中的技术需求

现在阅读 references/2-extract-requirements.md 并遵循其中的说明——本阶段的步骤位于该文件中，而不是此处。如果在本阶段对话经过压缩或恢复，请再次阅读。

阶段 3：构建追踪矩阵

现在阅读 references/3-traceability.md 并遵循其中的说明——本阶段的步骤位于该文件中，而不是此处。如果在本阶段对话经过压缩或恢复，请再次阅读。

阶段 4：检测 ADR 之间的冲突

现在阅读 references/4-conflicts.md 并遵循其中的说明——本阶段的步骤位于该文件中，而不是此处。如果在本阶段对话经过压缩或恢复，请再次阅读。

阶段 5：交叉检查引擎兼容性

现在阅读 references/5-engine.md 并遵循其中的说明——本阶段的步骤位于该文件中，而不是此处。如果在本阶段对话经过压缩或恢复，请再次阅读。

阶段 6：检查架构文档覆盖情况

现在阅读 references/6-document-coverage.md 并遵循其中的说明——本阶段的步骤位于该文件中，而不是此处。如果在本阶段对话经过压缩或恢复，请再次阅读。

阶段 7：输出审查报告

现在阅读 references/7-report.md 并遵循其中的说明——本阶段的步骤位于该文件中，而不是此处。如果在本阶段对话经过压缩或恢复，请再次阅读。

阶段 8：编写并更新追踪索引

现在阅读 references/8-write.md 并遵循其中的说明——本阶段的步骤位于该文件中，而不是此处。如果在本阶段对话经过压缩或恢复，请再次阅读。

阶段 9：交接

现在阅读 references/9-handoff.md 并遵循其中的说明——本阶段的步骤位于该文件中，而不是此处。如果在本阶段对话经过压缩或恢复，请再次阅读。

错误恢复协议

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

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

---

协作协议

适用于 collaborative 模式（默认模式）。 关于 guided 和 autonomous 模式，请参阅 .claude/docs/automation-modes.md——以下规则描述的是 collaborative 模式的要求，并非通用行为。

1. 静默阅读——不要逐一讲述读取的每个文件
2. 展示矩阵——在请求任何写入批准之前，先展示完整的可追溯性矩阵，让用户了解当前状态
3. 不要猜测——如果需求含糊不清，请询问：“[X] 是技术需求还是设计偏好？”
4. 先起草，再请求批准——始终在请求批准前，于对话中展示将要写入的内容（报告、更新后的 ADR 章节、systems-index 行）。绝不要请求写入用户尚未看过的内容。
5. 使用 AskUserQuestion 请求写入批准——仅以纯文本询问“可以吗？”并不足够。请使用带有 [A]/[B]/[C] 标签选项的结构化工具，让用户可以选择“立即写入”“先展示完整草稿”或“暂不”。涉及多个文件的变更集必须列出每个文件及其变更内容，然后通过带分组选项的问题一次性询问——不要针对每个文件分别用纯文本提问。
6. 不阻塞——结论仅供参考；即使存在 CONCERNS 甚至 FAIL 结果，用户仍可决定是否继续