Claude Code Game Studios 实战：一条 Story 的完整生命周期（/story-readiness → 实现 → /story-done）
Claude Code Game Studios 实战一条 Story 的完整生命周期/story-readiness → 实现 → /story-done【免费下载链接】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 仓库中的示例会话 session-story-lifecycle.md完整还原一条功能 StorySTORY-MOV-001「实现 CharacterBody2D 移动系统」从就绪校验、代码实现到完成验收的全过程。你将看到/story-readiness、/story-done、/sprint-status三个核心技能如何在 13 轮对话中协同工作readiness 四维校验如何拦截真实的设计歧义、ADR 状态如何成为硬性闸门、验收标准如何分级标记 AUTO / MANUAL / DEFERRED以及sprint-status.yaml如何成为冲刺状态的单一事实来源。读完本文你将掌握这套设计—架构—实现—验收闭环流水线的完整操作姿势与底层校验逻辑。背景示例会话的起始状态这是一位独立开发者在冲刺中期的一次实战会话前置条件如下design/gdd/movement-system.md已完稿8 个章节齐全docs/architecture/movement-adr-001.md状态为Accepted已接受production/sprints/sprint-03.md的 backlog 中列有 STORY-MOV-001production/stories/STORY-MOV-001.md已由/create-stories生成但尚未通过就绪校验没有任何实现代码。会话持续约50 分钟、13 轮对话最终 Story 被验证就绪、完成实现并由/story-done判定为COMPLETE WITH NOTES。值得说明的是示例中production/stories/、design/gdd/等路径是本仓库约定目录结构下的示例位置当前仓库以 skill 测试规格 和 模板 的形式固化这套流程并提供了真实的注册表文件 tr-registry.yaml 与 architecture.yaml 作为 TR-ID 与架构决策的校验数据源。Phase 1Story 就绪校验/story-readiness第 1–2 轮运行就绪检查并输出四维校验结果开发者在第 1 轮执行/story-readiness production/stories/STORY-MOV-001.mdAgent 读取 Story 后运行4 项校验对应/story-readiness技能的四个维度见 story-readiness 技能测试规格1. Design Completeness设计完整性引用的 GDDdesign/gdd/movement-system.md✅GDD 章节覆盖Detailed Rules ✅、Formulas ✅、Edge Cases ✅内嵌 TR-IDTR-MOV-001 至 TR-MOV-008 ✅2. Architecture Completeness架构完整性引用的 ADRdocs/architecture/movement-adr-001.md✅ADR 状态Accepted✅若为 Proposed 则 BLOCKEDStory 中的控制清单control manifest版本2026-03-10与当前清单一致 ✅3. Scope Clarity范围清晰度验收标准9 项全部可度量 ✅范围外项目已列出游泳、攀爬 ✅发现歧义1 处Story 写翻滚方向跟随最后一次输入方向而 GDD 写朝移动方向翻滚——当玩家停下后立即翻滚时二者冲突需在开工前澄清。4. Definition of Done完成定义需要的测试公式函数单元测试 ✅集成信号on_stamina_event必须正确触发 ✅最终判定为NEEDS WORK并提示存在 1 处必须在实现开始前解决的歧义。从技能测试规格看这套校验有明确的底层契约技能必须读取被引用的 ADR 文件而非仅读 Story 中的引用行、必须校验 ADR 状态是否为Accepted、必须读取 tr-registry.yaml 验证 TR-ID 真实存在、必须核对 Story 头部嵌入的 control manifest 版本与当前清单一致。三个判定等级语义清晰READY四项维度全部通过NEEDS WORK存在可在 Story 层面修复的问题如缺验收标准章节、清单版本过期BLOCKED存在外部依赖问题如 ADR 仍为Proposed在外部条件满足前无论如何不能开工。第 3–4 轮解决歧义并更新 Story用户裁决翻滚使用最后一次移动方向。如果玩家站立不动翻滚使用当前面朝方向。Agent 据此更新 Story 的 Detailed Rules 章节Roll direction: last movement direction. If velocity is zero at roll input, roll uses current facing direction.在征得用户同意May I write...后写入 Story并将状态置为ready-for-dev最终判定READY。注意/story-readiness本身是只读技能它只负责校验与给出判定对 Story 的写入发生在歧义澄清流程中且严格遵循先征求同意再写入的协作协议协议合规要求见 story-readiness 规格 的 Protocol Compliance 一节。Phase 2实现Implementation第 5–6 轮读取 Story 与 ADR提出文件结构用户确认开始实现后Agent 以 gameplay-programmer 身份读取 Story、GDD 与 ADR从 ADR-001 提取三条架构约束MovementComponent.gd挂在玩家场景上而非单例地形修正通过TerrainLayer.get_modifier(tile_position)辅助函数查询体力事件通过 signal 发出不直接调用 StaminaSystem。据此提出文件结构并征求同意src/gameplay/movement/ movement_component.gd # CharacterBody2D logic, state machine terrain_modifier_table.gd # Const table: terrain_type - {speed_mod, drain_mod} tests/unit/ test_movement_formulas.gd # Unit tests for speed/drain calculations这里体现了仓库 README 中Collaborative, Not Autonomous的协作协议Agent 展示工作草稿Draft→ 用户拍板Approve任何文件写入前都必须经过用户确认而不是让 AI 全自动操作。第 7 轮展示关键代码片段Agent 在写文件前先展示关键片段供评审class_name MovementComponent extends Node signal stamina_event(type: String, amount: float) export var base_walk_speed: float 120.0 export var run_multiplier: float 1.7 export var stamina_drain_walk: float 2.0 export var stamina_drain_run: float 6.0 export var stamina_cost_roll: float 15.0 var _is_carrying_heavy: bool false func _physics_process(delta: float) - void: var terrain_mod : _get_terrain_modifier() var effective_speed : _calculate_speed(terrain_mod) # ...所有数值均为export可在编辑器中配置无硬编码——这正对应该仓库src/gameplay/**路径规则的强制要求Data-driven values数据驱动取值。stamina_event信号也是后面/story-done验收中集成信号正确触发这一验收项的落点。第 8–9 轮写入文件与单元测试Agent 写入三个文件后运行 lint 检查无错误并创建6 个单元测试覆盖步行速度公式3 种地形类型跑步速度公式体力消耗计算翻滚体力消耗含零速度边界情况。同时明确指出需要手动测试的部分无敌帧、斜坡阻挡、地形集成需要运行场景——这为 Phase 3 的 MANUAL 验收项埋下伏笔。Phase 3Story 完成/story-done第 10–11 轮运行完成评审用户在场景中手动验证通过后执行/story-done production/stories/STORY-MOV-001.mdAgent 运行多阶段完成评审对应 story-done 技能测试规格 描述的流程Phase 1Story 定位✅production/stories/STORY-MOV-001.mdPhase 2验收标准逐条验证AUTO 自动化测试 / MANUAL 用户人工确认 / DEFERRED 暂缓#验收标准验证方式状态1普通地形步行速度正确自动公式单元测试通过✅ AUTO2跑步速度正确自动公式单元测试通过✅ AUTO3体力为 0 时跑步取消手动用户确认✅ MANUAL4翻滚无敌帧生效手动用户确认✅ MANUAL5地形修正正确生效手动用户确认✅ MANUAL6负重时禁用跑步自动库存未集成暂不可测⏳ DEFERRED7体力信号正确触发自动集成测试待办⏳ DEFERRED8无硬编码数值自动grep 魔法数字 → 0 处✅ AUTO9坡度 45° 阻挡移动手动用户确认✅ MANUALPhase 3GDD/ADR 偏差扫描按 TR-ID 逐条核对实现——TR-MOV-001 至 TR-MOV-007 全部按规格实现TR-MOV-008负重信号标注为ADVISORY因依赖库存集成 Story 而暂缓属于当前不可验证并非偏差。这里的关键设计是Story 中只存 TR-ID如 TR-MOV-001而不是引用 GDD 原文。完成评审时从 tr-registry.yaml 重新读取最新需求文本进行比对避免日后 GDD 措辞被清理时产生虚假的偏差标记详见本文经验总结。Phase 4Manifest 过期检查Story 的控制清单版本2026-03-10与当前清单版本一致 ✅说明 Story 中的实现指引没有偏离当前架构决策。Phase 5代码评审提示建议在标记完成前运行/code-review src/gameplay/movement/非阻塞性建议。最终判定COMPLETE WITH NOTES——两条验收标准暂缓到库存集成 Story记录为 deferred 而非 blocked。第 12 轮关闭 Story 并更新冲刺状态经用户同意后写入StoryStatus: Complete Completion Notes注明暂缓标准production/sprint-status.yaml中 STORY-MOV-001 置为done。暂缓项被显式记录将在库存集成 Story 中自动浮出负重禁用跑步需要库存信号体力信号集成测试需要体力系统。同时 Agent 给出下一条可接手的 StorySTORY-MOV-002体力系统下游依赖已解锁与 STORY-HUD-001移动 HUD 指示器并建议对下一个 Story 运行/story-readiness。production/sprint-status.yaml的写入遵循May I write协议且该文件是冲刺状态的单一事实来源由/story-done写入由/sprint-status读取见 sprint-status 技能测试规格。/sprint-status是 Haiku 层级的只读技能按状态统计 Story 数量并给出 ON TRACK / AT RISK / BLOCKED 冲刺健康判定且在任何 review mode 下都不调用总监门禁。深挖底层三个技能的机制设计三档判定与硬性闸门/story-readiness区分 NEEDS WORK可自行修复与 BLOCKED需外部动作是刻意的设计缺失验收标准章节属于 NEEDS WORK而 ADR 为Proposed属于 BLOCKED——不允许在未接受的 ADR 上实现。示例中如果movement-adr-001.md是ProposedStory 会直接 BLOCKED实现根本不会开始。版本一致性作为质量信号Story 头部嵌入的 control manifest 版本与当前清单版本不匹配时按测试规格属于 ADVISORY 级问题结果 NEEDS WORK 而非 BLOCKED它提示 Story 内嵌的实现指引可能已过期但不会阻止修复性开工。版本机制的价值在于让Story 的指导信息是否过时变成可机器校验的事实而不是靠人记。Director Gate 随 review mode 伸缩按测试规格/story-readiness在full模式下会追加 QL-STORY-READY 总监门禁QA lead 判定 INADEQUATE 可直接覆盖四维结果为 BLOCKED/story-done在full模式下会追加 LP-CODE-REVIEW 门禁Lead Programmer 判定 NEEDS CHANGES 则 Story 不得标记完成。而在lean或solo模式下门禁被显式跳过并在输出中注明。review mode 本身在/start或production/review-mode.txt中配置可覆盖为full全总监门禁/lean仅阶段门禁/solo无门禁。暂缓Deferred而非阻塞Blocked/story-done对无法验证的验收标准采取询问用户 → 标记 DEFERRED → COMPLETE WITH NOTES策略而不是假设通过或阻塞完成。这与所有验收标准必须验证的僵化流程形成对比跨 Story 的集成依赖被显式记录形成技术债可写入docs/tech-debt-register.md并在下游 Story 中自动浮出。技能测试规格明确要求技能不得在存在 ERROR 状态验收标准时标记 Complete但 DEFERRED 不构成 ERROR。经验总结这个示例教会我们什么原文档用 6 条经验概括了这套流水线的设计哲学结合源码验证如下Readiness 闸门能拦截真实问题翻滚方向的歧义如果不经/story-readiness暴露就会演变成实现后期被迫做决策的返工ADR 状态是硬闸门movement-adr-001.md若为Proposed而非AcceptedStory 将 BLOCKED、实现不会开始暂缓标准Deferred合理放行并非所有验收标准都能在 Story 关闭时验证/story-done跟踪 deferred 项而非阻塞完成TR-ID 引用优于引用 GDD 原文Story 存储 TR-MOV-001 这样的 ID 而非引用 GDD 文字避免日后 GDD 措辞修订时触发虚假的偏差标记——偏差核对以 tr-registry.yaml 为准sprint-status.yaml是冲刺状态单一事实来源由/story-done写入、由/sprint-status读取保证冲刺健康报告的准确性Manifest 版本检查确保 Story 的实现指引没有偏离当前的架构决策。上手路径如何在自己的项目里复刻这套闭环当前仓库以「技能 测试规格」的形式提供这套流程的完整参考实现阅读 story-readiness 技能测试规格了解四维校验、三档判定与 QL-STORY-READY 门禁的行为契约阅读 story-done 技能测试规格了解五阶段评审、AUTO/MANUAL/DEFERRED 分级、偏差分类INTENTIONAL / ERROR / OUT OF SCOPE与 LP-CODE-REVIEW 门禁阅读 sprint-status 技能测试规格了解冲刺健康判定与只读约束参考 create-stories 技能测试规格 理解 Story 文件是如何生成的查看 tr-registry.yaml 与 architecture.yaml理解 TR-ID 与 ADR 的注册表校验模型对照 README.md 中 Slash Commands 与 Path-Scoped Rules 两节把/story-readiness、/dev-story、/story-done接入自己的冲刺节奏。在 Claude Code 会话中依次执行/create-stories→/story-readiness story→ 实现 →/story-done story即可复刻本文 13 轮对话的完整闭环设计约束GDD/TR-ID、架构约束ADR/清单版本与验收证据自动测试 人工确认在每一环都被显式校验让一条 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考