深入解析 Claude Code Game Studios 的 /architecture-review 架构评审技能规格、裁决体系与 Director 门禁机制【免费下载链接】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/architecture-review是 Claude Code Game StudiosCCGS这一 AI 游戏开发工作室框架中的核心架构质量把关技能。它以 Opus 级能力对技术架构文档执行八大必需章节的完整性校验、内部一致性审查、与既有 ADR 的矛盾检测以及引擎版本锁定校验最终输出 APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED 三档裁决。读完本文你将完整掌握该技能的规格骨架、full/lean/solo 三种评审模式下 Director 门禁TD-ARCHITECTURE 与 LP-FEASIBILITY的并行签发逻辑、五条标准测试用例的判定边界以及它与/create-architecture、TR 注册表等上下游工作流的衔接方式。一、技能定位架构文档的技术总闸在 CCGS 的 72 个技能体系中/architecture-review被归类于review类别并在 catalog.yaml 中标记为priority: critical——与gate-check、design-review、story-readiness等控制阶段流转的关键技能同级。技能测试框架 README.md 用一句话概括了 review 类别的共性职责Read-only, 8-section check, correct verdicts只读、八节检查、正确裁决。其核心职责可拆解为四重校验全部围绕一份架构文档展开结构完整性校验对照项目规定的 8 个必需架构章节逐一检查输出 N/8 sections present 式的完成度报告内部一致性校验检查文档自身各章节之间是否自洽不存在前后矛盾ADR 一致性校验将文档与docs/architecture/目录下已 Accepted 的架构决策记录ADR交叉比对检测是否存在冲突引擎版本锁定校验核对文档引用的引擎版本是否与docs/engine-reference/中锁定的版本一致。该技能被明确标注为read-only只读整个评审过程不写任何文件。这一特性同时体现在其行为规格的静态断言中——技能体中不得出现 May I write 之类的写权限请求语言。1.1 在项目生命周期中的位置从工作流视角看/architecture-review处于架构编写 → 架构评审 → 细化实施链条的中段上游由 create-architecture.md 描述的作者技能/create-architecture以 skeleton-first 方式逐节起草架构文档其规格明确要求以/architecture-review或/create-control-manifest作为结尾交接下游评审通过后技能以下一步交接next-step handoff指向/create-control-manifest或/create-epics将架构决策落实为控制清单与史诗级任务旁路GDD 全量评审技能 review-all-gdds.md 在发现需要技术架构层面的裁决时同样会交接给/architecture-review写入方虽然评审本身只读但 tr-registry.yaml 的注释明确指出技术需求 IDTR-ID注册表由/architecture-review追加新条目永不覆盖供/create-stories、/story-done、/story-readiness等下游技能读取——这是它唯一与写沾边的责任且仅以追加形式发生。1.2 裁决词汇表技能只输出三种裁决不允许自由发挥裁决触发条件含义APPROVED8/8 章节齐全且无 ADR 冲突、无引擎版本偏差架构文档通过可进入/create-control-manifest或/create-epicsNEEDS REVISION结构基本完整但存在与既有 ADR 的矛盾或局部问题需定向修订无需推翻重来MAJOR REVISION NEEDED缺少 ≥2 个必需章节或存在严重结构缺陷需大改文档当前不可放行二、Director 门禁机制full / lean / solo 三模式/architecture-review最具特色的机制是Director Gate总监门禁。在full完整评审模式下技能读完架构文档后会并行派生两个总监级门禁代理TD-ARCHITECTURE技术总监对应 technical-director.md 中定义的technical-director代理负责系统架构决策与技术可行性评估。该代理属于Opus 模型层级catalog 中的 Tier 1 Directors裁决词汇为APPROVE / CONCERNS / REJECT输出格式如TD-ARCHITECTURE: APPROVELP-FEASIBILITY主程对应 lead-programmer.md 中定义的lead-programmer代理负责代码架构与可行性评估属于Sonnet 模型层级Tier 2 Leads裁决词汇为FEASIBLE / CONCERNS / INFEASIBLE输出格式如LP-FEASIBILITY: INFEASIBLE。两者的职责边界在各自的测试规格中被严格划定TD 不得对玩法是否有趣、是否符合创意愿景发表意见LP 不得对数值平衡是否合理做绑定式评估——越界请求必须重定向到creative-director或systems-designer等正确归属方。2.1 三种模式的行为差异模式门禁行为输出表现fullTD-ARCHITECTURE 与 LP-FEASIBILITY并行派生两者均完成后才给出裁决两个门禁均以completed gate身份出现在输出中lean两个门禁均跳过输出注明TD-ARCHITECTURE skipped — lean mode与LP-FEASIBILITY skipped — lean modesolo两个门禁均跳过同样注明skipped — solo mode裁决仅基于结构检查评审模式的读取来源是production/session-state/review-mode.txt——即门禁是否触发取决于会话状态文件中保存的评审模式值而不是用户临时口头要求。这也是 review 类别质量指标R4分析阶段不得触发 Director 门禁的例外依据所在quality-rubric.md 明确解释——架构评审风险高、值得总监签字背书R4 得以满足是因为门禁运行在分析完成之后而非分析之中。2.2 门禁的实质工作内容从 technical-director.md 的测试用例可以还原 TD-ARCHITECTURE 门禁的实际审查方式情境一架构评审面对分层架构输入层 → 游戏逻辑层 → 表现层TD 应确认系统边界划分正确、接口定义清晰返回TD-ARCHITECTURE: APPROVE情境三可行性面对每帧对 1000 个实体做射线检测这类 O(n²) 复杂度提案TD 应返回TD-FEASIBILITY: CONCERNS并给出算法复杂度与实体数阈值同时建议空间分区或兴趣管理等替代方案但不得强制指定情境五上下文约束当门禁上下文给出移动端、60fps、2GB 内存、无 Compute Shader等平台约束时TD 必须引用具体约束评估架构组件如 GPU 驱动渲染管线与平台限制冲突并据此返回 CONCERNS 或 REJECT而非给出脱离约束的泛泛建议。lead-programmer.md 则侧重代码级可行性例如每帧对 200 敌人做暴力最近邻搜索应判LP-FEASIBILITY: INFEASIBLE并引用帧预算数据如 16.67ms 总帧预算、AI 系统分得 4ms结合提交方给出的 7ms 实测估计指出超出 3ms 的偏差——评审结论必须可追溯到具体数字而非可能有点慢这类空话。三、行为规格全解析从静态断言到协议合规3.1 静态断言结构层/architecture-review的规格文件本身可作为一项可自动验证的测试对象。/skill-test static无需任何 fixture 即可完成以下结构断言拥有完整 frontmatter 字段name、description、argument-hint、user-invocable、allowed-tools包含 ≥2 个阶段标题phase headings包含三种裁决关键词APPROVED、NEEDS REVISION、MAJOR REVISION NEEDED不包含 May I write 语言只读技能的特性标志结尾存在下一步交接next-step handoff文档化门禁行为full 模式下 TD-ARCHITECTURE LP-FEASIBILITYlean/solo 模式下跳过。这些静态断言与 skill-test-spec.md 模板中定义的五类检查frontmatter、phase heading、verdict keyword、May-I-write 或只读、handoff一脉相承是框架内所有技能规格的通用基线。3.2 协议合规清单评审过程必须同时满足以下协议约束不写任何文件只读技能先呈现章节完成度检查再给出裁决full 模式下 TD-ARCHITECTURE 与 LP-FEASIBILITY并行派生而非串行lean/solo 模式下被跳过的门禁须按名称 模式显式注明裁决严格限定为三种词汇之一结尾根据裁决给出恰当的下一步交接。值得强调的是先呈现检查结果、后给出裁决这一顺序约束——它对应 review 类别质量指标R5结构化发现输出中必须在最终裁决之前包含逐节状态表或清单而不是一股脑的散文式意见。四、五条标准测试用例判定边界的精确刻画规格以五条测试用例锚定了技能行为的可验证边界每条均含 fixture前置项目状态、输入、预期行为与断言。4.1 Case 1Happy Path——完整架构文档 full 模式Fixturedocs/architecture/architecture.md存在且 8 个必需章节全部填充所有章节引用的引擎版本与docs/engine-reference/一致与docs/architecture/中已 Accepted 的 ADR 无矛盾production/session-state/review-mode.txt内容为full。输入/architecture-review docs/architecture/architecture.md预期流程读取架构文档 → 读取既有 ADR 交叉引用 → 读取引擎版本参考 → 并行派生 TD-ARCHITECTURE 与 LP-FEASIBILITY → 两门禁均返回 APPROVED → 输出逐节完成度检查8/8→ 裁决 APPROVED。关键断言8 个必需章节全部被检查并报告两个门禁并行派生而非串行裁决为 APPROVED技能不写任何文件交接目标/create-control-manifest或/create-epics存在。4.2 Case 2Failure Path——缺少必需章节Fixture架构文档存在但缺少至少 2 个必需章节例如没有数据模型章节、没有错误处理章节评审模式为full。预期行为技能识别缺失章节 → 完成度显示低于 8/8 →按名称列出缺失章节并给出具体补救指引 → 裁决MAJOR REVISION NEEDED。关键断言≥2 缺失时裁决必须是 MAJOR REVISION NEEDED而非 APPROVED 或 NEEDS REVISION每个缺失章节在输出中被点名补救指引须具体明确要添加什么而非笼统的补上缺失章节技能绝不放行缺失必需章节的文档。4.3 Case 3Partial Path——与既有 ADR 冲突Fixture架构文档 8 个章节齐全但docs/architecture/中某条 Accepted ADR 建立了与文档相悖的约束如 ADR-001 强制 ECS 模式而架构文档对同一系统采用了不同模式。预期行为技能读取架构文档与全部既有 ADR → 检测到冲突 → 冲突条目点名ADR 编号/标题、双方冲突的章节、影响范围→ 裁决NEEDS REVISION。关键断言单一矛盾时裁决是 NEEDS REVISION而非 MAJOR REVISION NEEDED冲突条目点名具体 ADR 编号与标题两份文档中的冲突章节均被识别技能不自动解决矛盾——它只报告不代行决策。4.4 Case 4Edge Case——文件不存在Fixture提供的路径在项目中不存在。输入/architecture-review docs/architecture/nonexistent.md预期行为尝试读取文件 → 文件未找到 → 输出点名缺失文件的清晰错误 → 建议检查docs/architecture/或运行/create-architecture→不产生任何裁决。关键断言文件缺失时输出清晰错误不产生 APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED 中的任何一种给出纠正性建议不崩溃、不输出残缺报告。4.5 Case 5Director Gate——full 模式派生双门禁 vs solo 模式全部跳过full 模式 fixture架构文档 8 章节齐全review-mode.txt为full。预期 TD-ARCHITECTURE 派生、LP-FEASIBILITY 与之并行派生、两者完成后才签发裁决裁决反映门禁反馈。solo 模式 fixture同一份文档review-mode.txt为solo。预期技能照常读取文档、门禁不派生、输出TD-ARCHITECTURE skipped — solo mode与LP-FEASIBILITY skipped — solo mode、裁决仅基于结构检查产生。关键断言full 模式下两个门禁都作为 completed gate 出现在输出中且并行solo 模式下两者均不以 active gate 出现但跳过注记完整solo 模式仍能基于纯结构检查给出裁决。五、可验证性的体系支撑规格如何被测试与维护5.1 测试工作流/architecture-review的行为规格是 CCGS Skill Testing Framework 质量保障层的一部分。按 CLAUDE.md 定义的测试流程对一项技能进行规格测试需要读取 catalog.yaml 获取技能的spec:权威路径与category:此处为CCGS Skill Testing Framework/skills/review/architecture-review.md与review读取技能本体.claude/skills/[name]/SKILL.md读取spec:路径指向的规格文件逐条评估断言将结果写入results/并更新catalog.yaml。测试命令层面/skill-test static负责自动验证第 3.1 节的结构断言无需 fixture而本文第四节的五条用例属于行为级测试。若技能在实践中行为异常/skill-improve [name]会执行测试 → 诊断 → 提议修复 → 重写 → 重测 → 保留或回退的完整闭环。一个值得注意的框架约定CLAUDE.md 明确写出规格描述的是当前行为而非理想行为它们由阅读技能本体写成因此可能编码了 bug。遇到规格失败正确的处理是先修技能再更新规格以匹配修复后的行为并把规格失败视为需要调查的信号而非技能确实错了的定论。5.2 质量评分标准中的审查定位review 类别在 quality-rubric.md 下共有五条二元 PASS/FAIL 指标/architecture-review是其中最典型的适用对象R1 — 只读强制不得在未经用户明确批准下修改被评审文档任何写操作评审日志、索引更新必须由 May I write 把关R2 — 八节检查显式评估全部 8 个必需章节或等价的架构章节R3 — 正确裁决词汇裁决严格为 APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED架构类或 PASS / CONCERNS / FAIL设计类R4 — 分析阶段无 Director 门禁architecture-review作为唯一例外被单独说明——门禁运行在分析完成之后这是刻意的架构评审风险高值得总监签字背书R5 — 结构化发现最终裁决前输出逐节状态表或清单。5.3 覆盖边界Coverage Notes规格文件末尾诚实地划定了测试覆盖的边界这些信息对理解技能的验证深度至关重要8 个必需架构章节是项目特定的测试使用技能本体中定义的章节列表规格内不重复枚举——意味着新增章节时只需改技能本体无需同步改规格引擎版本兼容性检查与docs/engine-reference/交叉引用属于 Case 1 happy path 的一部分但未作为独立用例做 fixture 测试RTM 模式需求追踪矩阵模式是/architecture-review技能自身rtm参数模式下的独立关注点不在本规格测试范围内。此外与评审配套的 TR-ID 注册表 tr-registry.yaml 展示了架构评审的落地产物约定技术需求 ID 采用TR-[system-slug]-[NNN]格式如TR-combat-001ID 永久有效、只追加不重排、改写需求时更新requirement文本并追加revised日期、移除时置status: deprecated——这套规则确保跨/architecture-review多次运行不会打乱 ID 顺序从而不破坏下游 story 的引用。六、结语评审即门禁规格即契约/architecture-review的价值不在于检查格式而在于把架构是否可放行这一高风险决策拆解成可重复、可验证、可追责的流程以 8 章节完成度为结构底线以 ADR 交叉比对为一致性红线以引擎版本锁定为技术前提以双 Director 并行门禁为高层背书以三档裁决为明确出口并以只读协议和交接指引保证评审结论能无缝流入实施管线。对于想把这套模式移植到自己团队工作流中的读者最直接的切入点是从 skill-test-spec.md 模板出发为每一个会给出放行/驳回结论的技能补上一份类似本文所剖析的规格——五条用例happy path、failure path、partial path、edge case、director gate、一份协议合规清单、一段覆盖边界说明。规格写得越精确AI 评审的行为就越可预测、可回归、可改进。【免费下载链接】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），仅供参考