Claude Code Game StudiosCCGS技能行为测试规范编写指南用 Skill Test Spec 为 72 个工作流技能建立可验收的质检标准【免费下载链接】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中49 个 Agent 与 72 个工作流技能构成了完整的游戏研发流水线而质量保障的关键在于每一个技能都必须能被自动验证。.claude/docs/templates/skill-test-spec.md仓库内还有一份功能等价的副本 CCGS Skill Testing Framework/templates/skill-test-spec.md正是这套验证体系的契约文件模板——它为每个技能定义行为测试规范Behavioral Spec供/skill-test spec按规范逐条断言评估。读完本文你将掌握该模板的完整结构、每个字段的编写要求、与/skill-test四种运行模式的联动方式以及如何用真实示例如 gate-check 规范为任意技能写出可被机器逐条验收的测试规格。一、为什么需要 Skill Test Spec从看起来合规到行为正确CCGS 的技能文件SKILL.md本身是 Markdown 指令可以被静态检查frontmatter 是否齐全、是否有 ≥2 个阶段标题、是否包含判定词但静态合规不等于行为正确。一个技能可能结构完整却在缺少必需文件时依然输出 PASS、未征求用户同意就写文件等关键行为上出错。Skill Test Spec 的定位正是弥补这一缺口它是描述技能在给定项目状态下应当如何表现的行为契约由 .claude/skills/skill-test/SKILL.md 中的spec模式逐条读取并评估。该规范文件明确写道This is a Claude-evaluated reasoning check, not code execution.也就是说/skill-test spec不是运行被测试的技能代码而是通读技能指令与被测规范以推理方式判断技能在被测夹具fixture状态下按指令执行是否满足每一条断言。断言结果分为PASS明确满足、PARTIAL部分满足但存在歧义、FAIL给定夹具下不满足。这套设计让规范同时服务两个读者人编写时理清技能的预期行为边界和LLM 评估器/skill-test spec执行时逐条裁决。这也是该模板全文采用Fixture → Input → Expected behavior → Assertions四段式的原因——四者合起来构成一个可推理的最小行为场景。二、模板总览一份 Skill Test Spec 的五段式骨架模板 .claude/docs/templates/skill-test-spec.md 的结构如下章节作用谁消费它Skill Summary一段话说明技能做什么、何时用、产出什么、属于哪个流水线阶段人评审者、后续维护者Static Assertions (Structural)列出应通过/skill-test static的结构性断言无需夹具/skill-test static静态检查Test Cases23 个行为场景Happy Path / Failure Path / Edge Case每个含 Fixture、Input、Expected behavior、Assertions/skill-test spec行为验证Protocol Compliance协作协议合规清单May I write、先呈现再征批、结尾给出下一步/skill-test spec的协议段Coverage Notes记录刻意不测的内容及原因人避免后人误补或误以为遗漏配套的 CCGS Skill Testing Framework/templates/agent-test-spec.md 是 Agent 版本结构类似多了 Tier/Category 头、Domain/Escalates to/Delegates to、Out-of-Domain Redirect 与 Conflict Escalation 等用例本文聚焦技能版本。三、逐节编写指南3.1 Skill Summary一段话交代五个要素模板要求在一段话内说明这个技能做什么、何时使用、产出什么并包含主要产出工件、它使用的判定格式、以及它所属的流水线阶段。参考真实范例 CCGS Skill Testing Framework/skills/gate/gate-check.md 的写法/gate-checkvalidates whether the project is ready to advance to the next development phase. It checks for required artifacts, runs quality checks, asks the user about unverifiable items, and produces a PASS/CONCERNS/FAIL verdict. On PASS with user confirmation, it writes the new stage name toproduction/stage.txt. It governs all 6 phase transitions and is the most critical gate-keeping skill in the pipeline.注意这段摘要已经点出了判定格式PASS/CONCERNS/FAIL、写入工件production/stage.txt、所属定位6 个阶段转换的 gate 技能。规范的摘要写清楚了/skill-test spec的评估器才能据此校验后续用例的合理性。3.2 Static Assertions与/skill-test static的 7 项检查对齐模板的 Static Assertions 章节标注了由/skill-test static自动验证无需夹具。它对应的正是 .claude/skills/skill-test/SKILL.md 的 Phase 2A 中定义的 7 项检查Check 1 — Required Frontmatter Fieldsfrontmatter 必须含name、description、argument-hint、user-invocable、allowed-tools五个字段缺一即 FAILCheck 2 — Multiple Phases≥2 个阶段标题## Phase N、## N.或 ≥2 个##标题不足 2 个即 FAILCheck 3 — Verdict Keywords必须至少包含PASS、FAIL、CONCERNS、APPROVED、BLOCKED、COMPLETE、READY、COMPLIANT、NON-COMPLIANT之一一个都没有即 FAILCheck 4 — Collaborative Protocol Language要求先问再写的语言规范形式为May I write或before writing/approval邻近写文件指令、或ask与write同段共现。缺失时 WARN若allowed-tools含Write/Edit却无此类语言则直接 FAILCheck 5 — Next-Step Handoff结尾须有下一步建议如提到/story-done、/gate-check、Recommended next/Follow-Up 字样缺失时 WARNCheck 6 — Fork Context Complexity若 frontmatter 含context: fork则需 ≥5 个阶段标题fork 上下文专供复杂多阶段技能使用不足则 WARNCheck 7 — Argument Hint Plausibilityargument-hint不能为空且应与正文的多模式描述如 Mode A | Mode B及第一阶段Parse Arguments部分互相印证不匹配则 WARN。因此模板中Static Assertions的勾选项应直接映射到上述 7 项检查——特别是判定词清单应如实列出该技能真正会输出的词模板示例给出的PASS, FAIL, CONCERNS与 gate-check 一致。3.3 Test Cases三种场景的编写规范模板定义了三个用例模板每个用例统一包含Fixture假设的项目状态哪些文件存在、内容如何、Input/[skill-name] [args]、Expected behavior分阶段的预期动作、Assertions可勾选的断言清单四部分Case 1: Happy Path正常路径—— 描述一切就绪时技能应如何表现。以 gate-check 规范的真实写法为例Fixturedesign/gdd/game-concept.md存在且包含全部必需章节design/gdd/game-pillars.md存在尚无 systems index该阶段正确状态。Input/gate-check systems-designExpected behavior1) 读取game-concept.md并验证有内容2) 检查 game pillars3) 检查质量项核心循环已描述、目标受众已明确4) 输出结构化清单并逐项标记5) 给出 PASS/CONCERNS/FAIL 判定6) 若 PASS 则询问 May I updateproduction/stage.txtto Systems Design?Assertions技能必须先 Glob/Read 验证文件存在再标记为已检查输出含 Required Artifacts 与 Quality Checks 分区输出含 Verdict 行对无法自动验证的质量项应提问而非假定 PASS更新production/stage.txt前必须说 May I write未经用户确认不得写入。编写要点Happy Path 的断言应当验证技能确实读取了文件、输出了正确的分区与判定词、并在写文件前征求同意——也就是把技能是否走完了它自己承诺的流程全部显式化。Case 2: Failure Path失败路径—— 描述关键工件缺失时技能必须暴露缺口而非假装正常。gate-check 规范的对应场景是game-concept.md不存在、design/gdd/为空Expected behavior读取失败 → 将必需工件标记为缺失 → 输出 FAIL → 列出 blocker No game concept document found → 建议补救动作运行/brainstorm创建。Assertions缺失必需工件时判定必须是 FAIL而非 PASS 或 CONCERNS输出必须点名缺失的具体文件输出含至少 1 项 Blockers给出补救建议FAIL 时不得写入production/stage.txt。编写要点模板特别强调两条——Skill does NOT output PASS when the fixture is incomplete夹具不完整时绝不能输出 PASS和Skill does not create files to fill in the gap without asking不得未经询问就自行创建文件补缺。这对应 CCGS 的协作原则技能是顾问而非越权执行者。Case 3: Edge Case边界情况—— 模板给出的示例是无参数调用/[skill-name]。gate-check 规范将其扩展为无参数时自动探测当前阶段读取production/stage.txt推断当前阶段 → 确定下一个 gate → 直接执行对应检查且输出头必须同时标明当前与目标阶段如 Gate Check: Concept → Systems Design。该规范的 Note 还修正了一个常见误解技能在自动探测到转换后仍会用 AskUserQuestion 向用户确认这是确认步骤而非让用户选 gate断言不应将其视为失败——这个修正说明Edge Case 断言应区分询问确认与推卸决策两种不同行为。3.4 Protocol ComplianceCCGS 协作协议的验收清单模板的协议合规段是固定五条任何技能规范都应当保留所有文件写入前使用May I write先呈现发现/报告再请求写文件批准结尾给出推荐的下一步或后续技能未经用户明确批准绝不自动创建文件不跳过阶段、不未经检查直接跳到判定。在/skill-test spec的执行流程中见 .claude/skills/skill-test/SKILL.md Phase 2B Step 3这些协议断言是总是存在always present的固定检查项无论被测技能属于哪个类别。3.5 Coverage Notes主动声明不测什么模板用一个列表要求作者记录刻意不覆盖的场景及原因示例包括Case 3all 模式未覆盖因为它在单个 spec 中运行检查过多——应逐个测试每个子模式数据库集成路径未覆盖因为它需要真实环境损坏的 YAML 文件的边界情况推迟到未来的 spec。gate-check 规范的真实 Coverage Notes 提供了教科书式写法——它将 Production→Polish、Polish→Release 两个 gate 显式排除需要 sprint plans、playtest data、QA sign-off 等多工件环境将 CONCERNS 判定路径声明为介于 Case 1 与 Case 2 之间、遵循相同模式的过渡态并将 Vertical Slice 验证排除需要可玩构建无法用文档夹具表达。写 Coverage Notes 的价值在于让后来的维护者知道没测是深思熟虑的决定而不是疏漏避免误补破坏规范的边界。四、与/skill-test四种模式的协作关系编写规范的目的不是摆设而是被 .claude/skills/skill-test/SKILL.md 消费。该技能提供四种模式CCGS Skill Testing Framework/README.md 给出了对应命令模式命令与 Skill Test Spec 的关系static/skill-test static [name\|all]结构检查器验证规范的 Static Assertions 章节对应的 7 项检查无需夹具spec/skill-test spec [name]行为验证器读取技能 规范文件逐条评估每个 Test Case 与 Protocol Compliance 断言category/skill-test category [name\|all]类别评分按 CCGS Skill Testing Framework/quality-rubric.md 中该类别gate/review/authoring/…的 45 项指标评估audit/skill-test audit覆盖率报告列出所有技能与 Agent 的 has-spec、last tested、result在spec模式执行时规范文件的定位流程为技能位于.claude/skills/[name]/SKILL.md规范路径从 CCGS Skill Testing Framework/catalog.yaml 的spec:字段解析技能缺失、catalog 无 spec 路径、或规范文件不存在时分别输出明确的错误信息Skill [name] not found...、No spec path set...、Spec file missing at [path]. Run/skill-test auditto see coverage gaps.。spec模式结束后会询问May I write these results toCCGS Skill Testing Framework/results/skill-test-spec-[name]-[date].mdand updateCCGS Skill Testing Framework/catalog.yaml?——获批后写入结果文件并更新该技能的last_spec与last_spec_result字段。这也是 CCGS Skill Testing Framework/README.md Updating the catalog 一节描述的机制。五、实战从模板到一份完整规范的四步工作流根据 CCGS Skill Testing Framework/README.md 的 Writing a new spec 一节为技能编写行为规范的标准流程是找到模板CCGS Skill Testing Framework/templates/skill-test-spec.md或 .claude/docs/templates/skill-test-spec.md复制到skills/[category]/[skill-name].md按技能类别放入 gate/review/authoring/readiness/pipeline/analysis/team/sprint/utility 对应目录目录内已存在 72 个真实规范文件可作参照在catalog.yaml中更新该技能的spec:字段指向新文件运行/skill-test spec [skill-name]验证规范本身是否自洽。值得一提的是该框架是自包含且可选的README 声明游戏开发者可以rm -rf CCGS Skill Testing Framework完全移除它.claude/中没有任何内容依赖它移除后/skill-test与/skill-improve仍可运行只是会报告 catalog.yaml 缺失并建议先运行/skill-test audit初始化。六、规范质量的进阶杠杆category 评分与 skill-improve 闭环规范写得再好若技能实现与规范脱节也会在category模式暴露。以gate类别为例CCGS Skill Testing Framework/quality-rubric.md 定义 5 项 PASS/FAIL 指标G1 读取production/session-state/review-mode.txt决定 spawn 哪些 directorG2 full 模式下并行 spawn 全部 4 位 Tier-1 directorCD/TD/PR/AD 的 PHASE-GATEG3 lean 模式只跑*-PHASE-GATEG4 solo 模式不 spawn 任何 director 且逐条标注 skipped — Solo modeG5 未经用户确认绝不写入production/stage.txt。gate-check 规范的 Case 5Director Gate正是对这些指标的用例化表达——5a 验证 full 模式并行 spawn 全部 4 个 PHASE-GATE 且任一 director 的 CONCERNS 会传导到总体判定Verdict is NOT auto-PASS if any director returns CONCERNS or REJECT5b 验证 solo 模式输出[CD-PHASE-GATE] skipped — Solo mode且判定仅基于工件与质量检查。由此可见规范 Test Case、/skill-test spec的行为验证、/skill-test category的类别评分三者构成层层递进的质量防线。若技能在测试中失败/skill-improve [name]提供测试 → 诊断 → 提议修复 → 重测的闭环CCGS Skill Testing Framework/README.md并可手动或自动更新 catalog 中的last_static/last_static_result。七、编写规范时的十条实践准则综合模板要求、/skill-test实现与真实规范范例编写 Skill Test Spec 时应遵循Fixture 要具体到文件路径写清哪些文件存在、内容到什么程度避免有文档这种模糊描述Expected behavior 按阶段编号1) 读什么 → 2) 评估什么 → 3) 输出什么与技能自身的 Phase 结构对应断言可被推理裁决每条断言都应能根据技能指令 夹具状态明确判定 PASS/PARTIAL/FAIL避免表现良好这类不可判定表述失败路径必须断言不输出 PASS这是模板反复强调的核心防线写文件前必须断言 May I write任何含写入的技能都不可绕过协作协议不可自动验证的质量项必须断言为提问如[?] MANUAL CHECK NEEDED而非默认 PASS判定词清单与技能实际输出对齐否则/skill-test static的 Check 3 会失效用 Coverage Notes 显式声明不测范围及原因多模式技能为每个模式单独立用例参考 gate-check 的 5a/5b 拆分写完立即用/skill-test spec [name]自检并让规范与 catalog.yaml 的spec:、last_*字段保持同步。遵循这套规范CCGS 的 72 个技能才能在结构合规之外获得真正可验证的行为质量——这正是Turn Claude Code into a full game dev studio这一目标在质量保障维度上的落地基础。【免费下载链接】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（CCGS）技能行为测试规范编写指南：用 Skill Test Spec 为 72 个工作流技能建立可验收的质检标准
Claude Code Game StudiosCCGS技能行为测试规范编写指南用 Skill Test Spec 为 72 个工作流技能建立可验收的质检标准【免费下载链接】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中49 个 Agent 与 72 个工作流技能构成了完整的游戏研发流水线而质量保障的关键在于每一个技能都必须能被自动验证。.claude/docs/templates/skill-test-spec.md仓库内还有一份功能等价的副本 CCGS Skill Testing Framework/templates/skill-test-spec.md正是这套验证体系的契约文件模板——它为每个技能定义行为测试规范Behavioral Spec供/skill-test spec按规范逐条断言评估。读完本文你将掌握该模板的完整结构、每个字段的编写要求、与/skill-test四种运行模式的联动方式以及如何用真实示例如 gate-check 规范为任意技能写出可被机器逐条验收的测试规格。一、为什么需要 Skill Test Spec从看起来合规到行为正确CCGS 的技能文件SKILL.md本身是 Markdown 指令可以被静态检查frontmatter 是否齐全、是否有 ≥2 个阶段标题、是否包含判定词但静态合规不等于行为正确。一个技能可能结构完整却在缺少必需文件时依然输出 PASS、未征求用户同意就写文件等关键行为上出错。Skill Test Spec 的定位正是弥补这一缺口它是描述技能在给定项目状态下应当如何表现的行为契约由 .claude/skills/skill-test/SKILL.md 中的spec模式逐条读取并评估。该规范文件明确写道This is a Claude-evaluated reasoning check, not code execution.也就是说/skill-test spec不是运行被测试的技能代码而是通读技能指令与被测规范以推理方式判断技能在被测夹具fixture状态下按指令执行是否满足每一条断言。断言结果分为PASS明确满足、PARTIAL部分满足但存在歧义、FAIL给定夹具下不满足。这套设计让规范同时服务两个读者人编写时理清技能的预期行为边界和LLM 评估器/skill-test spec执行时逐条裁决。这也是该模板全文采用Fixture → Input → Expected behavior → Assertions四段式的原因——四者合起来构成一个可推理的最小行为场景。二、模板总览一份 Skill Test Spec 的五段式骨架模板 .claude/docs/templates/skill-test-spec.md 的结构如下章节作用谁消费它Skill Summary一段话说明技能做什么、何时用、产出什么、属于哪个流水线阶段人评审者、后续维护者Static Assertions (Structural)列出应通过/skill-test static的结构性断言无需夹具/skill-test static静态检查Test Cases23 个行为场景Happy Path / Failure Path / Edge Case每个含 Fixture、Input、Expected behavior、Assertions/skill-test spec行为验证Protocol Compliance协作协议合规清单May I write、先呈现再征批、结尾给出下一步/skill-test spec的协议段Coverage Notes记录刻意不测的内容及原因人避免后人误补或误以为遗漏配套的 CCGS Skill Testing Framework/templates/agent-test-spec.md 是 Agent 版本结构类似多了 Tier/Category 头、Domain/Escalates to/Delegates to、Out-of-Domain Redirect 与 Conflict Escalation 等用例本文聚焦技能版本。三、逐节编写指南3.1 Skill Summary一段话交代五个要素模板要求在一段话内说明这个技能做什么、何时使用、产出什么并包含主要产出工件、它使用的判定格式、以及它所属的流水线阶段。参考真实范例 CCGS Skill Testing Framework/skills/gate/gate-check.md 的写法/gate-checkvalidates whether the project is ready to advance to the next development phase. It checks for required artifacts, runs quality checks, asks the user about unverifiable items, and produces a PASS/CONCERNS/FAIL verdict. On PASS with user confirmation, it writes the new stage name toproduction/stage.txt. It governs all 6 phase transitions and is the most critical gate-keeping skill in the pipeline.注意这段摘要已经点出了判定格式PASS/CONCERNS/FAIL、写入工件production/stage.txt、所属定位6 个阶段转换的 gate 技能。规范的摘要写清楚了/skill-test spec的评估器才能据此校验后续用例的合理性。3.2 Static Assertions与/skill-test static的 7 项检查对齐模板的 Static Assertions 章节标注了由/skill-test static自动验证无需夹具。它对应的正是 .claude/skills/skill-test/SKILL.md 的 Phase 2A 中定义的 7 项检查Check 1 — Required Frontmatter Fieldsfrontmatter 必须含name、description、argument-hint、user-invocable、allowed-tools五个字段缺一即 FAILCheck 2 — Multiple Phases≥2 个阶段标题## Phase N、## N.或 ≥2 个##标题不足 2 个即 FAILCheck 3 — Verdict Keywords必须至少包含PASS、FAIL、CONCERNS、APPROVED、BLOCKED、COMPLETE、READY、COMPLIANT、NON-COMPLIANT之一一个都没有即 FAILCheck 4 — Collaborative Protocol Language要求先问再写的语言规范形式为May I write或before writing/approval邻近写文件指令、或ask与write同段共现。缺失时 WARN若allowed-tools含Write/Edit却无此类语言则直接 FAILCheck 5 — Next-Step Handoff结尾须有下一步建议如提到/story-done、/gate-check、Recommended next/Follow-Up 字样缺失时 WARNCheck 6 — Fork Context Complexity若 frontmatter 含context: fork则需 ≥5 个阶段标题fork 上下文专供复杂多阶段技能使用不足则 WARNCheck 7 — Argument Hint Plausibilityargument-hint不能为空且应与正文的多模式描述如 Mode A | Mode B及第一阶段Parse Arguments部分互相印证不匹配则 WARN。因此模板中Static Assertions的勾选项应直接映射到上述 7 项检查——特别是判定词清单应如实列出该技能真正会输出的词模板示例给出的PASS, FAIL, CONCERNS与 gate-check 一致。3.3 Test Cases三种场景的编写规范模板定义了三个用例模板每个用例统一包含Fixture假设的项目状态哪些文件存在、内容如何、Input/[skill-name] [args]、Expected behavior分阶段的预期动作、Assertions可勾选的断言清单四部分Case 1: Happy Path正常路径—— 描述一切就绪时技能应如何表现。以 gate-check 规范的真实写法为例Fixturedesign/gdd/game-concept.md存在且包含全部必需章节design/gdd/game-pillars.md存在尚无 systems index该阶段正确状态。Input/gate-check systems-designExpected behavior1) 读取game-concept.md并验证有内容2) 检查 game pillars3) 检查质量项核心循环已描述、目标受众已明确4) 输出结构化清单并逐项标记5) 给出 PASS/CONCERNS/FAIL 判定6) 若 PASS 则询问 May I updateproduction/stage.txtto Systems Design?Assertions技能必须先 Glob/Read 验证文件存在再标记为已检查输出含 Required Artifacts 与 Quality Checks 分区输出含 Verdict 行对无法自动验证的质量项应提问而非假定 PASS更新production/stage.txt前必须说 May I write未经用户确认不得写入。编写要点Happy Path 的断言应当验证技能确实读取了文件、输出了正确的分区与判定词、并在写文件前征求同意——也就是把技能是否走完了它自己承诺的流程全部显式化。Case 2: Failure Path失败路径—— 描述关键工件缺失时技能必须暴露缺口而非假装正常。gate-check 规范的对应场景是game-concept.md不存在、design/gdd/为空Expected behavior读取失败 → 将必需工件标记为缺失 → 输出 FAIL → 列出 blocker No game concept document found → 建议补救动作运行/brainstorm创建。Assertions缺失必需工件时判定必须是 FAIL而非 PASS 或 CONCERNS输出必须点名缺失的具体文件输出含至少 1 项 Blockers给出补救建议FAIL 时不得写入production/stage.txt。编写要点模板特别强调两条——Skill does NOT output PASS when the fixture is incomplete夹具不完整时绝不能输出 PASS和Skill does not create files to fill in the gap without asking不得未经询问就自行创建文件补缺。这对应 CCGS 的协作原则技能是顾问而非越权执行者。Case 3: Edge Case边界情况—— 模板给出的示例是无参数调用/[skill-name]。gate-check 规范将其扩展为无参数时自动探测当前阶段读取production/stage.txt推断当前阶段 → 确定下一个 gate → 直接执行对应检查且输出头必须同时标明当前与目标阶段如 Gate Check: Concept → Systems Design。该规范的 Note 还修正了一个常见误解技能在自动探测到转换后仍会用 AskUserQuestion 向用户确认这是确认步骤而非让用户选 gate断言不应将其视为失败——这个修正说明Edge Case 断言应区分询问确认与推卸决策两种不同行为。3.4 Protocol ComplianceCCGS 协作协议的验收清单模板的协议合规段是固定五条任何技能规范都应当保留所有文件写入前使用May I write先呈现发现/报告再请求写文件批准结尾给出推荐的下一步或后续技能未经用户明确批准绝不自动创建文件不跳过阶段、不未经检查直接跳到判定。在/skill-test spec的执行流程中见 .claude/skills/skill-test/SKILL.md Phase 2B Step 3这些协议断言是总是存在always present的固定检查项无论被测技能属于哪个类别。3.5 Coverage Notes主动声明不测什么模板用一个列表要求作者记录刻意不覆盖的场景及原因示例包括Case 3all 模式未覆盖因为它在单个 spec 中运行检查过多——应逐个测试每个子模式数据库集成路径未覆盖因为它需要真实环境损坏的 YAML 文件的边界情况推迟到未来的 spec。gate-check 规范的真实 Coverage Notes 提供了教科书式写法——它将 Production→Polish、Polish→Release 两个 gate 显式排除需要 sprint plans、playtest data、QA sign-off 等多工件环境将 CONCERNS 判定路径声明为介于 Case 1 与 Case 2 之间、遵循相同模式的过渡态并将 Vertical Slice 验证排除需要可玩构建无法用文档夹具表达。写 Coverage Notes 的价值在于让后来的维护者知道没测是深思熟虑的决定而不是疏漏避免误补破坏规范的边界。四、与/skill-test四种模式的协作关系编写规范的目的不是摆设而是被 .claude/skills/skill-test/SKILL.md 消费。该技能提供四种模式CCGS Skill Testing Framework/README.md 给出了对应命令模式命令与 Skill Test Spec 的关系static/skill-test static [name\|all]结构检查器验证规范的 Static Assertions 章节对应的 7 项检查无需夹具spec/skill-test spec [name]行为验证器读取技能 规范文件逐条评估每个 Test Case 与 Protocol Compliance 断言category/skill-test category [name\|all]类别评分按 CCGS Skill Testing Framework/quality-rubric.md 中该类别gate/review/authoring/…的 45 项指标评估audit/skill-test audit覆盖率报告列出所有技能与 Agent 的 has-spec、last tested、result在spec模式执行时规范文件的定位流程为技能位于.claude/skills/[name]/SKILL.md规范路径从 CCGS Skill Testing Framework/catalog.yaml 的spec:字段解析技能缺失、catalog 无 spec 路径、或规范文件不存在时分别输出明确的错误信息Skill [name] not found...、No spec path set...、Spec file missing at [path]. Run/skill-test auditto see coverage gaps.。spec模式结束后会询问May I write these results toCCGS Skill Testing Framework/results/skill-test-spec-[name]-[date].mdand updateCCGS Skill Testing Framework/catalog.yaml?——获批后写入结果文件并更新该技能的last_spec与last_spec_result字段。这也是 CCGS Skill Testing Framework/README.md Updating the catalog 一节描述的机制。五、实战从模板到一份完整规范的四步工作流根据 CCGS Skill Testing Framework/README.md 的 Writing a new spec 一节为技能编写行为规范的标准流程是找到模板CCGS Skill Testing Framework/templates/skill-test-spec.md或 .claude/docs/templates/skill-test-spec.md复制到skills/[category]/[skill-name].md按技能类别放入 gate/review/authoring/readiness/pipeline/analysis/team/sprint/utility 对应目录目录内已存在 72 个真实规范文件可作参照在catalog.yaml中更新该技能的spec:字段指向新文件运行/skill-test spec [skill-name]验证规范本身是否自洽。值得一提的是该框架是自包含且可选的README 声明游戏开发者可以rm -rf CCGS Skill Testing Framework完全移除它.claude/中没有任何内容依赖它移除后/skill-test与/skill-improve仍可运行只是会报告 catalog.yaml 缺失并建议先运行/skill-test audit初始化。六、规范质量的进阶杠杆category 评分与 skill-improve 闭环规范写得再好若技能实现与规范脱节也会在category模式暴露。以gate类别为例CCGS Skill Testing Framework/quality-rubric.md 定义 5 项 PASS/FAIL 指标G1 读取production/session-state/review-mode.txt决定 spawn 哪些 directorG2 full 模式下并行 spawn 全部 4 位 Tier-1 directorCD/TD/PR/AD 的 PHASE-GATEG3 lean 模式只跑*-PHASE-GATEG4 solo 模式不 spawn 任何 director 且逐条标注 skipped — Solo modeG5 未经用户确认绝不写入production/stage.txt。gate-check 规范的 Case 5Director Gate正是对这些指标的用例化表达——5a 验证 full 模式并行 spawn 全部 4 个 PHASE-GATE 且任一 director 的 CONCERNS 会传导到总体判定Verdict is NOT auto-PASS if any director returns CONCERNS or REJECT5b 验证 solo 模式输出[CD-PHASE-GATE] skipped — Solo mode且判定仅基于工件与质量检查。由此可见规范 Test Case、/skill-test spec的行为验证、/skill-test category的类别评分三者构成层层递进的质量防线。若技能在测试中失败/skill-improve [name]提供测试 → 诊断 → 提议修复 → 重测的闭环CCGS Skill Testing Framework/README.md并可手动或自动更新 catalog 中的last_static/last_static_result。七、编写规范时的十条实践准则综合模板要求、/skill-test实现与真实规范范例编写 Skill Test Spec 时应遵循Fixture 要具体到文件路径写清哪些文件存在、内容到什么程度避免有文档这种模糊描述Expected behavior 按阶段编号1) 读什么 → 2) 评估什么 → 3) 输出什么与技能自身的 Phase 结构对应断言可被推理裁决每条断言都应能根据技能指令 夹具状态明确判定 PASS/PARTIAL/FAIL避免表现良好这类不可判定表述失败路径必须断言不输出 PASS这是模板反复强调的核心防线写文件前必须断言 May I write任何含写入的技能都不可绕过协作协议不可自动验证的质量项必须断言为提问如[?] MANUAL CHECK NEEDED而非默认 PASS判定词清单与技能实际输出对齐否则/skill-test static的 Check 3 会失效用 Coverage Notes 显式声明不测范围及原因多模式技能为每个模式单独立用例参考 gate-check 的 5a/5b 拆分写完立即用/skill-test spec [name]自检并让规范与 catalog.yaml 的spec:、last_*字段保持同步。遵循这套规范CCGS 的 72 个技能才能在结构合规之外获得真正可验证的行为质量——这正是Turn Claude Code into a full game dev studio这一目标在质量保障维度上的落地基础。【免费下载链接】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），仅供参考