用途
design-review 用于对单份设计文档进行审查，重点关注四类问题：完整性、内部一致性、可实现性以及是否符合设计标准。它的定位是在文档交付给程序员之前进行把关。
主要能力
- 完整性检查：通过结构检查脚本确定章节是否存在，并按工作流等级（full / standard / minimal）判断哪些章节为必需、哪些仅为建议。
- 一致性检查：核验公式结果与描述行为是否一致、边界情况是否与主规则冲突、依赖关系是否为双向。
- 可实现性检查：判断规则是否足够精确、是否存在含糊段落、是否考虑性能影响，以及每条验收标准是否可独立测试。
- 跨系统一致性：检查是否与现有机制冲突、是否产生非预期交互、是否与既定基调与设计支柱一致。
- 依赖图校验：检查 Dependencies 中列出的系统其 GDD 文件是否真实存在。
- 重复审查感知：通过 review-receipts 脚本检查文档与注册表是否变更，避免对未变更文档重复付费审查。
- 对抗式专家评审（full 模式）：并行派出多个专家子代理，从各自领域挑错，再由 creative-director 综合形成最终结论。
使用方式
该技能以斜杠命令形式调用，支持 --review 标志（其前身是 --depth，两者同时出现时 --review 优先）。审查模式分为：
- full：完整审查，包含所有阶段与专家代理委派。
- lean：执行所有阶段，但不派专家代理，单会话分析，速度更快。
- solo：仅阶段 1-4，不委派，不输出下一步提示，适合被其它技能内部调用。
工作流等级由配置解析得出，并影响章节的必需/建议判定。审查过程中会调用 .claude/scripts/gdd-structure-check.sh、.claude/scripts/review-receipts.sh、.claude/hooks/yaml-helper.sh 等脚本。
适用场景
- 游戏项目中 GDD 交付给程序员前的评审关卡。
- 需要跨文档事实核验（依赖注册表 entities.yaml 而非逐个读兄弟 GDD）。
- 需要多领域专家对抗式挑错（经济、战斗、AI、关卡、叙事、UI、网络、音频、性能等）。
限制
- 审查范围受工作流等级约束，minimal 等级不期望存在 GDD。
- 对未变更文档会跳过重复审查，但仅在文档与注册表所有相关行均显示 UNCHANGED 时才安全跳过。
- 依赖注册表
design/registry/entities.yaml进行跨文档事实核验；若该文件不存在或未收录本系统条目，则回退到读取目标文档 Dependencies 节所指定的相关 GDD。 - 最终结论使用 APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED / NOT ASSESSED，不同的 director-gate 词汇（如 READY、REJECT）不会使用。