Claude-Code-Game-Studios 多 Agent 审查工作流Review Workflow详解代码、设计、架构与跨域变更的分层审批机制【免费下载链接】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-StudiosCCGS的审查工作流文档.claude/docs/review-workflow.md展开系统讲解该开源项目中谁有权审批哪一类变更的四级审查矩阵代码变更由部门负责人审查、设计变更需 game-designer 与 creative-director 双签、架构变更由 technical-director 签核、跨域变更由 producer 统筹。读完本文你将掌握 CCGS 审查体系与 Gate 门禁机制.claude/docs/director-gates.md的完整对应关系理解 review-mode 三档强度full / lean / solo的运作原理并学会在 49 个 AI Agent、72 个工作流技能构成的分层组织中正确判定某次变更应该触发哪一层审批。一、审查工作流总览四条核心规则原文档 .claude/docs/review-workflow.md 以四条规则定义了整个项目的变更审批骨架代码变更Code changes需要相关部门负责人 Agentdepartment lead agent如 lead-programmer审查设计变更Design changes需要game-designer与creative-director双重签核sign-off架构变更Architecture changes需要technical-director签核跨域变更Cross-domain changes需要producer签核。这四条规则本质上是把真实游戏公司的组织结构搬进了 Claude Code 会话负责人对应垂直管理线、双签对应创意共识、技术总监对应架构主权、制作人对应跨部门调度。它们不是孤立的审批动作而是被 .claude/docs/director-gates.md 中定义的数十个具名 Gate如LP-CODE-REVIEW、CD-GDD-ALIGN、TD-ARCHITECTURE、PR-SCOPE以标准化的方式落地执行的。二、规则 1代码变更 — 部门负责人审查与 LP-CODE-REVIEW 门禁Code changes require review by the relevant department lead agent 在技能层由 code-review 技能 承载其 frontmatter 中agent: lead-programmer明确了审批人身份。该技能把代码审查拆成 9 个阶段核心检查项包括Phase 3 — ADR 合规检查搜索 story 文件、提交信息和头注释中的ADR-NNN或docs/architecture/ADR-引用对每个被引用的 ADR 提取 Decision 与 Consequences 章节将偏差分为三类ARCHITECTURAL VIOLATION阻塞级使用了 ADR 明确拒绝的模式、ADR DRIFT警告级、MINOR DEVIATION信息级Phase 4 — 编码标准合规公开方法/类有文档注释、圈复杂度 10、单方法不超过 40 行、依赖注入游戏状态禁止静态单例、配置值从数据文件加载、系统暴露接口而非具体类依赖Phase 5 — 架构与 SOLID依赖方向正确engine ← gameplay、模块间无循环依赖、UI 不持有游戏状态、跨系统通信使用事件/信号、五条 SOLID 原则逐一核查Phase 6 — 游戏专项帧率无关性delta time、热路径update 循环零分配、空/空值状态处理、线程安全、资源清理无泄漏Phase 7 — 专家并行复审按引擎配置.claude/docs/technical-preferences.md 的 Engine Specialists 节并行 spawn 引擎专家.gd/.cs/.cpp→ 语言专家、shader 文件 → shader 专家、UI 代码 → UI 专家对 Logic/Integration 类 story 还并行 spawnqa-tester评估可测试性。最终输出包含 9 个区块的结构化审查报告Verdict 三档为APPROVED / APPROVED WITH SUGGESTIONS / CHANGES REQUIRED且该技能是只读的不写任何文件。这与 director-gates.md 中 Tier 2 的LP-CODE-REVIEW门禁完全对应——该门禁在/dev-story、/story-done或/code-review时触发要求对照 story 验收标准与管辖 ADR 检查实现。三、规则 2设计变更 — 双签机制game-designer creative-director设计变更的双签体现为单人深度审查 创意总监终审的两层结构由 design-review 技能 实现第一层 — 结构审查Phase 2 对照设计文档标准清单检查 8 个必需章节Overview、Player Fantasy、Detailed Rules、Formulas、Edge Cases、Dependencies、Tuning Knobs、Acceptance Criteria并做依赖图验证——对 Dependencies 节每个系统用 Glob 确认其 GDD 是否存在于design/gdd/不存在的标记为断裂引用第二层 — 对抗式专家评审full 模式强制按 GDD 涉及的领域并行 spawn 多个专家 Agent包括基线必选的game-designer与systems-designer以及按需加入的 economy-designer、ai-programmer、level-designer、ux-designer、network-programmer 等Phase 3b 提供完整的领域→Agent 映射表。关键约束是必须发出真实 Task 调用禁止内部模拟专家视角第三层 — 创意总监综合所有专家反馈收集后spawncreative-director作为高级评审者做最终裁决senior verdict专家之间的分歧必须显式列出供用户仲裁不得静默化解。这正是原文档Design changes require sign-off fromgame-designerandcreative-director的落地形态。对应到 Gate 体系设计类门禁还包括CD-PILLARS支柱压力测试、CD-GDD-ALIGNGDD 与支柱对齐、CD-SYSTEMS系统分解愿景检查等。design-review 的裁决等级为APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED其 Phase 5 用三个连续的AskUserQuestion部件处理修订、系统索引更新与评审日志追加design/gdd/reviews/[doc-name]-review-log.md确保复审可追踪。四、规则 3架构变更 — technical-director 签核与 TD 系列门禁Architecture changes require sign-off fromtechnical-director 由两条执行路径承载4.1 architecture-review架构的全面审计architecture-review 技能 是架构版的 design-reviewfrontmatter 标注agent: technical-director、model: opus。它提供 5 种聚焦模式full全部阶段、coverage仅追踪缺口、consistency仅跨 ADR 冲突、engine仅引擎兼容性审计、single-gdd [path]单 GDD 覆盖审查以及rtm模式——构建 GDD 需求 → ADR → Story → 测试文件的完整需求追踪矩阵输出到docs/architecture/requirements-traceability.md。其核心产出是追踪矩阵从每个 GDD 提取技术需求数据结构、性能约束、引擎能力、跨系统通信、状态持久化、线程/时序、平台需求七大类生成稳定的TR-[system]-NNN编号与 docs/architecture/tr-registry.yaml 中的既有条目匹配复用绝不重编号再逐条核对 ADR 覆盖状态✅ Covered / ⚠️ Partial / ❌ Gap。随后是跨 ADR 冲突检测数据所有权、集成契约、性能预算、依赖环、架构模式、状态管理六类冲突与 ADR 依赖拓扑排序最后是引擎兼容性交叉检查版本一致性、post-cutoff API、废弃 API、缺失 Engine Compatibility 章节。4.2 TD 系列门禁架构签核的标准化判定director-gates.md 定义了 technical-director 名下的 6 个门禁覆盖架构生命周期门禁 ID触发时机判定词TD-SYSTEM-BOUNDARY/map-systems依赖映射完成、GDD 编写前APPROVE / CONCERNS / REJECTTD-FEASIBILITY头脑风暴 Phase 6 或早期概念含技术未知项VIABLE / CONCERNS / HIGH RISKTD-ARCHITECTURE主架构文档起草后/create-architecturePhase 7APPROVE / CONCERNS / REJECTTD-ADR单个 ADR 编写后、标记 Accepted 前APPROVE / CONCERNS / REJECTTD-ENGINE-RISK触碰 post-cutoff 引擎 API 的架构决策APPROVE / CONCERNS / REJECTTD-PHASE-GATE每次/gate-check与 CD/PR/AD 并行READY / CONCERNS / NOT READY以TD-ARCHITECTURE为例其审查要点为(1) 每个技术需求是否都有对应架构决策覆盖(2) 所有 HIGH RISK 引擎域是否被显式处理或标记为开放问题(3) API 边界是否干净、最小、可实现(4) Foundation 层 ADR 缺口是否在实现前解决——这与 .claude/docs/coordination-rules.md 中技术冲突升级到 technical-director的规则互为表里。五、规则 4跨域变更 — producer 统筹与 PR 系列门禁Cross-domain changes require sign-off fromproducer 对应 .claude/docs/coordination-rules.md 中的两条协调规则Rule 4 — Change Propagation当设计变更影响多个领域时由producer协调传播Rule 5 — No Unilateral Cross-Domain ChangesAgent 未经显式授权不得修改其指定目录之外的文件。producer 名下共有 5 个门禁PR-SCOPE范围与时间线校验REALISTIC / OPTIMISTIC / UNREALISTIC、PR-SPRINT冲刺可行性REALISTIC / CONCERNS / UNREALISTIC、PR-MILESTONE里程碑风险评估ON TRACK / AT RISK / OFF TRACK、PR-EPIC史诗结构可行性REALISTIC / CONCERNS / UNREALISTIC、PR-PHASE-GATE阶段转换生产就绪度READY / CONCERNS / NOT READY。跨域变更的协同在 .claude/docs/agent-coordination-map.md 的 Common Workflow Patterns 中有完整呈现例如新功能全流水线模式中producer 在第 3 步排期、识别依赖在第 13 步标记任务完成里程碑检查点模式中 producer 主持 go/no-go 讨论并在所有总监达成一致后记录决策。六、审查的强度控制Review Mode 三档机制审查工作流文档的四条规则是必须审批的默认前提但 CCGS 提供了可配置的强度控制让单人开发者不会被困在繁重的审批流程中。根据 .claude/docs/director-gates.md 的 Review Modes 章节全局配置production/review-mode.txt单行写入full、lean或solo三选一在/start时设置一次之后直接编辑文件即可修改。单次运行覆盖任何使用门禁的技能都接受--review [full|lean|solo]参数只对该次运行生效/brainstorm space horror → 使用全局模式 /brainstorm space horror --review full → 本次强制 full 模式 /architecture-decision --review solo → 本次跳过所有门禁模式执行内容适用场景full所有门禁激活每个工作流步骤都审查团队、学习型用户、希望每一步都获得总监反馈lean仅 PHASE-GATE/gate-check技能级门禁跳过默认值——独立开发者与小团队仅在里程碑节点让总监审查solo任何地方都不运行总监门禁Game Jam、原型阶段、追求极限速度每次 spawn 门禁前的强制解析顺序为--review参数 production/review-mode.txt 默认lean。解析结果决定是否 spawnsolo跳过所有门禁并在输出中注明[GATE-ID] skipped — Solo modelean仅保留四个 PHASE-GATECD / TD / PR / ADfull正常 spawn。七、并行门禁协议与裁决升级规则跨域变更审查规则 4的最典型场景是阶段转换。/gate-check会并行spawn 四位总监详见 gate-check 技能 的 Director Panel Assessment 阶段Spawn in parallel先发出全部 Task 调用再等待结果: 1. creative-director → gate CD-PHASE-GATE 2. technical-director → gate TD-PHASE-GATE 3. producer → gate PR-PHASE-GATE 4. art-director → gate AD-PHASE-GATE 收集四个裁决后应用升级规则: - 任一 NOT READY / REJECT → 总体裁决最低为 FAIL - 任一 CONCERNS → 总体裁决最低为 CONCERNS - 全部 READY / APPROVE → 才可判 PASS仍需通过物项检查所有 Gate 统一返回三种裁决技能必须处理全部三种裁决含义默认动作APPROVE / READY无问题继续继续工作流CONCERNS [list]有问题但不阻塞通过AskUserQuestion呈现给用户Revise flagged items/Accept and proceed/Discuss furtherREJECT / NOT READY [blockers]阻塞性问题不得继续向用户列出阻塞项在解决前不写文件、不推进阶段门禁结果需记录在相关文档的状态头中 **[Director] Review ([GATE-ID])**: APPROVED [date] / CONCERNS (accepted) [date] / REVISED [date]阶段门禁记录在docs/architecture/architecture.md或production/session-state/active.md。/gate-check还会在出裁决前执行Chain-of-Verification生成 5 个反证问题逐一复核裁决并在 PASS 后把新阶段名写入production/stage.txt以更新状态栏。八、审查在各生产阶段的门禁覆盖矩阵原文档的四条规则覆盖全部阶段director-gates.md 末尾给出了完整矩阵。CCGS 的 7 个生产阶段Concept → Systems Design → Technical Setup → Pre-Production → Production → Polish → Release各阶段必需与可选门禁如下阶段必需门禁可选门禁ConceptCD-PILLARS, AD-CONCEPT-VISUALTD-FEASIBILITY, PR-SCOPESystems DesignTD-SYSTEM-BOUNDARY, CD-SYSTEMS, PR-SCOPE, CD-GDD-ALIGN每个 GDDND-CONSISTENCY, AD-VISUALTechnical SetupTD-ARCHITECTURE, TD-ADR每个 ADR, LP-FEASIBILITY, AD-ART-BIBLETD-ENGINE-RISKPre-ProductionPR-EPIC, QL-STORY-READY每个 story, PR-SPRINT, 四个 PHASE-GATE经 gate-checkCD-PLAYTESTProductionLP-CODE-REVIEW每个 story, QL-STORY-READY, PR-SPRINT每个 sprintPR-MILESTONE, QL-TEST-COVERAGE, AD-VISUALPolishQL-TEST-COVERAGE, CD-PLAYTEST, PR-MILESTONEAD-VISUALRelease四个 PHASE-GATE经 gate-checkQL-TEST-COVERAGE从这个矩阵可以清晰看到四条规则的分布代码审查LP-CODE-REVIEW密集出现在 Production 阶段设计签核CD-*系列集中在 Concept 与 Systems Design架构签核TD-*系列集中在 Technical Setup而 producer 的PR-*门禁贯穿 Pre-Production 至 Release——这正是跨域统筹职责的体现。九、扩展新门禁与维护规范当新的技能或工作流需要新门禁时director-gates.md 规定了三条维护规则门禁 ID 规范[DIRECTOR-PREFIX]-[DESCRIPTIVE-SLUG]现有前缀CD-TD-PR-LP-QL-ND-AD-新 Agent 增加新前缀如AudioDirector → AU-、UX → UX-五字段完整每个门禁必须包含 Trigger、Context to pass、Prompt、Verdicts 及特殊处理说明技能中只引用 ID技能通过 ID 引用门禁绝不内联复制 Prompt 文本——这避免了提示词更新时的漂移drift正是 .claude/docs/review-workflow.md 这类短规则 集中式定义设计的核心动机。这一短规则文档 集中门禁库的组合让 CCGS 在保持四条审批规则极简可读的同时把完整的审查深度沉淀在 .claude/docs/director-gates.md 单一事实源中并经由 .claude/docs/coordination-rules.md垂直委派、水平咨询、冲突升级、变更传播四条协调规则与 .claude/docs/agent-coordination-map.md组织层级、委派矩阵、升级路径、九种工作流模式形成闭环。审查工作流因此不再是一纸约定而是由 49 个 Agent、72 个技能和数十个标准化 Gate 共同执行的可运行工程机制。【免费下载链接】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），仅供参考