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本指南系统讲解 Claude Code Game Studios 中负责全量 GDD 整体评审的/review-all-gdds技能它同时读取design/gdd/下全部系统设计文档运行跨 GDD 一致性与游戏设计整体性两类互补评审捕捉单文档评审无法发现的矛盾、支柱漂移与主导策略。读完本文你将掌握该技能的四种聚焦模式、七个执行阶段、完整的报告模板与交接协议并了解仓库中配套的测试规格与质量标尺如何保障它的行为可被自动化验证。一、技能定位为什么单 GDD 评审不够游戏设计文档GDD逐一评审时每份文档内部可能完全自洽——公式自洽、章节齐全、可实现性良好。但系统之间的交互关系只有在同时看到所有 GDD 时才会暴露问题。/review-all-gdds正是为此而生它执行两类互补评审跨 GDD 一致性Cross-GDD Consistency——文档之间的矛盾、过期引用、所有权冲突游戏设计整体性Game Design Holism——只有把全部系统放在一起看才会浮现的问题主导策略、经济失衡、认知过载、支柱漂移、互相竞争的进度循环。技能在 SKILL.md 中明确强调这与/design-review是两回事。/design-review评审单个 GDD 的内部完整性八段式设计标准Overview、Player Fantasy、Detailed Rules、Formulas、Edge Cases、Dependencies、Tuning Knobs、Acceptance Criteria而/review-all-gdds评审的是所有 GDD 之间的关系。两者的测试规格也做了明确分工/design-review的规格文件 design-review.md 在 Coverage Notes 中注明跨系统一致性检查不在本规格测试范围内因为它需要多个 GDD 文件对比这由/review-all-gdds规格覆盖。运行时机技能的 frontmatter 中明确给出了三个触发时机所有 MVP 级 GDD 各自通过审批之后即/design-review全部通过之后制作中期任何 GDD 被大幅修订之后此时文档间的引用最容易过期/create-architecture开始之前——建立在相互矛盾的 GDD 之上的架构会继承这些矛盾。从流水线看README.md 将/review-all-gdds归入Game Design技能组与/brainstorm、/map-systems、/design-system、/quick-design、/propagate-design-change并列而 catalog.yaml 将其标注为priority: critical、category: review与gate-check、design-review、story-readiness、story-done、architecture-review并列是控制阶段转换的关键技能之一。二、调用方式与四种聚焦模式技能的参数通过$ARGUMENTS[0]传入省略时默认执行full模式/review-all-gdds [focus: full | consistency | design-theory | since-last-review]参数执行内容适用场景无/full一致性 设计理论两轮检查标准流程架构开始前必跑consistency仅跨 GDD 一致性检查更快时间紧张或仅关注文档间矛盾design-theory仅游戏设计整体性检查只关注设计理论层面的问题since-last-review仅评审上次评审报告之后被修改过的 GDD基于 git增量迭代节省 tokensince-last-review模式会运行git log --name-only找出自上次评审报告文件写入以来修改过的 GDD先向用户展示范围内文档再做全量读取且只对这些 GDD以及它们在 Key deps 中列出的依赖 GDD执行 L1 全量读取。执行模型与工具边界frontmatter 定义了该技能的执行约束见 SKILL.md模型opusOpus 档负责高难度整体评审可调用工具Read, Glob, Grep, Write, Bash, AskUserQuestion, Task——注意它在授权列表中但写入一律需要用户确认用户可调用user-invocable: true即用户可直接以斜杠命令触发。并行执行模型是技能的重要特征Phase 2一致性与 Phase 3设计理论读取相同的 GDD 输入但产出独立的报告两者相互独立技能要求同时以并行 Task 代理方式发起而不是等 Phase 2 完成后再启动 Phase 3两个结果收集齐后才合并撰写报告。这一行为被测试规格 review-all-gdds.md 的 Protocol Compliance 显式断言Phase 1一致性与 Phase 2设计理论必须并行发起——而非顺序执行。三、Phase 1加载一切Load Everything评审的第一步是把所有输入加载进来分为三级递进的读取目标是先省 token再决定读什么。Phase 1a — L0摘要扫描快速、低 token在读取任何完整文档之前先用 Grep 抽取所有 GDD 的## Summary段落Grep pattern## Summary globdesign/gdd/*.md output_modecontent -A 5随后向用户展示清单Found [N] GDDs. Summaries: • combat.md — [summary text] • inventory.md — [summary text] ...since-last-review模式在此阶段额外执行git log --name-only圈定范围先展示范围内 GDD 再进入全量读取。Phase 1b — 注册表预载快速基线在全文读取前检查实体注册表Read pathdesign/registry/entities.yaml该文件是仓库中真实存在的基础设施位于 entities.yaml其头部注释明确列出了读者之一就是/review-all-gddsPhase 1 — baseline for Phase 2 checks。注册表维护所有跨系统边界出现的命名事实entities / items / formulas / constants的权威值与来源 GDD若注册表存在且有条目将它作为预构建的冲突基线Phase 2 中先 grep 注册过的名字比盲目全文读取更快若注册表为空或缺失照常继续但必须在报告中注明Entity registry is empty — consistency checks rely on full GDD reads only. Run/consistency-checkafter this review to populate the registry.——这也印证了/consistency-check分析类技能与本技能的分工前者负责在解决冲突后回填注册表。注册表还提供了现成的 Grep 检索模式可加速本技能的一致性扫描例如全部实体名Grep pattern^ - name: pathdesign/registry/entities.yaml某 GDD 拥有什么Grep patternsource: design/gdd/combat.md已废弃条目Grep patternstatus: deprecatedPhase 1c — L1/L2全量文档加载对范围内文档进行完整读取design/gdd/game-concept.md—— 游戏愿景、核心循环、MVP 定义design/gdd/game-pillars.md若存在—— 设计支柱与反支柱design/gdd/systems-index.md—— 权威系统列表、分层、依赖、状态design/gdd/下每一份范围内的系统 GDD——完整读取game-concept.md 与 systems-index.md 已在上方读过跳过。加载完成后汇报Loaded [N] system GDDs covering [M] systems. Pillars: [list]. Anti-pillars: [list].最低数量门槛如果系统 GDD少于 2 份立即停止并输出Cross-GDD review requires at least 2 system GDDs. Write more GDDs first, then re-run/review-all-gdds.这一少于 2 份 GDD 不产出结论的行为也被测试规格的 Case 4Edge Case——design/gdd/为空与 Case 5 覆盖目录为空时技能必须输出明确错误、不产出 verdict、不崩溃、不产出一半的报告并推荐先运行/brainstorm与/design-system再回来重跑。四、Phase 2跨 GDD 一致性检查对每对/每组 GDD 逐一工作寻找矛盾与缺口共六个子检查。2a依赖双向性Dependency Bidirectionality对每份 GDD 的 Dependencies 段落检查每个依赖是否双向成立若 GDD-A 写 depends on GDD-B检查 GDD-B 是否列出 GDD-A 为依赖者若 GDD-A 写 depended on by GDD-C检查 GDD-C 是否列出 GDD-A 为依赖项任何单向依赖都标记为一致性问题⚠️ Dependency Asymmetry [system-a].md lists: Depends On → [system-b].md [system-b].md does NOT list [system-a].md as a dependent → One of these documents has a stale dependency section测试规格 Case 3Partial Path验证了孤儿依赖引用这一变体GDD-A 在 Dependencies 中指向不存在的 system-B 时应报告为DEPENDENCY GAPverdict 为 MINOR ISSUES依赖缺口本身只是建议级不单独阻塞并建议运行/design-system system-B补齐绝不能静默忽略。2b规则矛盾Rule Contradictions对任何 GDD 中定义的规则、机制或约束检查是否有其他 GDD 对同一情境定义了矛盾规则。需要扫描的类别下限/上限规则某 GDD 定义了输出的最小值另一 GDD 却说某机制可以绕过该下限——直接矛盾资源所有权两份 GDD 都定义了共享资源的积累/消耗时是否一致状态转换GDD-A 描述角色死亡时发生什么GDD-B 对同一事件的描述是否一致时序GDD-A 说 X 在同一帧发生GDD-B 是否假设它是异步的叠加规则GDD-A 说状态效果可叠加GDD-B 是否假设不可叠加。 Rule Contradiction [system-a].md: Minimum [output] after reduction is [floor_value] [system-b].md: [mechanic] bypasses [system-a]s rules and can reduce [output] to 0 → These rules directly contradict. Which GDD is authoritative?这正是测试规格 Case 2Failure Path的夹具GDD-A 定义下限值、GDD-B 定义绕过下限的机制期望行为是检测到矛盾、报告两个文件名与具体矛盾规则、严重度 HIGH、verdict 为 MAJOR ISSUES且技能不自动解决冲突。2c过期引用Stale References对每个跨文档引用GDD-A 提到 GDD-B 中的机制、数值或系统名验证被引用元素在 GDD-B 中仍以相同名称与行为存在GDD-A 说 combo multiplier from the combat system feeds into score检查战斗 GDD 是否真的定义了输出到分数的大厅倍数GDD-A 引用 the progression curve defined in [system].md检查该文件是否真有那条曲线GDD-A 写于 GDD-B 之前、假设了 GDD-B 后来不同设计的机制——标记 GDD-A 含过期引用。⚠️ Stale Reference inventory.md (written first): Item weight uses the encumbrance formula from movement.md movement.md (written later): Defines no encumbrance formula — uses a flat carry limit instead → inventory.md references a formula that doesnt exist2d数据与调优旋钮所有权冲突Ownership Conflicts两份 GDD 不应同时声称拥有同一数据或调优旋钮。扫描所有 GDD 的 Tuning Knobs 段落并标记重复⚠️ Ownership Conflict [system-a].md Tuning Knobs: [multiplier_name] — controls [output] scaling [system-b].md Tuning Knobs: [multiplier_name] — scales [output] with [factor] → Two GDDs define multipliers on the same output. Which owns the final value? This will produce either a double-application bug or a design conflict.所有权的概念与实体注册表的source:字段一脉相承——注册表规定每个事实只有一个权威来源 GDD其他引用它的 GDD 把自己记入referenced_by正是为了从工具层面防止这类双重所有权。2e公式兼容性Formula Compatibility对输出作为另一公式输入的连接公式检查上游输出范围是否落在下游期望输入范围内若 system-a 输出 [min]–[max]而 system-b 设计接收 [min2]–[max2]错配是否刻意为之若经济 GDD 期望资源获取量在 X 区间而进度 GDD 生成量在 Y 区间经济会变得无关紧要或不可达——这是否是设计意图公式错配标记为CONCERNS需要设计判断不一定错误⚠️ Formula Range Mismatch [system-a].md: Max [output] [value_a] (at max [condition]) [system-b].md: Base [input] [value_b], max [input] [value_c] → Late-[stage] [scenario] can resolve in a single [event]. Is this intentional? If not, either [system-a]s ceiling or [system-b]s ceiling needs adjustment.2f验收标准互查Acceptance Criteria Cross-Check扫描所有 GDD 的 Acceptance Criteria 段落寻找矛盾GDD-A 标准Player cannot die from a single hitGDD-B 标准Boss attack deals 150% of player max health这两条验收标准不可能同时通过——必须标记。五、Phase 3游戏设计整体性检查以游戏设计理论与玩家心理学为透镜整体评审所有 GDD。这些问题是单个 GDD 评审无法捕获的因为需要同时看到所有系统。3a进度循环竞争Progression Loop Competition一款游戏应有一个玩家认为是游戏主旨的主导进度循环其余循环作为支撑。当多个系统平等竞争主进度驱动者时玩家不知道游戏核心是什么。扫描所有声称以下特征的系统发放玩家主要资源XP、等级、声望、解锁自称 core 或 main 循环与其他做同样事的系统具有相当深度与时间投入。⚠️ Competing Progression Loops combat.md: Awards XP, unlocks abilities, is described as the core loop crafting.md: Awards XP, unlocks recipes, is described as the primary activity exploration.md: Awards XP, unlocks map areas, described as the main driver → Three systems all claim to be the primary progression loop and all award the same primary currency. Players will optimise one and ignore the others. Consider: one primary loop with the others as support systems.3b玩家注意力预算Player Attention Budget统计典型会话中需要玩家同时保持主动注意的系统数量。每个被主动管理的系统都消耗注意力主动Active 玩家游玩中需要定期对这个系统做决策被动Passive 系统自动运行玩家看到结果但不管理。超过 3–4 个同时主动的系统会造成大多数玩家的认知过载。技能要求给出计数并在超过 4 个并发主动系统时标记⚠️ Cognitive Load Risk Simultaneously active systems during [core loop moment]: 1. [system-a].md — [decision type] (active) 2. [system-b].md — [resource management] (active) 3. [system-c].md — [tracking] (active) 4. [system-d].md — [item/action use] (active) 5. [system-e].md — [cooldown/timer management] (active) 6. [system-f].md — [coordination decisions] (active) → 6 simultaneously active systems during the core loop. Research suggests 3-4 is the comfortable limit for most players. Consider: which of these can be made passive or simplified?3c主导策略检测Dominant Strategy Detection主导策略会让其他策略失去意义——玩家发现它、只用它、然后觉得游戏其余部分无聊。寻找资源垄断某策略生成资源显著快于其他所有策略无风险高收益某策略同时高回报低风险若存在高风险策略它们需要成比例更高的回报无取舍某选项在所有维度上都优于其他所有选项显而易见的优解如果任何进度选择明显正确其余选项就不是真正的选择。⚠️ Potential Dominant Strategy combat.md: Ranged attacks deal 80% of melee damage with no risk combat.md: Melee attacks deal 100% damage but require close range → Unless melee has a significant compensating advantage (AOE, stagger, resource regeneration), ranged is dominant — higher safety, only 20% less damage. Consider what melee offers that ranged cannot.3d经济循环分析Economic Loop Analysis识别所有 GDD 中的全部资源金币、XP、制造材料、体力、生命、法力等对每种资源绘制其来源Sources与消耗Sinks然后标记危险的经济状态条件征兆风险无限来源无消耗资源无限积累后期变得毫无挑战有消耗无来源资源耗尽归零系统变得不可用来源 消耗盈余不断积累资源失去意义消耗 来源持续稀缺挫败与门槛卡点正反馈循环资源越多 → 越容易赚更多领先者滚雪球无追赶机制落后加速扩大赤字不可恢复状态 Economic Imbalance: Unbounded Positive Feedback gold economy: Sources: monster drops (scales with player power), merchant selling (unlimited) Sinks: equipment purchase (one-time), ability upgrades (finite count) → After equipment and abilities are purchased, gold has no sink. Infinite surplus. Gold becomes meaningless mid-game. Add ongoing gold sinks (upkeep, consumables, cosmetics, gambling).3e难度曲线一致性Difficulty Curve Consistency多个系统随玩家进度缩放时必须以兼容的方向与速率缩放。错配的缩放曲线会产生意外难度尖峰或难度崩塌。对每个随时间缩放的系统提取缩放什么敌人血量、玩家伤害、资源成本、区域面积如何缩放线性、指数、阶梯式何时缩放等级、时间、区域。⚠️ Difficulty Curve Mismatch combat.md: Enemy health scales exponentially with area (×2 per area) progression.md: Player damage scales linearly with level (10% per level) → By area 5, enemies have 32× base health; player deals ~1.5× base damage. The gap widens indefinitely. Late areas will become inaccessibly difficult unless the curves are reconciled.3f支柱对齐Pillar Alignment每个系统应至少明确服务一个设计支柱。不服务任何支柱的系统是设计上的范围蔓延scope creep by design——它在游戏里却不服务于游戏想要成为的样子。对每个系统检查其 Player Fantasy 段落与设计支柱的映射标记任何幻想无法对应支柱的系统⚠️ Pillar Drift fishing-system.md: Player Fantasy — peaceful, meditative activity Pillars: Brutal Combat, Tense Survival, Emergent Stories → The fishing system serves none of the three pillars. Either add a pillar that covers it, redesign it to serve an existing pillar, or cut it.同时检查反支柱——任何做了反支柱明确宣称游戏绝不会做之事的系统 Anti-Pillar Violation Anti-Pillar: We will NOT have linear story progression — player defines their path main-quest.md: Defines a 12-chapter linear story with mandatory sequence → This system directly violates the defined anti-pillar.3g玩家幻想一致性Player Fantasy Coherence所有系统的玩家幻想应相互兼容——它们应强化玩家在这款游戏中是谁的一致身份。冲突的玩家幻想造成身份混乱⚠️ Player Fantasy Conflict combat.md: You are a ruthless, precise warrior — every kill is earned dialogue.md: You are a charismatic diplomat — violence is always avoidable exploration.md: You are a reckless adventurer — diving in without a plan → Three systems present incompatible identities. Players will feel the game doesnt know what it wants them to be. Consider: do these fantasies serve the same core identity from different angles, or do they genuinely conflict?六、Phase 4跨系统场景走查从玩家视角走查游戏找出只会在多系统交互边界出现的问题——静态分析单份 GDD 无法浮现的问题。4a识别关键多系统时刻扫描所有 GDD找出 3–5 个多个系统同时激活的最重要的玩家向时刻重点寻找战斗 经济重叠击杀掉落资源、战斗期间消耗资源、死亡/重生与经济状态交互进度 难度重叠战斗中升级触发、能力解锁改变战斗可行性、进度里程碑处的难度缩放叙事 玩法重叠对话选择锁定/解锁机制、剧情节拍打断资源循环、任务完成触发系统状态变化3 系统链条任何玩家动作触发系统 A → 喂给系统 B → 触发系统 C最高风险的交互路径。先列出每个场景及一行描述再继续。4b逐个走查场景对每个场景显式按步骤推演触发Trigger——什么玩家动作或游戏事件启动它激活顺序Activation order——哪些系统激活什么顺序数据流Data flow——每个系统输出什么该输出对链条下一系统是否为有效输入玩家体验Player experience——每一步玩家看到、听到、感觉到什么失败模式Failure modes——是否存在以下任一项竞态条件两个系统同时修改同一状态反馈循环系统 A 放大系统 BB 再放大 A且没有上限或阻尼坏的状态转换某系统假设了前一系统可能已改变的状态例如战斗步骤可能致死但后续假设玩家存活矛盾消息两个系统对同一事件给出冲突反馈如成功音效 失败UI复合难度尖峰两个系统在同一进度点同时放大成倍叠加预期难度增幅奖励冲突两个系统对同一触发各自奖励合计超过预期值双重获利未定义行为GDD 未规定此组合状态下会发生什么两套规则都覆盖不到。技能给出了一个完整走查示例Example walkthrough: Scenario: Player kills elite enemy at level-up threshold during active quest Trigger: Player lands killing blow on elite enemy → combat.md: awards kill XP (100 pts) → progression.md: XP total crosses level threshold → triggers level-up Output: new level, stat increases, ability unlock popup → quest.md: kill-count criterion met → triggers quest completion event Output: quest reward XP (500 pts), completion fanfare → progression.md (again): quest XP added → triggers SECOND level-up in same frame ⚠️ Data flow issue: quest.md awards XP without checking if a level-up is already in progress. progression.md has no guard against concurrent level-up events. Undefined behavior: does the player level up once or twice? Does the ability popup fire twice? Does the second level use the updated or pre-update stat baseline?4c标记场景问题对走查中发现的每个问题按严重度分类BLOCKER阻塞未定义行为、坏的状态转换或矛盾玩家消息——该场景下体验已破坏或不连贯WARNING警告复合尖峰、无上限反馈循环、奖励冲突——体验可用但产出非预期结果INFO提示轻微顺序歧义或消息重叠——值得记录但不太可能造成玩家可见问题。所有发现加入报告的Cross-System Scenario Issues段落每条必须引用场景名、涉及的具体系统、问题发生的步骤、失败模式的性质。七、Phase 5–6输出报告、落盘与状态更新报告模板评审产出一份结构化报告模板如下## Cross-GDD Review Report Date: [date] GDDs Reviewed: [N] Systems Covered: [list] --- ### Consistency Issues #### Blocking (must resolve before architecture begins) [Issue title] [What GDDs are involved, what the contradiction is, what needs to change] #### Warnings (should resolve, but wont block) ⚠️ [Issue title] [What GDDs are involved, what the concern is] --- ### Game Design Issues #### Blocking [Issue title] [What the problem is, which GDDs are involved, design recommendation] #### Warnings ⚠️ [Issue title] [What the concern is, which GDDs are affected, recommendation] --- ### Cross-System Scenario Issues Scenarios walked: [N] [List scenario names] #### Blockers [Scenario name] — [Systems involved] [Step where failure occurs, nature of the failure mode, what must be resolved] #### Warnings ⚠️ [Scenario name] — [Systems involved] [What the unintended outcome is, recommendation] #### Info ℹ️ [Scenario name] — [Systems involved] [Minor ordering ambiguity or note] --- ### GDDs Flagged for Revision | GDD | Reason | Type | Priority | |-----|--------|------|----------| | [system-a].md | Rule contradiction with [system-b].md | Consistency | Blocking | | [system-c].md | Stale reference to nonexistent mechanic | Consistency | Blocking | | [system-d].md | No pillar alignment | Design Theory | Warning | --- ### Verdict: [PASS / CONCERNS / FAIL] PASS: No blocking issues. Warnings present but dont prevent architecture. CONCERNS: Warnings present that should be resolved but are not blocking. FAIL: One or more blocking issues must be resolved before architecture begins. ### If FAIL — required actions before re-running: [Specific list of what must change in which GDD]注意 verdict 词汇是PASS / CONCERNS / FAIL架构类与design-review的APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED设计类形成两套词汇表——这正是质量标尺 quality-rubric.md 中 R3 指标对两类 review 技能的区分。写入授权与索引更新用AskUserQuestion请求写入权限提示 May I write this review todesign/gdd/gdd-cross-review-[date].md?选项[A] Yes — write the report/[B] No — skip若有 GDD 被标记需要修订再用一次AskUserQuestion询问是否更新 systems index选项[A] Yes — update systems index/[B] No — leave as-is若同意将每个被标记 GDD 在design/gdd/systems-index.md中的 Status 字段更新为Needs Revision。此处有一个易被忽视的精确性要求——不要在状态值后追加括号备注因为其他技能会把 Needs Revision 作为精确字符串匹配任何附加括号都会破坏匹配。这一写入全部需要显式授权的行为正是质量标尺 R1Read-only enforcement的落点评审过程中不修改被评审文档所有写操作评审日志、索引更新都必须在 May I write 之后进行。测试规格的 Protocol Compliance 也断言Does NOT write any files without May I write approval 与 Findings table shown before any write ask。会话状态更新写报告若获准还更新了索引之后静默向production/session-state/active.md追加## Session Extract — /review-all-gdds [date] - Verdict: [PASS / CONCERNS / FAIL] - GDDs reviewed: [N] - Flagged for revision: [comma-separated list, or None] - Blocking issues: [N — brief one-line descriptions, or None] - Recommended next: [the Phase 7 handoff action, condensed to one line] - Report: design/gdd/gdd-cross-review-[date].md若active.md不存在则以其为初始内容创建并在对话中确认Session state updated.八、Phase 7交接Handoff所有文件写入完成后用AskUserQuestion提供收尾选项组件。构建选项前先检查项目状态是否存在被标记为30 秒编辑简要补充之类的简单 Warning 级项→ 提供内联快速修复选项是否存在 Flagged for Revision 表中的 GDD→ 为每个提供/design-review选项读取design/gdd/systems-index.md找下一个 Status 为Not Started的系统 → 提供/design-system选项verdict 是否为 PASS 或 CONCERNS→ 提供/gate-check或/create-architecture选项。选项池仅包含实际适用的[_] Apply quick fix: [W-XX description] in [gdd-name].md — [effort estimate]每个简单编辑型警告一个仅 Warning 级不用于 Blocking[_] Run /design-review [flagged-gdd-path] — address flagged warnings每个被标记 GDD 一个[_] Run /design-system [next-system] — next in design order始终包含点名实际系统[_] Run /create-architecture — begin architecture (verdict is PASS/CONCERNS)verdict 非 FAIL 时包含[_] Run /gate-check — validate Systems Design phase gateverdict 为 PASS 时包含[_] Stop here只对被包含的选项分配字母 A、B、C…将最能推进流水线的选项标记为(recommended)。技能绝不以纯文本收尾始终以该组件结束。九、错误恢复协议与协作协议错误恢复协议若任何被派生的代理返回 BLOCKED、报错或未能完成立即浮出继续前先报告 [AgentName]: BLOCKED — [reason]评估依赖若被阻塞代理的输出被后续阶段需要未经用户输入不得越过该阶段继续提供选项通过AskUserQuestion给出三选一跳过该代理并在最终报告中注明缺口以更窄范围重试更少 GDD、单系统聚焦停在这里先解决阻塞。始终产出一份部分报告——无论完成度如何都输出已完成内容保证工作不丢失。协作协议静默阅读——先加载全部 GDD 再呈现任何内容展示一切——在请求任何动作前呈现完整的一致性分析与设计理论分析区分阻塞与建议——不是每个问题都必须阻塞架构要明确哪些会阻塞不做设计决策——标记矛盾与选项但绝不单方面决定哪份 GDD 是对的写前先问——写报告或更新索引前必须确认具体到点——每个问题必须引用确切的 GDD、段落与原文禁止模糊警告。这六条与 README 中声明的项目协作哲学一致Collaborative, Not Autonomous——Agent 提供结构与专业意见用户始终做最终决策。十、仓库中的质量保障测试规格、质量标尺与流水线闭环/review-all-gdds作为critical级技能其行为在仓库中被三层机制锁定1. 行为测试规格review-all-gdds.md 定义了 5 个测试用例Happy Path 无冲突 → CONSISTENTConflicting rules → MAJOR ISSUES孤儿依赖 → MINOR ISSUES无 GDD 文件 → 报错不产 verdict不派生导演门禁代理外加 Protocol Compliance 断言。其中 Case 5 验证了一个关键设计决策该技能不派生任何导演级门禁代理——它本身就是整体评审再委托给导演门禁会形成循环依赖。这与质量标尺 R4分析阶段不派生导演门禁以及 review 类别的整体定义评审技能读取文档并产出结构化结论主要只读不得在分析阶段触发导演门禁相互印证。2. 质量标尺quality-rubric.md 的review类别指标R1–R5直接适用于本技能R1 — 只读强制不静默修改被评审文档R2 — 八段检查显式评估全部 8 个必需 GDD 段落R3 — 正确结论词汇verdict 必须是PASS / CONCERNS / FAIL架构类R4 — 分析阶段无导演门禁分析阶段不派生导演门禁R5 — 结构化发现最终结论前输出按段落的状态表或清单。3. 目录登记catalog.yaml 将其登记为category: review、priority: criticalspec 路径指向CCGS Skill Testing Framework/skills/review/review-all-gdds.md该文件由/skill-test系列工具消费用于执行静态断言与行为测试形成写技能 → 测技能 → 改进技能的闭环参见 CLAUDE.md 的测试工作流。在完整流水线中的位置从技能文档与 README 的综合信息可以确认/review-all-gdds是设计阶段通向架构阶段的整体评审门它运行在所有 MVP GDD 完成与/create-architecture开始之间verdict 为 FAIL 时必须先解决阻塞问题再重跑为 PASS/CONCERNS 时交接组件才会给出/create-architecture或/gate-check选项。从源码结构看它与/consistency-check分析级、负责回填实体注册表、/design-review单文档内部评审、/architecture-review架构级评审形成三级评审体系覆盖单文档 → 全量关系 → 架构的完整质量链路。附快速参考技能本体.claude/skills/review-all-gdds/SKILL.md行为测试规格CCGS Skill Testing Framework/skills/review/review-all-gdds.md质量标尺review 类 R1–R5CCGS Skill Testing Framework/quality-rubric.md技能目录登记CCGS Skill Testing Framework/catalog.yaml实体注册表Phase 1b 基线design/registry/entities.yaml相关技能对照单文档评审 /design-review 规格【免费下载链接】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），仅供参考