企业官网建设流程全解析

Claude Code Game Studios 跨 GDD 整体评审：/review-all-gdds 双阶段并行评审技能的行为规格与测试指南

【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios

/review-all-gdds是 Claude Code Game Studios（CCGS）技能框架中负责跨游戏设计文档（GDD）整体评审的核心技能：它并行运行「一致性扫描」与「设计理论检查」两个独立阶段，对design/gdd/下全部系统 GDD 输出 CONSISTENT / MINOR ISSUES / MAJOR ISSUES 三档结论，且全程只读、绝不未经批准写入任何文件。本文以仓库中的技能测试规格为骨架，结合测试框架的分类质量指标、技能目录与设计目录规范，完整讲解该技能的评审模型、无导演 Gate 的设计原理、五个行为测试用例及协议合规要求，帮助你理解并验证这一「整体评审闸门」级技能。

一、技能定位：Opus 级整体评审与只读原则

/review-all-gdds被定义为Opus 层级技能，与单文档评审/design-review、架构评审/architecture-review同属review类别，且在 catalog.yaml 中被标记为critical 优先级。它执行的是跨 GDD 的整体（holistic）评审：

• 输入：design/gdd/目录下的全部系统 GDD 文件（而非单个文档）；
• 评审面：两份文档之间的相互矛盾、公式不一致、过期引用、所有权冲突，以及整体设计理论层面的支柱漂移、主导策略、认知过载、经济失衡；
• 输出：结构化问题发现表 + 三档终审结论；
• 副作用：只读。规格明确要求「不写入任何文件，除非获得用户明确批准」（no files are written without explicit user approval），因此技能本身不包含「May I write」类协作语言——它不需要征求写入许可，因为它默认不写。

该技能在管线中的身份是整体评审闸门（holistic review gate）本身：它在单个 GDD 各自完成后、架构工作开始前被调用。规格原文强调：它不会孵化任何导演级 Gate Agent（不产生 CD-、TD-、PR-、AD- 前缀的评审），因为「它本身就是导演级评审」——若再委托给导演 Gate，会形成循环依赖（circular dependency）。

二、在研发管线中的位置：系统设计阶段的出口闸门

要理解/review-all-gdds的价值，需要把它放回 CCGS 的 7 阶段管线。在 设计目录规范 中，GDD 的校验流程被明确规定为两步：

Validation:Run/design-review [path]after authoring any GDD. Run/review-all-gddsafter completing a set of related GDDs.

即：单个 GDD 写完后用/design-review做单文档 8 节合规评审；一组相关 GDD 全部完成后，用/review-all-gdds做跨文档整体评审。从 skill-flow-diagrams.md 的 Phase 2（系统设计阶段）可以看到完整链条：

/map-systems ──► design/gdd/systems-index.md /design-system [name] ──► design/gdd/[system].md（逐系统编写） /design-review [system].md ──► 单 GDD 评审意见 /review-all-gdds ──► 跨 GDD 整体评审 /gate-check ──► PASS → 进入技术搭建阶段（Phase 3）

也就是说，/review-all-gdds是系统设计阶段流向架构阶段前的最后一关：通过后进入/create-architecture、/architecture-review等技术搭建流程。它同时与两个相邻技能形成分工：

• 与/design-review的关系：/design-review只评审单个 GDD 的 8 节完整度、内部一致性与可实现性。在其测试规格的 Coverage Notes 中明确声明：跨系统一致性检查需要多个 GDD 文件做对比，由/review-all-gdds的规格负责覆盖——这正是单文档评审与整体评审的边界。
• 与/consistency-check的关系：/consistency-check负责结构层面的一致性扫描（公式不匹配、所有权冲突、过期引用、依赖缺口），其规格同样声明：深层的设计理论分析（支柱漂移、主导策略）由/review-all-gdds处理。/review-all-gdds的两阶段模型实际上是「一致性机械扫描 + 设计理论纵深检查」的合体，且要求两阶段并行。

三、双阶段并行评审架构

/review-all-gdds的核心设计是两个互补且彼此独立的评审阶段：

Phase 1：一致性扫描（Consistency Scan）

负责找出文档之间的结构性冲突，覆盖四类问题：

Phase 2：设计理论检查（Design Theory Check）

负责从游戏设计理论层面做整体评估，覆盖四类问题：

为什么必须并行？两个阶段之间没有输入依赖：一致性扫描不需要设计理论检查的结论，反之亦然。规格要求它们同时派生（spawned simultaneously）以节省时间，并在 Protocol Compliance 中把「并行而非串行」列为硬性合规项。这也与质量指标体系一致：review类别在 quality-rubric.md 中定义了 R1–R5 五个度量，其中R4 — 分析阶段不孵化导演 Gate正是本技能的设计约束。

输出的结构化发现表

无论发现多少问题，技能都必须输出一张结构化发现表（findings table）——即使没有问题，也要显示「No issues found」。每一条冲突条目必须包含：

• 双方文件名（例如 GDD-A vs GDD-B），而不是含糊的「发现冲突」；
• 具体的冲突规则：直接引用或转述互相矛盾的两条规则原文，不得使用「存在冲突」之类的模糊表述；
• 严重度分级：其中直接规则矛盾被归类为severity HIGH（阻塞级），孤立依赖缺口则属于 advisory（建议级，不单独阻塞）。

四、Verddict 体系与后续交接（Handoff）

技能的最终结论必须且只能是三档之一：

交接语义是规格的固定组成部分：MAJOR ISSUES 时不自动前进，MINOR ISSUES 时可谨慎继续，CONSISTENT 时指向架构工作。与之配套，/design-system的规格也把/review-all-gdds列为编写完成后的标准交接目标之一。

五、为什么没有导演 Gate：规避循环依赖

在 CCGS 框架中，许多技能会根据production/session-state/review-mode.txt中的full/lean/solo三档模式孵化导演 Gate（如/design-system的 CD-GDD-ALIGN、/architecture-review的 TD-ARCHITECTURE + LP-FEASIBILITY）。/review-all-gdds是一个明确的反例：

• 规格的 Director Gate Checks 部分写明：无任何导演 Gate；
• 理由：该技能本身就是整体评审，若再孵化导演 Gate 去评审它，就形成了「评审评审」的循环依赖；
• 配套断言：技能不读取production/session-state/review-mode.txt，review mode 设置对其行为零影响；
• 输出中不得出现任何Gate: [GATE-ID]或 "skipped" gate 条目；
• 对应质量指标：R4 — 该技能在全部模式下 gate 数 = 0。

这一设计把「评审行为」与「门禁行为」清晰分离：整体评审是分析动作，门禁推进交给后续的/gate-check完成。

六、测试规格的结构与静态断言

该技能的行为规格存放在CCGS Skill Testing Framework/skills/review/review-all-gdds.md，遵循通用技能测试规格模板（5 个测试用例 + 协议合规断言）的结构。其中静态断言（Static Assertions）由/skill-test static自动校验、无需夹具，共 6 项：

• 具备必需的 frontmatter 字段：name、description、argument-hint、user-invocable、allowed-tools；
• 包含 ≥5 个阶段标题（属于复杂多阶段技能）；
• 包含结论关键词：CONSISTENT、MINOR ISSUES、MAJOR ISSUES；
• 不要求「May I write」语言（只读技能）；
• 结尾包含下一步交接（next-step handoff）；
• 文档化了两阶段并行派生（Phase 1 与 Phase 2 相互独立）。

在 CCGS 测试框架中，运行方式是/skill-test static review-all-gdds（结构合规）与/skill-test spec review-all-gdds（对照本规格逐条行为评估），测试结果可回写 catalog.yaml 中该技能条目的last_static/last_spec/last_spec_result等追踪字段。

七、五个行为测试用例详解

规格用五个用例覆盖该技能的完整行为面：快乐路径、失败路径、部分路径、边界情形、导演 Gate 情形。注意：用例中的design/gdd/目录、GDD 文件与production/session-state/review-mode.txt均属于测试夹具（Fixture）假设的项目状态，测试运行前需先满足这些前置条件。

Case 1：Happy Path —— 无冲突的干净 GDD 集合

夹具：design/gdd/下存在 ≥3 个系统 GDD；全部 GDD 内部一致（无公式矛盾、无所有权竞争、无过期引用）；全部与design/gdd/game-pillars.md中定义的设计支柱对齐。

期望行为：

1. 读取design/gdd/下全部 GDD 文件；
2. Phase 1（一致性）与 Phase 2（设计理论）并行派生；
3. Phase 1 未发现矛盾、公式不匹配或所有权冲突；
4. Phase 2 未发现支柱漂移、主导策略或认知过载；
5. 输出结构化发现表，0 条阻塞问题；
6. 结论：CONSISTENT。

断言：两阶段确实并行而非串行；输出含发现表（空表也显示「No issues found」）；无冲突时结论为 CONSISTENT；无用户批准不写任何文件；结尾含向/architecture-review或/create-architecture的交接。

Case 2：Failure Path —— 两个 GDD 之间的冲突规则

夹具：GDD-A 定义某下限规则（例如「[输出] 的最小值为 [N]」）；GDD-B 描述了一种可绕过该下限的机制（例如「[机制] 可将 [输出] 降至 0」）；两文档其余部分完整有效。

期望行为：

1. Phase 1 检测到 GDD-A 与 GDD-B 的矛盾；
2. 冲突条目同时列出双方文件名、具体冲突规则，严重度标记为HIGH；
3. 结论：MAJOR ISSUES；
4. 交接指示用户先解决冲突并重新运行。

断言：结论必须是 MAJOR ISSUES（而非其他两档）；两个文件名都被点名；矛盾规则被引用或转述（不是笼统的「发现冲突」）；问题被归为 HIGH（阻塞级）；技能不自动解决冲突——它只报告，修复是人的工作。

Case 3：Partial Path —— 单个 GDD 的孤立依赖引用

夹具：GDD-A 在 Dependencies 部分引用系统 "system-B"；但design/gdd/中不存在 system-B 的 GDD；其余 GDD 全部一致。

期望行为：

1. Phase 1 检测到孤立依赖引用；
2. 问题报告为：DEPENDENCY GAP —— GDD-A 引用了没有对应 GDD 的 system-B；
3. 未发现其他冲突；
4. 结论：MINOR ISSUES（孤立依赖缺口本身是建议级，不单独阻塞）。

断言：结论为 MINOR ISSUES（单个孤立引用不升级为 MAJOR）；报告点名 GDD-A 与缺失依赖名；技能建议运行/design-system system-B来补缺口；技能不会跳过或静默忽略缺失依赖。

Case 4：Edge Case —— 未找到任何 GDD 文件

夹具：design/gdd/目录为空或不存在。

期望行为：

1. 技能尝试读取design/gdd/；
2. 未找到文件——输出带指引的错误信息；
3. 建议先运行/brainstorm和/design-system再重试；
4. 不产出任何结论（不给出 CONSISTENT / MINOR ISSUES / MAJOR ISSUES）。

断言：目录为空时输出清晰错误；无结论产出；给出正确的下一步建议；技能不崩溃、不产出残缺报告。这与/consistency-check的空目录行为（建议/design-system）保持一致。

Case 5：Director Gate —— 任何模式下都不孵化 Gate

夹具：design/gdd/含 ≥2 个一致的系统 GDD；production/session-state/review-mode.txt存在且内容为full（最宽松模式）。

期望行为：

1. 技能读取全部 GDD 并运行两阶段评审；
2. 不读取review-mode.txt；
3. 不孵化任何导演 Gate Agent（无 CD-、TD-、PR-、AD- 前缀）；
4. 正常完成并输出结论；
5. review mode 设置对该技能行为无影响。

断言：任何时刻都不孵化导演 Gate；不读取review-mode.txt；输出不含任何Gate: [GATE-ID]或 "skipped" gate 条目；无论何种模式都正常产出结论；对应R4 指标：该技能在全部模式下 gate 数 = 0。

五个用例一览

八、协议合规清单（Protocol Compliance）

规格最后以检查清单形式固化了一组不可协商的协议要求：

• Phase 1（一致性）与 Phase 2（设计理论）并行派生，而非串行；
• 未经「May I write」批准不写任何文件；
• 任何写入请求之前必须先完整展示发现表；
• 结论严格限定为 CONSISTENT、MINOR ISSUES、MAJOR ISSUES 三选一；
• 按结论给出正确交接：MAJOR ISSUES → 修复后重跑；MINOR ISSUES → 可带着注意继续；CONSISTENT →/create-architecture。

九、覆盖范围说明（Coverage Notes）

规格如实标注了测试的边界，这些边界本身就是对该技能能力模型的重要说明：

• 经济平衡分析（source/sink 回路）需要跨 GDD 的资源数据，在规格中由 Case 2结构性覆盖——冲突检测的模式与公式不匹配检测一致，无需单独夹具；
• Phase 2 设计理论检查中的主导策略检测、认知过载等项未逐一做夹具测试，它们遵循与一致性检查相同的模式，并通过支柱漂移用例的结构间接验证；
• since-last-review增量范围模式不在本规格测试范围内——它是运行时关注点（runtime concern），由技能本体在真实会话中处理。

十、如何用测试框架验证本技能

在 CCGS 测试框架中验证/review-all-gdds的完整流程为：

/skill-test static review-all-gdds # 校验 6 项静态断言（无需夹具） /skill-test spec review-all-gdds # 按本规格 5 个用例逐条行为评估（需准备夹具） /skill-test category review-all-gdds # 对照 review 类别 R1–R5 指标评估 /skill-test audit # 查看全部技能/Agent 的规格覆盖与最近测试结果

按 CLAUDE.md 的工作流，运行前先读 catalog.yaml 取该技能条目的spec:权威路径与category:（本技能为review）。需要特别留意的是，本框架的规格描述的是当前行为而非理想行为，规格失败应视为「需要调查」，而非「技能必然有错」——当技能实际表现与规格不符时，应先修正技能本体，再同步更新规格。

总结

/review-all-gdds以「双阶段并行 + 三档结论 + 严格只读 + 零导演 Gate」四个设计要点，成为 CCGS 系统设计阶段通往架构阶段前的整体质量闸门：Phase 1 保证多文档在规则、公式、引用、所有权四个维度上不打架，Phase 2 保证整体玩法在支柱、策略、认知、经济四个理论维度上不失控，最终通过 CONSISTENT / MINOR ISSUES / MAJOR ISSUES 三档结论驱动清晰的下一步动作。它的行为规格既是一份可执行的测试契约（6 项静态断言 + 5 个行为用例 + 协议合规清单），也是理解 CCGS「先整体评审、后架构落地」协作流水线如何保证设计一致性的最佳切片。

【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios