Claude-Code-Game-Studios 团队战斗流水线/team-combat 技能行为测试规范全解析【免费下载链接】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技能测试框架中team类别下的 team-combat 行为测试规范完整解读/team-combat技能如何端到端编排一次战斗功能的团队交付流水线从游戏策划、玩法编程、AI 编程、技术美术、音效设计、引擎专精到 QA 测试的七个角色历经「设计 → 架构 → 并行实现 → 集成 → 验证 → 签收」六个阶段并以AskUserQuestion在每个阶段门禁处征求用户批准。读完本文你将掌握该技能的行为契约、五类测试场景Happy Path、Agent 阻塞、缺参、并行阶段、引擎路由、协议合规清单与覆盖缺口并能直接对照框架内的 rubric 指标T1–T5开展行为验收。一、背景CCGS 与技能测试框架Claude Code Game Studios 将 Claude Code 组织为一个完整的游戏开发工作室包含 49 个 AI Agent 与 72 个工作流技能并配套一套独立的质量保障层——CCGS Skill Testing Framework目录。该框架测试的是技能与 Agent 本身而不是用它们制作的游戏见 CCGS Skill Testing Framework/README.md。框架内每个技能对应一份行为测试规范behavioral spec/team-combat的规范文件位于 CCGS Skill Testing Framework/skills/team/team-combat.md并已在主登记表 CCGS Skill Testing Framework/catalog.yaml 中登记- name: team-combat spec: CCGS Skill Testing Framework/skills/team/team-combat.md last_static: last_static_result: last_spec: last_spec_result: last_category: last_category_result: priority: medium category: teampriority: medium、category: team表明它属于团队编排类技能测试时需对照 CCGS Skill Testing Framework/quality-rubric.md 中### team一节的度量指标。规范文件的结构约定按框架约定见 CCGS Skill Testing Framework/CLAUDE.md技能规范文件统一存放于skills/[category]/[name].md由catalog.yaml的spec:字段作为权威路径。每份规范应包含Skill Summary技能摘要→ Static Assertions静态断言→ Test Cases测试用例→ Protocol Compliance协议合规→ Coverage Notes覆盖说明。这与模板 CCGS Skill Testing Framework/templates/skill-test-spec.md 的骨架一致——模板定义了 5 个用例槽位Happy Path、Failure/Blocked、Mode Variant、Edge Case、Director Gate与 4 条协议合规项/team-combat规范在此骨架上针对团队流水线做了具体化改造。测试执行入口测试框架提供了两条驱动路径见 CCGS Skill Testing Framework/README.md/skill-test spec team-combat将技能与其书面规范逐条对照评估/skill-test category team-combat按team类别 rubric 指标评估。框架还特别声明CCGS Skill Testing Framework/CLAUDE.md规范描述的是当前行为而非理想行为可能编码了既有 bug当技能实际行为异常时应先修正技能、再同步更新规范。规范失败应视为「需要调查」而非「技能一定错误」。二、技能摘要一条命令驱动整个战斗团队规范的Skill Summary给出了/team-combat的能力边界与核心约束Orchestrates the full combat team pipeline end-to-end for a single combat feature.针对单个战斗功能端到端编排完整的战斗团队流水线。协调角色game-designer、gameplay-programmer、ai-programmer、technical-artist、sound-designer、primary engine specialist主引擎专精、qa-tester共七类角色六个结构化阶段Design设计→ Architecture架构含引擎专精校验→ Implementation并行实现→ Integration集成→ Validation验证→ Sign-off签收阶段门禁每个阶段转换处使用AskUserQuestion征求用户批准流水线不会自动前进写入委托所有文件写入全部委托给子 Agent编排者orchestrator自身不直接写文件输出产物生成一份汇总报告verdict 取值COMPLETE / NEEDS WORK / BLOCKED并在结尾给出交接建议/code-review、/balance-check、/team-polish。从仓库角色定义看gameplay-programmer的职责边界与流水线分工高度吻合——gameplay-programmer 测试规范 明确其领域为游戏机制代码、玩家系统、战斗实现与交互功能不拥有UI 实现ui-programmer、AI 行为树ai-programmer、引擎/渲染系统engine-programmer且被要求将 UI 反馈与 AI 反应正确分流。这与/team-combat在 Phase 3 将玩法、AI、VFX、音频四路并行解耦的设计完全一致。三、静态断言结构性合规检查清单规范在进入行为测试前先做 10 项静态断言Structural确保技能文件本身结构达标#断言内容1具备必需 frontmatter 字段name、description、argument-hint、user-invocable、allowed-tools2至少 2 个阶段标题Phase 1 至 Phase 6 全部存在3包含 verdict 关键词COMPLETE、NEEDS WORK、BLOCKED4包含 May I write 或 File Write Protocol —— 写入委托给子 Agent编排者不直接写文件5结尾有下一步交接引用/code-review、/balance-check、/team-polish6存在 Error Recovery Protocol错误恢复协议小节且含全部四个恢复步骤7阶段转换处使用AskUserQuestion请求用户批准8Phase 3 明确标注为并行gameplay-programmer、ai-programmer、technical-artist、sound-designer9Phase 2 包含派生主引擎专精从.claude/docs/technical-preferences.md读取10Team Composition 列出全部七个角色这些断言与模板 skill-test-spec.md 中的通用静态检查frontmatter、阶段标题、verdict 关键词、May I write、handoff 小节一脉相承但针对团队技能增加了引擎路由与并行阶段两项专属检查。静态断言未通过时行为测试不会启动行为测试则按下一节的五个用例逐一执行。四、测试用例详解Case 1Happy Path —— 全员成功完整流水线跑通Fixture前置状态design/gdd/game-concept.md存在且有内容引擎已在.claude/docs/technical-preferences.md配置Engine Specialists 小节已填写尚无针对所请求战斗功能的现有 GDD。输入/team-combat parry and riposte system招架与反击系统期望行为六阶段推进Phase 1—— 派生 game-designer产出design/gdd/parry-riposte.md必须覆盖 GDD 的8 个必备小节overview概览、player fantasy玩家愿景、rules规则、formulas公式、edge cases边界情况、dependencies依赖、tuning knobs调优旋钮、acceptance criteria验收标准随后请求用户批准设计文档Phase 2—— 派生 gameplay-programmer 与 ai-programmer产出架构草图类结构、接口、文件清单随后派生主引擎专精校验惯用法idioms并将其输出并入架构在 Phase 3 开始前以AskUserQuestion呈现架构选项Phase 3—— 并行派生 gameplay-programmer、ai-programmer、technical-artist、sound-designer四者全部返回后才进入 Phase 4Phase 4—— 集成环节把 Phase 3 的全部产出接线调优旋钮被验证为数据驱动data-drivenAskUserQuestion确认集成结果后进入 Phase 5Phase 5—— 派生 qa-tester依据验收标准编写测试用例验证边界情况并按预算检查性能影响Phase 6—— 生成汇总报告设计 COMPLETE、所有团队成员 COMPLETE、列出测试用例、整体 verdict 为 COMPLETE下一步建议/code-review、/balance-check、/team-polish。断言要点每个阶段门禁处调用AskUserQuestion至少 Phase 3 前与 Phase 5 前Phase 3 四个 Agent同时启动无顺序依赖引擎专精在 Phase 2 运行其输出并入架构所有文件写入委托给子 Agent编排者绝不直接调用 Write/Edit最终报告含 COMPLETE verdict设计文档覆盖全部 8 个 GDD 小节。源码印证rubric 的 T4 指标「Dependent phases wait for all parallel agents to complete before proceeding」见 quality-rubric.md正是对「四路并行、全部收齐再前进」的度量定义。Case 2Blocked Agent —— 子 Agent 中途返回 BLOCKEDFixturedesign/gdd/parry-riposte.md已存在Phase 1 已完成ai-programmer 返回 BLOCKED理由是「AI 行为系统尚无已接受的架构 ADR当前状态为 Proposed」。输入/team-combat parry and riposte system期望行为Phase 1 —— 发现设计文档已存在game-designer 确认有效阶段通过Phase 2 —— gameplay-programmer 完成架构草图ai-programmer 返回 BLOCKED理由是「AI 行为系统的 ADR 处于 Proposed 状态在 ADR 被 Accepted 之前无法实现」触发Error Recovery Protocolai-programmer: BLOCKED — AI behavior ADR is ProposedAskUserQuestion给出三选一(a) 跳过 ai-programmer 并记录缺口(b) 缩小范围重试(c) 停下并先运行/architecture-decision若用户选择 (a)Phase 3 仅以 gameplay-programmer、technical-artist、sound-designer 三路继续ai-programmer 缺口记入部分报告最终报告完整记录部分实现ai-programmer 小节标记 BLOCKED整体 verdict 为BLOCKED。断言要点BLOCKED 表面消息在任何依赖阶段继续之前出现AskUserQuestion至少提供三个选项skip / retry / stop产生部分报告——已完成 Agent 的工作不被丢弃只要存在未解决的 Agent整体 verdict 为 BLOCKED 而非 COMPLETE阻塞原因引用 ADR 并建议/architecture-decision编排者绝不静默绕过被阻塞的依赖。源码印证rubric 的 T3 指标「If any spawned agent returns BLOCKED or fails, skill surfaces it immediately and halts dependent work — never silently skips」quality-rubric.md正是本用例的度量底座而「先跑/architecture-decision」的建议可对接 architecture-decision 技能规范authoring 类别。Case 3No Argument —— 无参调用给出清晰用法提示Fixture任意项目状态。输入/team-combat无参数期望行为技能检测到未提供参数输出用法消息说明必需参数战斗功能描述给出示例调用/team-combat [combat feature description]技能退出不派生任何子 Agent。断言要点无参数时不派生任何子 Agent用法消息包含 frontmatter 中argument-hint的格式错误消息至少包含一个合法调用示例除检测缺参所需外不做多余文件读取不显示 verdict流水线从未运行。源码印证rubric 的 T5 指标「If required argument (e.g., feature name) is missing, skill outputs usage hint and stops without spawning agents」与 Case 3 完全对应属于team类别的通过标准之一。Case 4Parallel Phase Validation —— Phase 3 四路同时运行Fixturedesign/gdd/parry-riposte.md存在且完整架构草图已获批准引擎专精已完成架构校验。输入/team-combat parry and riposte system从 Phase 2 完成处续跑期望行为架构批准后 Phase 3 开始四个 Task 调用gameplay-programmer、ai-programmer、technical-artist、sound-designer在任何结果被等待之前全部发出技能等待四者全部完成才进入 Phase 4即使某个 Agent 提前完成Phase 4 也不会提前开始。断言要点四个 Task 调用在同一批次发出四者之间无顺序等待四个 Phase 3 Agent 全部返回前Phase 4 不开始不把某个 Phase 3 Agent 的输出作为另一个 Phase 3 Agent 的输入彼此独立四个 Phase 3 Agent 的结果都出现在 Phase 4 集成步骤的引用中。源码印证rubric 的 T2 指标「Agents whose inputs dont depend on each other are spawned in parallel (single message, multiple Task calls)」quality-rubric.md精确描述了「单条消息、多个 Task 调用」的并行执行形态。Case 5Architecture Phase Engine Routing —— 引擎专精收到正确上下文Fixture.claude/docs/technical-preferences.md的 Engine Specialists 小节已填写例如 Primary: godot-specialistgameplay-programmer 产出的架构草图可用引擎版本固定在docs/engine-reference/godot/VERSION.md。输入/team-combat parry and riposte system期望行为Phase 2 —— gameplay-programmer 产出架构草图技能读取.claude/docs/technical-preferences.md的 Engine Specialists 小节识别主引擎专精的 Agent 类型引擎专精被派生携带架构草图、GDD 路径、来自VERSION.md的引擎版本以及显式指令——检查废弃 API引擎专精输出惯用法说明、废弃 API 警告、原生系统建议返回编排者编排者在向用户呈现 Phase 2 结果前把引擎说明并入架构AskUserQuestion将引擎专精说明与架构草图一并呈现。断言要点引擎专精 Agent 类型从.claude/docs/technical-preferences.md读取而非硬编码引擎专精提示词包含架构草图与 GDD 路径引擎专精对照固定的引擎版本检查废弃 API引擎专精输出在 Phase 3 开始前并入不跳过、不单独追加若未配置引擎则跳过引擎专精步骤并在报告中添加说明。源码印证引擎专精对VERSION.md的依赖在框架中处处可见——例如 godot-specialist 测试规范 要求「将docs/engine-reference/godot/VERSION.md视为高于 LLM 训练数据的权威来源」并「读取 4.6 上下文并应用 Jolt 默认知识来自 VERSION.md 迁移说明」godot-shader-specialist 测试规范 亦引用「Godot 4.6 包含 glow 重构」的 VERSION.md 注释。这印证了「版本固定 → 引擎专精按版本校验 API 合法性」是框架级约定而非/team-combat独有设计。五、协议合规清单无论用例通过与否技能运行还需满足以下协议级要求每个阶段转换处使用AskUserQuestion——用户批准后流水线才前进所有文件写入通过 Task 委托给子 Agent——编排者不直接调用 Write 或 Edit遵循 Error Recovery Protocolsurface表面化→ assess评估→ offer options提供选项→ partial report部分报告Phase 3 按技能规范并行启动即使 Agent 被 BLOCKED也始终产生部分报告verdict 取值为COMPLETE / NEEDS WORK / BLOCKED三者之一输出结尾必须有下一步建议/code-review、/balance-check、/team-polish。这与 rubric 的 T1明确列出派生的 Agent 与顺序、T3阻塞即表面化、T4收齐全部 verdict 再前进三项指标互为表里构成team类别技能的验收标准见 quality-rubric.md。六、覆盖说明已知测试缺口规范的 Coverage Notes 诚实标注了当前覆盖范围的边界NEEDS WORK 路径未单独测试qa-tester 在 Phase 5 发现失败从而走 NEEDS WORK verdict 的场景未在此规范中独立成用例它遵循与 Case 2 相同的错误恢复与部分报告协议「缩小范围重试」的递归行为未覆盖该选项被列出为断言但其完整递归行为通过/create-stories拆分由 create-stories 规范 覆盖Phase 4 集成逻辑仅隐式验证接线玩法、AI、VFX、音频的集成步骤由 Happy Path 用例间接验证专门的集成测试需要 fixture 代码文件支撑引擎专精不可用状态仅部分覆盖Case 5 的断言部分覆盖「未配置引擎」场景但缺乏专门的未配置引擎 fixture若需强化覆盖可补充该 fixture。理解这些缺口对测试者尤为重要由于规范描述的是「当前行为」缺口既可能是待补测试也可能恰好暴露了技能的薄弱环节——这正是 CCGS Skill Testing Framework/CLAUDE.md 反复强调「规范失败需要调查」的原因。七、实践指南如何在本仓库验证 /team-combat结合框架约定CCGS Skill Testing Framework/CLAUDE.md 的测试工作流验证该技能的标准流程为读取 catalog.yaml 获取team-combat的spec:路径与category: team读取技能本体位于项目.claude/skills/team-combat/SKILL.md即游戏项目侧的技能定义对照本规范 team-combat.md 逐条评估断言执行/skill-test spec team-combat与/skill-test category team-combat测试结果可写入results/并回写catalog.yaml的last_spec、last_spec_result字段。测试所需的仓库证据均可就地取材角色边界看 gameplay-programmer 规范 与agents/下各 tier 目录引擎版本权威性看 docs/engine-reference/godot/VERSION.md类别度量看 quality-rubric.md 的### team一节规范骨架对照 templates/skill-test-spec.md。八、结语/team-combat技能测试规范是 CCGS「团队编排类」技能的样板之一它把一次战斗功能的完整交付拆解为六个阶段、七类角色、五类可重复验证的行为场景并把「阶段门禁AskUserQuestion、写入委托、并行无依赖、阻塞即表面化、部分报告兜底、verdict 三态、handoff 闭环」沉淀为可断言的协议。这份规范的价值不止于测试——它本身就是编排复杂多 Agent 流水线的设计蓝图任何想要构建「一个命令驱动整个跨职能团队」工作流的开发者都可以从本规范及其配套 rubricT1–T5中获得可直接迁移的模式。【免费下载链接】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），仅供参考