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 StudiosCCGS技能框架中负责跨游戏设计文档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负责找出文档之间的结构性冲突覆盖四类问题检查项含义矛盾Contradictions两个 GDD 对同一机制给出互相排斥的规则描述公式不匹配Formula Mismatches同一变量/机制在不同 GDD 中出现数值不一致的公式定义过期引用Stale References引用了已被修改或不再存在的机制/系统所有权冲突Competing Ownership两个 GDD 同时声明对同一实体或机制的归属权Phase 2设计理论检查Design Theory Check负责从游戏设计理论层面做整体评估覆盖四类问题检查项含义主导策略Dominant Strategies是否存在某条策略在多数场景下无条件优于其他选择支柱漂移Pillar Drift各系统是否偏离design/gdd/game-pillars.md定义的设计支柱认知过载Cognitive Overload玩家需要同时记忆/管理的系统负担是否超出合理范围经济失衡Economic Imbalance资源产出source与消耗sink回路是否在跨系统层面失衡为什么必须并行两个阶段之间没有输入依赖一致性扫描不需要设计理论检查的结论反之亦然。规格要求它们同时派生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技能的最终结论必须且只能是三档之一结论触发条件后续交接HandoffCONSISTENT无任何阻塞问题进入架构阶段/architecture-review或/create-architectureMINOR ISSUES存在建议级问题如孤立依赖缺口可以带着已知问题继续但需保持注意may proceed with awarenessMAJOR ISSUES存在 HIGH 级阻塞冲突先修复冲突并重新运行再继续流程交接语义是规格的固定组成部分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.txtreview 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 1Happy Path —— 无冲突的干净 GDD 集合夹具design/gdd/下存在 ≥3 个系统 GDD全部 GDD 内部一致无公式矛盾、无所有权竞争、无过期引用全部与design/gdd/game-pillars.md中定义的设计支柱对齐。期望行为读取design/gdd/下全部 GDD 文件Phase 1一致性与 Phase 2设计理论并行派生Phase 1 未发现矛盾、公式不匹配或所有权冲突Phase 2 未发现支柱漂移、主导策略或认知过载输出结构化发现表0 条阻塞问题结论CONSISTENT。断言两阶段确实并行而非串行输出含发现表空表也显示「No issues found」无冲突时结论为 CONSISTENT无用户批准不写任何文件结尾含向/architecture-review或/create-architecture的交接。Case 2Failure Path —— 两个 GDD 之间的冲突规则夹具GDD-A 定义某下限规则例如「[输出] 的最小值为 [N]」GDD-B 描述了一种可绕过该下限的机制例如「[机制] 可将 [输出] 降至 0」两文档其余部分完整有效。期望行为Phase 1 检测到 GDD-A 与 GDD-B 的矛盾冲突条目同时列出双方文件名、具体冲突规则严重度标记为HIGH结论MAJOR ISSUES交接指示用户先解决冲突并重新运行。断言结论必须是 MAJOR ISSUES而非其他两档两个文件名都被点名矛盾规则被引用或转述不是笼统的「发现冲突」问题被归为 HIGH阻塞级技能不自动解决冲突——它只报告修复是人的工作。Case 3Partial Path —— 单个 GDD 的孤立依赖引用夹具GDD-A 在 Dependencies 部分引用系统 system-B但design/gdd/中不存在 system-B 的 GDD其余 GDD 全部一致。期望行为Phase 1 检测到孤立依赖引用问题报告为DEPENDENCY GAP —— GDD-A 引用了没有对应 GDD 的 system-B未发现其他冲突结论MINOR ISSUES孤立依赖缺口本身是建议级不单独阻塞。断言结论为 MINOR ISSUES单个孤立引用不升级为 MAJOR报告点名 GDD-A 与缺失依赖名技能建议运行/design-system system-B来补缺口技能不会跳过或静默忽略缺失依赖。Case 4Edge Case —— 未找到任何 GDD 文件夹具design/gdd/目录为空或不存在。期望行为技能尝试读取design/gdd/未找到文件——输出带指引的错误信息建议先运行/brainstorm和/design-system再重试不产出任何结论不给出 CONSISTENT / MINOR ISSUES / MAJOR ISSUES。断言目录为空时输出清晰错误无结论产出给出正确的下一步建议技能不崩溃、不产出残缺报告。这与/consistency-check的空目录行为建议/design-system保持一致。Case 5Director Gate —— 任何模式下都不孵化 Gate夹具design/gdd/含 ≥2 个一致的系统 GDDproduction/session-state/review-mode.txt存在且内容为full最宽松模式。期望行为技能读取全部 GDD 并运行两阶段评审不读取review-mode.txt不孵化任何导演 Gate Agent无 CD-、TD-、PR-、AD- 前缀正常完成并输出结论review mode 设置对该技能行为无影响。断言任何时刻都不孵化导演 Gate不读取review-mode.txt输出不含任何Gate: [GATE-ID]或 skipped gate 条目无论何种模式都正常产出结论对应R4 指标该技能在全部模式下 gate 数 0。五个用例一览用例场景结论预期核心验证点Case 1干净 GDD 集合CONSISTENT并行派生、空发现表、交接存在Case 2两 GDD 规则冲突MAJOR ISSUES双方文件名具体规则HIGH 严重度、不自动修复Case 3孤立依赖引用MINOR ISSUES点名 GDD 与缺失系统、建议/design-systemCase 4design/gdd/为空无结论清晰错误、不崩溃、给下一步建议Case 5review-modefull正常结论不读模式文件、0 个 Gate、R40八、协议合规清单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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考