Claude Code Game Studios 中的 dev-story 技能从故事到代码的完整实现流水线【免费下载链接】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导读/dev-story是 Claude Code Game StudiosCCGS这套AI 游戏开发工作室体系中衔接规划与编码的核心技能。它以 Story用户故事文件为输入自动加载 GDD 需求TR Registry、架构决策记录ADR、分层控制清单Control Manifest与引擎技术偏好路由到正确的程序员 Agent 与引擎专家驱动实现与测试同步完成。读完本文你将掌握如何用一条/dev-story [story-path]命令把一个通过story-readiness校验的故事变成src/中可运行的源码与tests/中的配套测试并理解其背后的七阶段编排协议与错误恢复机制。一、dev-story 在 CCGS 工作流中的定位CCGSClaude Code Game Studios将游戏研发流程拆解为 49 个 AI Agent 与 72 个工作流技能dev-story是其中被明确定位为核心实现技能的环节。其技能声明.claude/skills/dev-story/SKILL.md中写明Read a story file and implement it. Loads the full context (story, GDD requirement, ADR guidelines, control manifest), routes to the right programmer agent for the system and engine, implements the code and test, and confirms each acceptance criterion.它在整个工作流中处于承上启下的位置官方给出的每个 Story 的标准循环为/qa-plan sprint ← 在 sprint 开始前定义测试需求 /story-readiness [path] ← 在开始前校验故事就绪状态 /dev-story [path] ← 实现它本技能 /code-review [files] ← 评审实现 /story-done [path] ← 验证并关闭故事当 sprint 内所有故事完成后还需运行/team-qa sprint执行完整 QA 循环并获得签署结论之后才能推进项目阶段phase gate。也就是说dev-story的上游是 story-readiness确保故事可开工下游是 story-done验收并闭环。dev-story的输出被严格定义为项目src/目录下的源码文件 tests/目录下的测试文件。从仓库结构可以印证CCGS 的 Agent 定义文件.claude/agents/ 与 CCGS Skill Testing Framework/agents/按层级划分了 directors、leads、specialists、operations、qa 等角色而 .claude/docs/agent-roster.md 则给出了完整的角色名册与模型分层Opus/Sonnet/Haikudev-story正是通过这张名册把任务路由给正确的程序员。二、Phase 1-2定位故事并加载完整上下文2.1 找到要实现的 Story/dev-story的参数是一个可选的[story-path]提供了路径直接读取该故事文件。未提供参数先检查production/session-state/active.md中的当前活动故事若找到则向用户确认是否继续该故事若没有则询问用户并通过 Glob 搜索production/epics/**/*.md列出所有Status: Ready的故事供选择。2.2 前置文件存在性校验硬门禁在加载任何上下文之前dev-story首先根据故事中的ADR Governing Implementation字段提取 ADR 路径并校验三类关键文件是否存在文件路径缺失时的处理TR 注册表docs/architecture/tr-registry.yamlSTOP—— TR registry not found. Run/create-epicsto generate it.治理 ADR故事 ADR 字段指向的路径STOP—— ADR file [path] not found. Run/architecture-decisionto create it, or correct the filename in the storys ADR field.控制清单docs/architecture/control-manifest.mdWARN 并继续—— Control manifest not found — layer rules cannot be checked. Run/create-control-manifest.若 TR 注册表或治理 ADR 缺失故事状态被置为BLOCKED并写入会话状态且不派生任何程序员 Agent。这条规则保证了没有设计依据就不写代码。仓库中实际的 docs/architecture/tr-registry.yaml 正是这一机制的落地文件它维护着每个 GDD 技术需求的稳定 ID格式TR-[system-slug]-[NNN]并明确声明ID 永久有效、绝不重编号、删除只能标记 deprecated、需求改写只更新requirement文本并追加revised日期。这也解释了为什么dev-story要求以注册表中的当前requirement文本为唯一事实来源——故事文件内联引用的需求文本可能已过期stale。2.3 并行读取四类上下文通过校验后dev-story会同时independent reads读取以下上下文且明确要求所有上下文加载完成前不得开始实现故事文件提取故事标题、ID、层级layer、类型Logic / Integration / Visual/Feel / UI / Config/Data、TR-ID、治理 ADR 引用、故事头部的 Manifest Version、逐条验收标准acceptance criteria、实现备注ADR guidance 段落、Out of Scope 边界、Test Evidence要求的测试文件路径、Dependencies依赖列表。TR 注册表读取docs/architecture/tr-registry.yaml按 TR-ID 查找当前需求文本。治理 ADR读取docs/architecture/[adr-file].md提取完整 Decision 部分、Implementation Guidelines程序员遵循的指南、Engine Compatibilitycutoff 后的 API 与已知风险、ADR Dependencies。控制清单读取docs/architecture/control-manifest.md提取该故事所属 layer 的 Required patterns、Forbidden patterns、性能护栏performance guardrails。2.4 Manifest 版本一致性检查dev-story会比对故事内嵌的Manifest Version与当前控制清单头部的版本日期一致直接继续。不一致通过AskUserQuestion让用户三选一——[A]更新故事中的 Manifest Version 并按当前规则实现推荐[B]按旧规则实现用户自担不合规风险[C]停止先人工审查 manifest 差异。选[A]时需在派生程序员之前先编辑故事文件的Manifest Version:字段选[B]时仍要求细读新规则并在 Phase 6 总结的 Deviations 中记录版本不匹配选[C]则彻底停止、不派生任何 Agent。2.5 依赖校验Dependency Validation从故事提取 Dependencies 列表后逐项验证Glob 搜索production/epics/**/*.md定位每个依赖故事文件读取其Status:字段若任一依赖状态不是Complete或Done通过AskUserQuestion询问——[A]仍然继续接受依赖风险[B]停止先完成依赖[C]依赖实际已完成但状态未更新——将其标记为 Complete 并继续需先征求同意。选[B]时该故事被置为BLOCKED且不派生 Agent选[A]则必须在 Phase 6 总结的 Deviations 下注明在有未完成依赖的情况下实现。依赖文件找不到时给出警告 Dependency story not found: [path]并提示核对路径或创建故事文件。2.6 引擎技术偏好最后读取 .claude/docs/technical-preferences.md获取Engine:值——决定派生哪些程序员 Agent命名约定类名、文件名、信号/事件名性能预算帧预算、内存上限Forbidden patterns。该文件由/setup-engine填充当前仓库中仍是[TO BE CONFIGURED]占位状态是后续路由与编码规范的依据。三、Phase 3路由到正确的程序员 Agentdev-story根据故事的Layer、Type 与系统名决定通过Task派生哪个专家。3.1 特殊分支Config/Data 故事跳过 Agent 派生若故事类型为Config/Data完全不需要派生程序员 Agent 或引擎专家直接跳到 Phase 4 的 Config/Data 处理分支——实现本质是一次数据文件编辑无需路由表评估。3.2 主程序员路由表故事上下文主 AgentFoundation 层——任意类型engine-programmer任意层——Type: UIui-programmer任意层——Type: Visual/Feelgameplay-programmer负责实现Core 或 Feature——玩法机制gameplay-programmerCore 或 Feature——AI 行为、寻路ai-programmerCore 或 Feature——网络、复制network-programmerConfig/Data——无代码不需要 Agent见 Phase 4 说明这些角色在 .claude/docs/agent-roster.md 中有明确定义例如engine-programmer引擎系统、渲染、物理、内存管理、gameplay-programmer玩法代码、ai-programmerAI 系统、network-programmer网络代码均为 Sonnet 层级的 Specialist。而 CCGS Skill Testing Framework/agents/specialists/engine-programmer.md 进一步展示了这些 Agent 的能力边界测试例如对象池实现含单元测试、越域请求重定向到ui-programmer、内存泄漏诊断流程、跨域协作时与lead-programmer协调 API 变更、以及在给出 Godot 4.6 引擎版本参考时以VERSION.md为准Jolt 成为默认物理引擎而非依赖训练数据。3.3 引擎专家代码类故事的次级 Agent对于代码类故事需从 .claude/docs/technical-preferences.md 的Engine Specialists段落读取配置的主专家并在故事涉及引擎特定 API、模式或 ADR 标注 HIGH 引擎风险时将其与主 Agent 一起派生引擎可用专家 AgentGodot 4godot-specialist、godot-gdscript-specialist、godot-shader-specialistUnityunity-specialist、unity-ui-specialist、unity-shader-specialistUnreal Engineunreal-specialist、ue-gas-specialist、ue-blueprint-specialist、ue-umg-specialist、ue-replication-specialist当引擎风险为 HIGH 时来自 ADR 或 VERSION.md即使是非引擎面向的故事也必须派生引擎专家——因为 HIGH 风险意味着 ADR 记录了对 cutoff 之后引擎 API 的假设需要专家验证。仓库中的引擎文档体系docs/engine-reference/按 Godot / Unity / Unreal 分别维护了 modules、plugins、VERSION.md、breaking-changes.md 等参考正是这些专家 Agent 的校验依据。四、Phase 4-5实现与测试编写4.1 向程序员 Agent 传递完整上下文包通过Task派生程序员 Agent 时必须提供 8 项内容完整的故事文件内容TR 注册表中的当前 GDD 需求文本ADR 的 Decision Implementation Guidelines逐字传递不得摘要该 layer 的控制清单规则引擎命名约定与性能预算ADR Engine Compatibility 段落中的引擎特定注意事项必须创建的测试文件路径显式指令实现这个故事并编写测试。Agent 的行为约束包括按 ADR 指南在src/中创建/修改文件、遵守控制清单的 Required/Forbidden patterns、不得越过故事的 Out of Scope 边界触碰无关文件、为公开 API 编写带文档注释的干净代码。4.2 三种特殊故事类型Config/Data 故事无需 Agent直接编辑数据文件并记录每个值从什么改为什么from/to。Visual/Feel 故事派生gameplay-programmer实现代码/动画调用但注意其验收标准无法自动验证——手感是否到位does it feel right?在/story-done阶段通过人工确认完成。Logic 与 Integration 故事测试必须随实现一同编写绝不允许推迟。技能要求以如下提醒告知程序员 AgentThe test file for this story is required at:[path from Test Evidence section]. The story cannot be closed via/story-donewithout it. Write the test alongside the implementation, not after.4.3 测试编写标准依据 .claude/docs/coding-standards.md 的 Testing Standards 章节测试要求如下文件命名[system]_[feature]_test.[ext]函数命名test_[scenario]_[expected_outcome]每个验收标准至少有一个测试函数覆盖禁止随机种子、禁止时间相关断言、禁止外部 I/O必须测试 GDD Formulas 章节的公式边界值。同时该文档明确了按故事类型的测试证据要求Logic 故事需要tests/unit/[system]/下的自动化单元测试BLOCKING 门禁、Integration 需要集成测试或文档化 playtestBLOCKING、Visual/Feel 需要截图 负责人签署ADVISORY、UI 需要人工走查文档或交互测试ADVISORY、Config/Data 需要 smoke check 通过报告ADVISORY。在 CI/CD 层面还给出了各引擎的测试命令示例Godot 用godot --headless --script tests/gdunit4_runner.gdUnity 用game-ci/unity-test-runnerv4Unreal 用带-nullrhi标志的无头 runner。对于Visual/Feel 与 UI故事不写自动化测试提醒 Agent 在实现总结中注明需要的人工证据Evidence doc required atproduction/qa/evidence/[slug]-evidence.md.对于Config/Data故事不写测试文件以 smoke check 作为证据。五、Phase 6-7结果收集、总结与会话状态更新5.1 收集项程序员 Agent 完成后收集创建/修改的文件带路径、测试文件路径与测试函数数量、对 Out of Scope 边界的任何偏离需标记、Agent 提出的问题或阻塞项、专家标记的引擎特定风险。5.2 实现总结模板技能给出了标准的总结输出模板要点如下## Implementation Complete: [Story Title] **Files changed**: - src/[path] — created / modified ([brief description]) - tests/[path] — test file ([N] test functions) **Acceptance criteria covered**: - [x] [criterion] — implemented in [file:function] - [x] [criterion] — covered by test [test_name] - [ ] [criterion] — DEFERRED: requires playtest (Visual/Feel) **Deviations from scope**: [None] or [list files touched outside story boundary] **Engine risks flagged**: [None] or [specialist finding] **Blockers**: [None] or [describe] Ready for: /code-review [file1] [file2] then /story-done [story-path]5.3 会话状态更新静默向production/session-state/active.md追加会话摘录记录故事路径与标题、变更文件、测试路径或 None — Visual/Feel/Config story、阻塞项、下一步动作文件不存在则创建。随后向用户确认 Session state updated.。六、错误恢复协议Error Recovery Protocol任何通过 Task 派生的 Agent 若返回 BLOCKED、报错或无法完成按以下流程处理立即上报在进入依赖阶段前向用户报告 [AgentName]: BLOCKED — [reason]评估依赖判断被阻塞 Agent 的输出是否为后续阶段所需若是则在得到用户输入前不得越过该依赖点提供选项AskUserQuestion跳过该 Agent 并在最终报告中注明缺口 / 以更小范围重试 / 停止并先解决阻塞始终产出部分报告保留已完成的工作绝不因单个 Agent 阻塞而丢弃。常见的阻塞场景及处理输入文件缺失故事找不到、GDD 缺失→ 转给创建它的技能ADR 状态为 Proposed → 不实现先运行/architecture-decision范围过大 → 通过/create-stories拆分为两个故事ADR 与故事指令冲突 → 上报冲突不得擅自猜测Manifest 版本不匹配 → 向用户展示 diff询问按旧规则继续还是先更新故事。七、协作协议编排器不直接写文件dev-story作为编排器遵循严格的协作协议文件写入全部委托所有源码、测试文件、证据文档都由通过 Task 派生的子 Agent 写入每个子 Agent 单独执行 May I write to [path]? 协议编排器自身不直接写文件先加载后实现上下文story、TR-ID、ADR、manifest、引擎偏好未加载完不得开始编码否则代码会偏离设计ADR 即法律实现必须遵循 ADR 的 Implementation Guidelines若指南与看起来更好的做法冲突应在总结中标记而非默默偏离严守范围Out of Scope 段落是契约若实现某验收标准必须触碰越界文件停下来上报Implementing [criterion] requires modifying [file], which is out of scope. Shall I proceed or create a separate story?Logic/Integration 的测试不可缺席测试文件不存在就不能标记实现完成Visual/Feel 标准是延迟而非跳过在总结中标记为 DEFERRED由/story-done人工验证重大结构性决策前先询问若故事需要 ADR 未覆盖的架构模式先上报The ADR doesnt specify how to handle [case]. My plan is [X]. Proceed?这套编排器收集上下文 → 派生专职 Agent 实现 → 汇总报告 → 更新会话状态的模式与仓库中 .claude/docs/coordination-rules.md 定义的纵向委派领导 Agent → 部门主管 → 专家、并行 Task 协议独立输入同时派生、BLOCKED 立即上报、部分报告机制完全一致是 CCGS 多 Agent 编排哲学在实现环节的集中体现。八、从 dev-story 出发的完整闭环实现完成后dev-story的 Recommended Next Steps 指向运行/code-review [file1] [file2]在关闭故事前评审实现运行/story-done [story-path]验证每条验收标准并标记故事完成——该技能会读取 TR 注册表中的当前需求文本、比对 Manifest 版本、检查测试证据门禁Logic/Integration 缺测试为 BLOCKING、生成验收标准 ↔ 测试追溯表并最终更新故事状态与会话状态sprint 内所有故事完成后运行/team-qa sprint执行完整 QA 循环再推进项目阶段。至此一条从/qa-plan sprint到/story-done的研发闭环完整成形dev-story扮演着把设计承诺兑现为可运行代码与可验证测试的关键枢纽其七阶段流程、硬门禁校验、按类型差异化路由与测试策略构成了 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），仅供参考 Claude Code Game Studios 中的 dev-story 技能：从故事到代码的完整实现流水线
Claude Code Game Studios 中的 dev-story 技能从故事到代码的完整实现流水线【免费下载链接】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导读/dev-story是 Claude Code Game StudiosCCGS这套AI 游戏开发工作室体系中衔接规划与编码的核心技能。它以 Story用户故事文件为输入自动加载 GDD 需求TR Registry、架构决策记录ADR、分层控制清单Control Manifest与引擎技术偏好路由到正确的程序员 Agent 与引擎专家驱动实现与测试同步完成。读完本文你将掌握如何用一条/dev-story [story-path]命令把一个通过story-readiness校验的故事变成src/中可运行的源码与tests/中的配套测试并理解其背后的七阶段编排协议与错误恢复机制。一、dev-story 在 CCGS 工作流中的定位CCGSClaude Code Game Studios将游戏研发流程拆解为 49 个 AI Agent 与 72 个工作流技能dev-story是其中被明确定位为核心实现技能的环节。其技能声明.claude/skills/dev-story/SKILL.md中写明Read a story file and implement it. Loads the full context (story, GDD requirement, ADR guidelines, control manifest), routes to the right programmer agent for the system and engine, implements the code and test, and confirms each acceptance criterion.它在整个工作流中处于承上启下的位置官方给出的每个 Story 的标准循环为/qa-plan sprint ← 在 sprint 开始前定义测试需求 /story-readiness [path] ← 在开始前校验故事就绪状态 /dev-story [path] ← 实现它本技能 /code-review [files] ← 评审实现 /story-done [path] ← 验证并关闭故事当 sprint 内所有故事完成后还需运行/team-qa sprint执行完整 QA 循环并获得签署结论之后才能推进项目阶段phase gate。也就是说dev-story的上游是 story-readiness确保故事可开工下游是 story-done验收并闭环。dev-story的输出被严格定义为项目src/目录下的源码文件 tests/目录下的测试文件。从仓库结构可以印证CCGS 的 Agent 定义文件.claude/agents/ 与 CCGS Skill Testing Framework/agents/按层级划分了 directors、leads、specialists、operations、qa 等角色而 .claude/docs/agent-roster.md 则给出了完整的角色名册与模型分层Opus/Sonnet/Haikudev-story正是通过这张名册把任务路由给正确的程序员。二、Phase 1-2定位故事并加载完整上下文2.1 找到要实现的 Story/dev-story的参数是一个可选的[story-path]提供了路径直接读取该故事文件。未提供参数先检查production/session-state/active.md中的当前活动故事若找到则向用户确认是否继续该故事若没有则询问用户并通过 Glob 搜索production/epics/**/*.md列出所有Status: Ready的故事供选择。2.2 前置文件存在性校验硬门禁在加载任何上下文之前dev-story首先根据故事中的ADR Governing Implementation字段提取 ADR 路径并校验三类关键文件是否存在文件路径缺失时的处理TR 注册表docs/architecture/tr-registry.yamlSTOP—— TR registry not found. Run/create-epicsto generate it.治理 ADR故事 ADR 字段指向的路径STOP—— ADR file [path] not found. Run/architecture-decisionto create it, or correct the filename in the storys ADR field.控制清单docs/architecture/control-manifest.mdWARN 并继续—— Control manifest not found — layer rules cannot be checked. Run/create-control-manifest.若 TR 注册表或治理 ADR 缺失故事状态被置为BLOCKED并写入会话状态且不派生任何程序员 Agent。这条规则保证了没有设计依据就不写代码。仓库中实际的 docs/architecture/tr-registry.yaml 正是这一机制的落地文件它维护着每个 GDD 技术需求的稳定 ID格式TR-[system-slug]-[NNN]并明确声明ID 永久有效、绝不重编号、删除只能标记 deprecated、需求改写只更新requirement文本并追加revised日期。这也解释了为什么dev-story要求以注册表中的当前requirement文本为唯一事实来源——故事文件内联引用的需求文本可能已过期stale。2.3 并行读取四类上下文通过校验后dev-story会同时independent reads读取以下上下文且明确要求所有上下文加载完成前不得开始实现故事文件提取故事标题、ID、层级layer、类型Logic / Integration / Visual/Feel / UI / Config/Data、TR-ID、治理 ADR 引用、故事头部的 Manifest Version、逐条验收标准acceptance criteria、实现备注ADR guidance 段落、Out of Scope 边界、Test Evidence要求的测试文件路径、Dependencies依赖列表。TR 注册表读取docs/architecture/tr-registry.yaml按 TR-ID 查找当前需求文本。治理 ADR读取docs/architecture/[adr-file].md提取完整 Decision 部分、Implementation Guidelines程序员遵循的指南、Engine Compatibilitycutoff 后的 API 与已知风险、ADR Dependencies。控制清单读取docs/architecture/control-manifest.md提取该故事所属 layer 的 Required patterns、Forbidden patterns、性能护栏performance guardrails。2.4 Manifest 版本一致性检查dev-story会比对故事内嵌的Manifest Version与当前控制清单头部的版本日期一致直接继续。不一致通过AskUserQuestion让用户三选一——[A]更新故事中的 Manifest Version 并按当前规则实现推荐[B]按旧规则实现用户自担不合规风险[C]停止先人工审查 manifest 差异。选[A]时需在派生程序员之前先编辑故事文件的Manifest Version:字段选[B]时仍要求细读新规则并在 Phase 6 总结的 Deviations 中记录版本不匹配选[C]则彻底停止、不派生任何 Agent。2.5 依赖校验Dependency Validation从故事提取 Dependencies 列表后逐项验证Glob 搜索production/epics/**/*.md定位每个依赖故事文件读取其Status:字段若任一依赖状态不是Complete或Done通过AskUserQuestion询问——[A]仍然继续接受依赖风险[B]停止先完成依赖[C]依赖实际已完成但状态未更新——将其标记为 Complete 并继续需先征求同意。选[B]时该故事被置为BLOCKED且不派生 Agent选[A]则必须在 Phase 6 总结的 Deviations 下注明在有未完成依赖的情况下实现。依赖文件找不到时给出警告 Dependency story not found: [path]并提示核对路径或创建故事文件。2.6 引擎技术偏好最后读取 .claude/docs/technical-preferences.md获取Engine:值——决定派生哪些程序员 Agent命名约定类名、文件名、信号/事件名性能预算帧预算、内存上限Forbidden patterns。该文件由/setup-engine填充当前仓库中仍是[TO BE CONFIGURED]占位状态是后续路由与编码规范的依据。三、Phase 3路由到正确的程序员 Agentdev-story根据故事的Layer、Type 与系统名决定通过Task派生哪个专家。3.1 特殊分支Config/Data 故事跳过 Agent 派生若故事类型为Config/Data完全不需要派生程序员 Agent 或引擎专家直接跳到 Phase 4 的 Config/Data 处理分支——实现本质是一次数据文件编辑无需路由表评估。3.2 主程序员路由表故事上下文主 AgentFoundation 层——任意类型engine-programmer任意层——Type: UIui-programmer任意层——Type: Visual/Feelgameplay-programmer负责实现Core 或 Feature——玩法机制gameplay-programmerCore 或 Feature——AI 行为、寻路ai-programmerCore 或 Feature——网络、复制network-programmerConfig/Data——无代码不需要 Agent见 Phase 4 说明这些角色在 .claude/docs/agent-roster.md 中有明确定义例如engine-programmer引擎系统、渲染、物理、内存管理、gameplay-programmer玩法代码、ai-programmerAI 系统、network-programmer网络代码均为 Sonnet 层级的 Specialist。而 CCGS Skill Testing Framework/agents/specialists/engine-programmer.md 进一步展示了这些 Agent 的能力边界测试例如对象池实现含单元测试、越域请求重定向到ui-programmer、内存泄漏诊断流程、跨域协作时与lead-programmer协调 API 变更、以及在给出 Godot 4.6 引擎版本参考时以VERSION.md为准Jolt 成为默认物理引擎而非依赖训练数据。3.3 引擎专家代码类故事的次级 Agent对于代码类故事需从 .claude/docs/technical-preferences.md 的Engine Specialists段落读取配置的主专家并在故事涉及引擎特定 API、模式或 ADR 标注 HIGH 引擎风险时将其与主 Agent 一起派生引擎可用专家 AgentGodot 4godot-specialist、godot-gdscript-specialist、godot-shader-specialistUnityunity-specialist、unity-ui-specialist、unity-shader-specialistUnreal Engineunreal-specialist、ue-gas-specialist、ue-blueprint-specialist、ue-umg-specialist、ue-replication-specialist当引擎风险为 HIGH 时来自 ADR 或 VERSION.md即使是非引擎面向的故事也必须派生引擎专家——因为 HIGH 风险意味着 ADR 记录了对 cutoff 之后引擎 API 的假设需要专家验证。仓库中的引擎文档体系docs/engine-reference/按 Godot / Unity / Unreal 分别维护了 modules、plugins、VERSION.md、breaking-changes.md 等参考正是这些专家 Agent 的校验依据。四、Phase 4-5实现与测试编写4.1 向程序员 Agent 传递完整上下文包通过Task派生程序员 Agent 时必须提供 8 项内容完整的故事文件内容TR 注册表中的当前 GDD 需求文本ADR 的 Decision Implementation Guidelines逐字传递不得摘要该 layer 的控制清单规则引擎命名约定与性能预算ADR Engine Compatibility 段落中的引擎特定注意事项必须创建的测试文件路径显式指令实现这个故事并编写测试。Agent 的行为约束包括按 ADR 指南在src/中创建/修改文件、遵守控制清单的 Required/Forbidden patterns、不得越过故事的 Out of Scope 边界触碰无关文件、为公开 API 编写带文档注释的干净代码。4.2 三种特殊故事类型Config/Data 故事无需 Agent直接编辑数据文件并记录每个值从什么改为什么from/to。Visual/Feel 故事派生gameplay-programmer实现代码/动画调用但注意其验收标准无法自动验证——手感是否到位does it feel right?在/story-done阶段通过人工确认完成。Logic 与 Integration 故事测试必须随实现一同编写绝不允许推迟。技能要求以如下提醒告知程序员 AgentThe test file for this story is required at:[path from Test Evidence section]. The story cannot be closed via/story-donewithout it. Write the test alongside the implementation, not after.4.3 测试编写标准依据 .claude/docs/coding-standards.md 的 Testing Standards 章节测试要求如下文件命名[system]_[feature]_test.[ext]函数命名test_[scenario]_[expected_outcome]每个验收标准至少有一个测试函数覆盖禁止随机种子、禁止时间相关断言、禁止外部 I/O必须测试 GDD Formulas 章节的公式边界值。同时该文档明确了按故事类型的测试证据要求Logic 故事需要tests/unit/[system]/下的自动化单元测试BLOCKING 门禁、Integration 需要集成测试或文档化 playtestBLOCKING、Visual/Feel 需要截图 负责人签署ADVISORY、UI 需要人工走查文档或交互测试ADVISORY、Config/Data 需要 smoke check 通过报告ADVISORY。在 CI/CD 层面还给出了各引擎的测试命令示例Godot 用godot --headless --script tests/gdunit4_runner.gdUnity 用game-ci/unity-test-runnerv4Unreal 用带-nullrhi标志的无头 runner。对于Visual/Feel 与 UI故事不写自动化测试提醒 Agent 在实现总结中注明需要的人工证据Evidence doc required atproduction/qa/evidence/[slug]-evidence.md.对于Config/Data故事不写测试文件以 smoke check 作为证据。五、Phase 6-7结果收集、总结与会话状态更新5.1 收集项程序员 Agent 完成后收集创建/修改的文件带路径、测试文件路径与测试函数数量、对 Out of Scope 边界的任何偏离需标记、Agent 提出的问题或阻塞项、专家标记的引擎特定风险。5.2 实现总结模板技能给出了标准的总结输出模板要点如下## Implementation Complete: [Story Title] **Files changed**: - src/[path] — created / modified ([brief description]) - tests/[path] — test file ([N] test functions) **Acceptance criteria covered**: - [x] [criterion] — implemented in [file:function] - [x] [criterion] — covered by test [test_name] - [ ] [criterion] — DEFERRED: requires playtest (Visual/Feel) **Deviations from scope**: [None] or [list files touched outside story boundary] **Engine risks flagged**: [None] or [specialist finding] **Blockers**: [None] or [describe] Ready for: /code-review [file1] [file2] then /story-done [story-path]5.3 会话状态更新静默向production/session-state/active.md追加会话摘录记录故事路径与标题、变更文件、测试路径或 None — Visual/Feel/Config story、阻塞项、下一步动作文件不存在则创建。随后向用户确认 Session state updated.。六、错误恢复协议Error Recovery Protocol任何通过 Task 派生的 Agent 若返回 BLOCKED、报错或无法完成按以下流程处理立即上报在进入依赖阶段前向用户报告 [AgentName]: BLOCKED — [reason]评估依赖判断被阻塞 Agent 的输出是否为后续阶段所需若是则在得到用户输入前不得越过该依赖点提供选项AskUserQuestion跳过该 Agent 并在最终报告中注明缺口 / 以更小范围重试 / 停止并先解决阻塞始终产出部分报告保留已完成的工作绝不因单个 Agent 阻塞而丢弃。常见的阻塞场景及处理输入文件缺失故事找不到、GDD 缺失→ 转给创建它的技能ADR 状态为 Proposed → 不实现先运行/architecture-decision范围过大 → 通过/create-stories拆分为两个故事ADR 与故事指令冲突 → 上报冲突不得擅自猜测Manifest 版本不匹配 → 向用户展示 diff询问按旧规则继续还是先更新故事。七、协作协议编排器不直接写文件dev-story作为编排器遵循严格的协作协议文件写入全部委托所有源码、测试文件、证据文档都由通过 Task 派生的子 Agent 写入每个子 Agent 单独执行 May I write to [path]? 协议编排器自身不直接写文件先加载后实现上下文story、TR-ID、ADR、manifest、引擎偏好未加载完不得开始编码否则代码会偏离设计ADR 即法律实现必须遵循 ADR 的 Implementation Guidelines若指南与看起来更好的做法冲突应在总结中标记而非默默偏离严守范围Out of Scope 段落是契约若实现某验收标准必须触碰越界文件停下来上报Implementing [criterion] requires modifying [file], which is out of scope. Shall I proceed or create a separate story?Logic/Integration 的测试不可缺席测试文件不存在就不能标记实现完成Visual/Feel 标准是延迟而非跳过在总结中标记为 DEFERRED由/story-done人工验证重大结构性决策前先询问若故事需要 ADR 未覆盖的架构模式先上报The ADR doesnt specify how to handle [case]. My plan is [X]. Proceed?这套编排器收集上下文 → 派生专职 Agent 实现 → 汇总报告 → 更新会话状态的模式与仓库中 .claude/docs/coordination-rules.md 定义的纵向委派领导 Agent → 部门主管 → 专家、并行 Task 协议独立输入同时派生、BLOCKED 立即上报、部分报告机制完全一致是 CCGS 多 Agent 编排哲学在实现环节的集中体现。八、从 dev-story 出发的完整闭环实现完成后dev-story的 Recommended Next Steps 指向运行/code-review [file1] [file2]在关闭故事前评审实现运行/story-done [story-path]验证每条验收标准并标记故事完成——该技能会读取 TR 注册表中的当前需求文本、比对 Manifest 版本、检查测试证据门禁Logic/Integration 缺测试为 BLOCKING、生成验收标准 ↔ 测试追溯表并最终更新故事状态与会话状态sprint 内所有故事完成后运行/team-qa sprint执行完整 QA 循环再推进项目阶段。至此一条从/qa-plan sprint到/story-done的研发闭环完整成形dev-story扮演着把设计承诺兑现为可运行代码与可验证测试的关键枢纽其七阶段流程、硬门禁校验、按类型差异化路由与测试策略构成了 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），仅供参考