Claude Code Game Studios 流水线技能测试规范深度解析/create-stories 如何把 Epic 拆解为开发者就绪的故事文件【免费下载链接】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技能测试框架中 pipeline 类别的/create-stories行为规范create-stories.md展开。该规范定义了 CCGS 工作流中Epic → Story拆解环节的完整行为契约技能如何读取上游上下文EPIC、GDD、ADR、控制清单、TR 注册表如何为每条故事生成结构化 frontmatter 并分类为五种故事类型以及在 full / lean / solo 三种评审模式下导演门禁QL-STORY-READY的触发与跳过规则。读完本文你将掌握该技能的行为边界、五种测试用例的验证方法以及如何借助/skill-test静态断言、协议合规清单和测试框架的规范有效性约定在自己的游戏项目中验证和驱动这条故事生产流水线。一、技能定位从 Epic 到 Story 的流水线枢纽CCGS 将游戏研发组织为七阶段流水线零到上线的完整链路见 skill-flow-diagrams.md。在Phase 4Pre-Production中/create-stories处于/create-epics的正下游/create-epics [layer] ───────────────► production/epics/*/EPIC.md /create-stories [epic-slug] ─────────► production/epics/*/story-*.md /prototype [core-mechanic] ──────────► prototypes/[name]/ /sprint-plan new ────────────────────► production/sprints/sprint-01.md/create-stories的输入是单个 Epic输出是若干开发者可以直接认领实施的故事文件。它同时被 catalog.yaml 登记为 pipeline 类别技能spec:字段指向本规范文件并且在 quality-rubric.md 的 pipeline 类别指标P1–P5中受约束正确的输出 schema、层级/优先级排序、每个工件写入前的 May I write、导演门禁按模式触发、以及先读后写P5即产出工件前必须读取相关 GDD/ADR/清单。从 README.md 的项目自述看这正是 CCGS用结构对抗单次会话无组织状态设计哲学的落地一个游戏系统在 GDD 层是需求描述在 Epic 层是范围与架构约束而到了 Story 层必须变成可被/story-readiness校验、可被/dev-story派发给对应程序员 Agent 实施的具体任务单元。二、技能职责总览Skill Summary规范对技能行为的官方定义如下这是全文的事实基线/create-stories将一个 Epic 拆解为开发者就绪的故事文件。它读取EPIC.mdEpic 本体含范围、需求、DoD对应的 GDD设计文档提供验收标准管辖该 Epic 的 ADR架构决策记录提供架构约束控制清单control manifest由/create-control-manifest从所有 Accepted ADR 机械提取的约束汇总见 create-control-manifest.mdTR 注册表docs/architecture/tr-registry.yaml为每条技术需求提供稳定 ID每条故事获得结构化 frontmatter包含Frontmatter 字段含义Title故事标题Epic所属 EpicLayer所在层级Foundation / Core / Feature / PresentationPriority优先级Status状态Ready / Blocked见 Case 3TR-ID关联的注册表技术需求 IDADR references管辖 ADR 引用Acceptance Criteria验收标准Definition of Done完成定义故事按类型分类Logic逻辑/ Integration集成/ Visual/Feel表现手感/ UI界面/ Config/Data配置与数据故事类型决定其必需测试证据路径——例如 Logic 类故事需要单元测试证据Integration 类故事则可走 playtest 文档替代路径见覆盖范围说明一节。在full评审模式下每条故事创建后都会运行一次QL-STORY-READY检查在lean或solo模式下该检查被跳过。技能在写入每条故事文件之前都会询问May I write。故事文件写入production/epics/[layer]/story-[name].md。三、静态断言/skill-test static的七项结构检查静态断言由/skill-test static自动验证无需 fixture即不需要准备项目现场。它们校验的是技能自身文档而非技能行为的结构完备性共七项具备必需的 frontmatter 字段name、description、argument-hint、user-invocable、allowed-tools具备 ≥2 个阶段标题phase headings包含判定关键词COMPLETE、BLOCKED、NEEDS WORK包含 May I write 协作协议语言逐故事审批末尾有下一步交接handoff/story-readiness、/dev-story记录故事 Status当管辖 ADR 为 Proposed 时故事为 Blocked记录 QL-STORY-READY 门禁full 模式激活lean/solo 模式跳过这一检查清单与 skill-test-spec.md 模板 中Static Assertions章节的结构一一对应说明本规范是严格按模板生成的。其中 frontmatter 五项要求对应 Claude Code 技能Skill的标准声明格式allowed-tools决定了技能可使用的工具集合May I write 语言要求只在 allowed-tools 包含 Write/Edit 时强制模板原话而/create-stories显然需要写文件因此该语言是硬性要求。四、导演门禁检查三种评审模式下的 QL-STORY-READYCCGS 的评审模式由production/session-state/review-mode.txt的内容决定full/lean/solo该机制在 gate 类别指标 G1 与 readiness 指标 RD4 中被反复强调。/create-stories的导演门禁行为如下full 模式每条故事创建后运行 QL-STORY-READY 检查。未通过的故故事在 May I write 询问之前被标记为NEEDS WORK。注意full 模式下的门禁是**质检负责人QA lead**级别的 QL-STORY-READY而非顶层导演。lean 模式QL-STORY-READY 被跳过输出逐故事注明 QL-STORY-READY skipped — lean mode。solo 模式QL-STORY-READY 被跳过输出等价注明。这与上游/create-epics的 PR-EPICproducer 门禁模式形成对照PR-EPIC 在 full 模式于草拟 Epic 之后、写入任何文件之前运行QL-STORY-READY 则在 full 模式于每条故事创建之后运行。两者共同遵循 pipeline 类别指标 P4 的约定——范围内门禁在 full 运行、在 lean/solo 跳过并注明且任何门禁都不得自动阻断写入最终决定权始终在用户手中见 Case 5 断言。五、测试用例详解五个场景的 fixture、期望行为与断言本规范的核心是五个行为测试用例。每个用例都定义了 fixture假定项目状态、输入、期望行为与断言清单。下面逐一展开。Case 1Happy Path —— 3 条故事的 EpicADR 全部 AcceptedFixtureproduction/epics/[layer]/EPIC-[name].md存在含 3 条 GDD 需求对应 GDD 存在且验收标准与 Epic 匹配所有管辖 ADR 均为Status: Accepteddocs/architecture/control-manifest.md存在docs/architecture/tr-registry.yaml为全部 3 条需求提供了 TR-IDproduction/session-state/review-mode.txt内容为lean输入/create-stories [epic-name]期望行为技能读取 EPIC.md、GDD、管辖 ADR、控制清单和 TR 注册表将每条需求分类为故事类型Logic / Integration / Visual/Feel / UI / Config/Data按正确 frontmatter schema 草拟 3 个故事文件QL-STORY-READY 被跳过lean 模式——在输出中注明写入每个故事文件前询问 May I write获批后写入全部 3 个故事文件断言每条故事的 frontmatter 包含Title、Epic、Layer、Priority、Status、TR-ID、ADR reference、Acceptance Criteria、DoD故事类型分类正确fixture 中至少有一个 Logic 类型May I write 按故事逐个询问而非整批只问一次输出中注明 QL-STORY-READY 跳过3 个故事文件按story-[name].md命名正确写入技能不开始实施不越界写实现代码这里值得注意May I write 逐条询问与技能不越界实施两条它们共同体现了 CCGS 协作协议的两个支柱——用户对每个产出物有审批权且技能严格守在自己的职责边界内拆故事不写代码。Case 2失败路径 —— 找不到 Epic 文件Fixture提供的 epic 路径在production/epics/下不存在。输入/create-stories nonexistent-epic期望行为技能尝试读取 EPIC.md文件未找到技能输出明确错误并给出所搜索的路径技能建议检查production/epics/或先运行/create-epics不创建任何故事文件断言技能输出明确错误点名缺失的文件路径不写入任何故事文件技能推荐正确的下一步动作/create-epics技能不会在没有有效 EPIC.md 的情况下创建故事这一用例验证的是 pipeline 指标 P5先读后写的失败分支上游工件缺失时技能必须干净地停止对应判定关键词 BLOCKED 的场景而不是凭想象生成故事。Case 3受阻故事 —— ADR 状态为 ProposedFixtureEPIC.md 存在含 2 条需求需求 1 由一条 Accepted ADR 覆盖需求 2 由一条Status: Proposed的 ADR 覆盖输入/create-stories [epic-name]期望行为技能读取需求 2 的 ADR发现 Status: Proposed需求 2 的故事以Status: Blocked草拟阻断注记引用具体 ADRBLOCKED: ADR-NNN is Proposed需求 1 的故事正常以Status: Ready草拟两条故事都在草稿中展示——用户对两者都被询问 May I write断言故事 2 的 frontmatter 中Status: Blocked阻断注记点名具体 ADR 编号并推荐/architecture-decision故事 1 为Status: Ready——阻断状态不影响非阻断故事写入前在草稿预览中展示 Blocked 状态两个故事文件都会写入Blocked 故事仍然写入——只是被标记这条用例揭示了 CCGS 对受阻的处理哲学受阻不等于搁置。Blocked 故事照常落盘、照常进入下游但状态与注记让/story-readiness能立即识别它story-readiness.md 的 Case 2 正是引用 ADR 为 Proposed → 判定 BLOCKED从而把决策显式地暴露给用户。这与 readiness 指标 RD3BLOCKED 保留给故事作者无法自行修复的问题如 Proposed ADR完全一致。Case 4边界情况 —— 未提供参数Fixtureproduction/epics/存在且含 ≥2 个 epic 子目录。输入/create-stories无参数期望行为技能检测到未提供参数输出用法错误No epic specified. Usage: /create-stories [epic-name]技能列出production/epics/中可用的 epic不创建任何故事文件断言无参数时输出用法错误列出可用 epic 以帮助用户选择不写入任何故事文件技能不会在无用户输入的情况下静默挑选一个 epicCase 5导演门禁 —— full 模式运行 QL-STORY-READY未通过者标记 NEEDS WORKFixtureEPIC.md 存在含 2 条需求两条管辖 ADR 均为 Acceptedproduction/session-state/review-mode.txt内容为fullQL-STORY-READY 检查发现其中一条故事的验收标准存在歧义输入/create-stories [epic-name]期望行为两条故事均被草拟每条故事都运行 QL-STORY-READY 检查故事 1 通过 QL-STORY-READY故事 2 未通过——被标记为 NEEDS WORK附具体反馈两条故事在 May I write 前都向用户展示通过/未通过状态用户可以选择继续故事原样写入并带 NEEDS WORK 注记或先修订断言输出中逐故事出现 QL-STORY-READY 结果故事 2 被标记为 NEEDS WORK并指明未通过的具体标准故事 1 显示通过 QL-STORY-READY写入前用户被给予继续或修订的选择技能不会在未经用户输入的情况下自动阻止写入未通过 QL-STORY-READY 的故事Case 5 是 QL-STORY-READY 门禁行为的完整验证门禁负责揭示风险NEEDS WORK 具体反馈但门禁结果永远不是最终裁决——用户才是。这与 readiness 指标 RD4QL-STORY-READY 在 full 模式触发、lean/solo 跳过并注明以及模板中技能不得在 CONCERNS 或 FAIL 判定下自动推进的原则一致。六、协议合规清单七项协作协议硬约束协议合规是跨用例的横切要求任何用例执行时都必须满足草拟故事前加载全部上下文EPIC、GDD、ADR、manifest、TR 注册表任何 May I write 询问前完整展示故事草稿May I write 逐故事询问而非整批一次Blocked 故事在写入审批前标记——而非写入后才被发现TR-ID 引用注册表——需求文本不内嵌在故事文件中保证单一事实来源防止需求文本在 Story 层漂移控制清单规则逐故事从 manifest 引用不得凭空编造以下一步交接收尾/story-readiness→/dev-story最后一条把/create-stories与下游串成完整闭环故事文件落盘后/story-readiness只读校验四维度Design / Architecture / Scope / DoD产出 READY / NEEDS WORK / BLOCKED验证故事可认领性确认 READY 后由/dev-story路由到对应的程序员 Agentgameplay-programmer、engine-programmer 等开始实施实施完成后由/story-done依据 TR 注册表中的当前需求文本核验完成度。真实的端到端运转样例见 session-story-lifecycle.md其中 STORY-MOV-001 由/create-stories生成随后经历/story-readiness四维度校验发现翻滚方向歧义 → NEEDS WORK → 用户澄清 → READY→ 实施 → 测试的完整生命周期。七、覆盖范围说明测试边界的诚实声明规范在最后明确划出了未被 fixture 直接覆盖的边界这是测试框架描述当前行为、不掩盖缺口态度的体现该原则出自 CCGS Skill Testing Framework/CLAUDE.md 的 Spec Validity NoteIntegration 故事的测试证据集成类故事的测试证据playtest 文档替代路径遵循与 Logic 故事相同的审批模式但未独立做 fixture 测试。故事排序基础故事优先、UI 最后foundational first, UI last的排序规则通过 Case 1 的多故事 fixture隐式验证无专门用例。故事规模规则拆分过大需求分组的规则未在此测试——它由/create-stories技能本体内部逻辑处理不属于本规范的测试范围。这三点对使用者的直接启示是如果你要为/create-stories扩充测试覆盖Integration 证据路径和故事排序是天然的补测候选。八、测试框架机制如何实际运行这套规范本规范并非孤立文档它运行在 CCGS Skill Testing Framework 的完整测试体系中用法详见 测试框架 README命令作用/skill-test static create-stories运行第三节的七项静态断言无需 fixture/skill-test static all对所有 72 个技能运行静态断言/skill-test spec create-stories按本规范逐用例评估技能行为fixture 需人工准备/skill-test category create-stories对照 pipeline 类别指标P1–P5评估/skill-test audit全量覆盖视图has-spec、上次测试时间、结果/skill-improve create-stories测试 → 诊断 → 提议修复 → 重写 → 重测 的完整改进循环执行流程CLAUDE.md先读catalog.yaml取技能的spec:路径与category:再读技能本体与规范逐用例评估断言最后将结果写入results/并更新catalog.yaml的last_spec/last_spec_result字段。两个需要牢记的框架约定规范描述的是当前行为而非理想行为这些 spec 是阅读技能本体后撰写的因此可能编码了技能的实际缺陷。技能在实践中表现异常时应优先修正技能本体再更新规范使其匹配修正后的行为规范测试失败应视为需要调查而非技能一定错了。目录自包含且可删除CCGS Skill Testing Framework/与主项目无任何导入关系删除它不影响 CCGS 技能/Agent 本身/skill-test与/skill-improve仍能运行会报告 catalog.yaml 缺失并引导初始化。九、TR 注册表与故事引用为什么 TR-ID 必须来自注册表协议合规要求TR-ID 引用注册表——需求文本不内嵌在故事文件中其底层依据是 docs/architecture/tr-registry.yaml。该文件头部注释明确规定了它的使命与使用规则目的为每条 GDD 技术需求提供持久、稳定的 ID防止TR-ID在多次/architecture-review中重编号而破坏故事引用。ID 格式TR-[system-slug]-[NNN]system-slug为系统短名NNN为按系统从 001 起的三位零填充序号。状态值active活跃/deprecated废弃/superseded-by: TR-[system]-NNN被替代。硬规则ID 永久有效绝不重编号、绝不删除只能置 deprecated新条目只能追加到各系统列表末尾需求改写但意图不变时更新文本并加revised日期ID 保持不变需求被拆分或替换时置superseded-by。注释中明确列出其读写方由/architecture-review写入只追加、从不覆盖由/create-stories读取在故事中嵌入 ID同时/story-done评审时查当前需求文本与/story-readiness校验 TR-ID 存在且活跃也读取它。文件当前为骨架状态version: 1、requirements: []含 combat 系统的示例条目实际条目由真实项目的 architecture-review 流程填充。正是这套机制保证了需求文本在 GDD → 注册表 → 故事之间只有一份权威来源故事文件只存 ID 引用需求一旦改写reworded所有引用它的故事自动获得最新语义无需逐文件同步。十、与上下游技能的衔接把 /create-stories 放进完整工作流最后从 create-epics.md 和 story-readiness.md 看/create-stories在整个流水线中的上下游契约上游输入就绪条件/create-epics按层Foundation → Core → Feature → Presentation把 Approved GDD 转为 EPIC.md每条 Epic 含 scope、管辖 ADR、GDD 需求、引擎风险等级与 DoD并在 full 模式运行 PR-EPICproducer门禁其结尾交接正是/create-stories [epic-slug]。因此/create-stories的 无 epic 文件失败路径Case 2实际上是在用户跳过或遗漏上游步骤时兜底。/create-control-manifest只从 Accepted ADR 提取 Required/Forbidden Patterns 生成控制清单Proposed ADR 被排除并注明——这保证了/create-stories引用的 manifest 规则全部有 Accepted 架构依据。/architecture-decision产出 ADR含 Accepted/Proposed 状态是 Case 3 中 Blocked 判定与/architecture-decision推荐的来源。下游产出消费方/story-readiness四维度校验Design / Architecture / Scope / DoD验证故事可认领性其 Case 1 fixture 中TR-ID: TR-light-001、ADR: docs/architecture/adr-003-inventory.md、Status: Ready for Dev、manifest 版本匹配等字段与/create-stories的 frontmatter schema 一一对应——说明本规范的输出 schema 就是下游校验的输入契约。/dev-story将 READY 故事路由到对应程序员 Agent开启实施阶段见 skill-flow-diagrams.md 的 Phase 5 生产循环。总结/create-stories的测试规范不仅是一份验收文档更是一份契约——它把一个 Epic 应被拆成什么样子、受阻时如何标记、门禁在何种模式生效、每一步如何征得用户同意全部固化为可自动断言的检查项。借助 skill-test-spec.md 模板 与/skill-test//skill-improve工具链这套方法可以平移到 CCGS 的其他 pipeline 技能create-epics、dev-story、map-systems 等甚至你自己的自定义技能上让每一个流水线产物都具备可验证的质量底线。【免费下载链接】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），仅供参考