Claude Code Game Studios/smoke-check技能深度解析实现到 QA 交接前的自动化冒烟测试关口【免费下载链接】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/smoke-check是 CCGSClaude Code Game Studios技能体系中负责实现 → QA 交接的关键路径关口技能它自动检测测试环境、经 Bash 运行引擎自动化测试套件、对照 sprint stories 扫描测试覆盖率并用AskUserQuestion分批与开发者确认人工冒烟项最终在用户批准后把报告写入production/qa/smoke-[date].md。读完本文你将掌握该技能的完整执行协议、PASS / PASS WITH WARNINGS / FAIL 三种判决的判定边界、五类测试场景的预期行为与断言以及在 Godot / Unity / Unreal 引擎项目中落地这一冒烟关口的实战方法。一、技能定位生产阶段 QA 周期中的硬性关口在 CCGS 的七阶段流水线中/smoke-check属于Phase 5 Production 阶段的每个 sprint QA 周期。根据 skill-flow-diagrams.md 中的 QA Pipeline 图示其位置是/qa-plan ─────► production/qa/qa-plan-sprint-NN.md │ ▼ /smoke-check │ ├── PASS → QA hand-off cleared └── FAIL → block sprint close → fix critical paths first │ ▼ /regression-suite → /test-evidence-review → /test-flakinessWORKFLOW-GUIDE.md 将其定位为 Critical path smoke test gate before QA hand-off预估消耗 5-6 步。它承接/qa-plan产出的测试计划把代码实现完成这一状态正式推向 QA 验收只有它返回 PASSsprint 才能继续走向/story-done关闭故事否则会阻塞 sprint close。与/team-qa的联动关系也值得注意/team-qa的 Phase 4smoke check是一个硬门FAIL 会直接停止整个 QA 循环且其失败处置会明确建议 re-run/smoke-check见 team-qa.md。也就是说/smoke-check既服务于单 sprint 的日常交接也是团队级全量 QA 流程的前置闸门。二、核心工作流五步完成冒烟检查/smoke-check的执行流程可归纳为五个阶段阶段动作关键工具/输入Phase 1检测测试环境查找tests/目录、从technical-preferences.md识别引擎、确认 QA 计划是否存在technical-preferences.md、production/qa/qa-plan-sprint-*.mdPhase 2经 Bash 运行自动化测试套件并解析输出引擎无头运行命令如godot --headless --script tests/gdunit4_runner.gdPhase 3扫描测试覆盖率核对每个 sprint story 是否有对应测试文件sprint 故事文件与tests/下测试文件Phase 4用AskUserQuestion分批次确认人工冒烟项Batch 1 核心稳定性、Batch 2 sprint 机制、Batch 3 附加项AskUserQuestionPhase 5组装报告 → 询问 May I write… → 批准后写入production/qa/smoke-[date].md→ 给出判决写文件权限关键约束必须先经 Bash 运行自动化测试再向开发者提出任何人工冒烟问题保证自动化证据先于主观确认。三、判决体系PASS / PASS WITH WARNINGS / FAIL三种判决的触发条件定义严格是协议合规检查Protocol Compliance的核心判决触发条件对流程的影响PASS自动化测试全部通过 所有人冒烟项通过 无 MISSING 覆盖率允许 QA hand-off可继续/story-donePASS WITH WARNINGS自动化测试通过或NOT RUN 所有关键检查通过但存在建议性缺口如部分故事缺少测试覆盖、引擎二进制不可用构建可交接 QA但缺口需在/story-done关闭受影响故事前解决FAIL任一自动化测试失败或 Batch 1 / Batch 2 冒烟项返回 FAIL阻塞 QA 交接提示修复后重跑/smoke-check两个重要的边界规则NOT RUN 不等于 FAIL当引擎二进制不在 PATH 上导致自动化测试无法执行时记为警告warning并按 PASS WITH WARNINGS 处理而不是直接 FAIL只有 FAIL 才触发强制阻断MISSING 覆盖率只构成警告Batch 3 的失败响应不会单独触发 FAILFAIL 仅由自动化测试失败或 Batch 1/Batch 2 的 FAIL 响应触发。FAIL 判决附带的标准提示语为The smoke check failed. Do not hand off to QA until these failures are resolved.并列出失败测试名、给出修复后重跑/smoke-check的建议。四、静态断言可自动验证的结构性要求/skill-test static可在无需 fixture 的情况下自动验证以下结构要求这五个检查项与 skill-test-spec.md 模板中的 Static Assertions 一脉相承具备全部必需 frontmatter 字段name、description、argument-hint、user-invocable、allowed-tools至少 2 个阶段标题phase headings包含判决关键词PASS、PASS WITH WARNINGS、FAIL在写报告前包含 May I write 协作协议用语末尾提供下一步交接指引FAIL 时指向/bug-reportPASS 时给出 QA 交接指引。五、五类测试场景详解Test Cases/smoke-check的规格文档针对五种典型场景给出了完整的 fixture、预期行为与断言这是验证技能实现是否合格的可执行契约。Case 1Happy Path —— 全绿放行PASSFixture 状态tests/目录存在且含 GDUnit4 运行脚本technical-preferences.md标记引擎为 Godotproduction/qa/qa-plan-sprint-005.md已存在自动化运行器报告 12 个测试全部通过12 passing, 0 failing开发者确认 Batch 1 与 Batch 2 全部 PASS所有 sprint stories 都有匹配测试文件。预期行为链检测测试目录与引擎确认 QA 计划存在经 Bash 运行godot --headless --script tests/gdunit4_runner.gd解析输出12/12 通过扫描覆盖率——所有 stories 为 COVERED 或 EXPECTED用AskUserQuestion询问 Batch 1核心稳定性与 Batch 2sprint 机制开发者全部选择 PASS组装报告自动化测试 PASS、冒烟项全 PASS、无 MISSING 覆盖率询问May I write this smoke check report toproduction/qa/smoke-[date].md?批准后写报告给出判决 PASS。断言自动化运行器必须经 Bash 调用人工冒烟必须走AskUserQuestion写文件前必须问 May I write报告写入production/qa/smoke-[date].md判决为 PASS。Case 2失败路径 —— 自动化测试失败即 FAILFixture 状态tests/存在、引擎为 Godot运行器报告 10 个测试中 8 通过、2 失败test_health_clamp_at_zero、test_damage_calculation_negativeQA 计划存在。预期行为链运行自动化测试 → 解析出 2 个失败 →记录失败测试名→ 仍走完人工冒烟批次 → 报告将自动化测试标记为 FAIL 并列出失败测试名 → 询问并写报告 → 给出 FAIL 判决及阻断提示建议修复后重跑/smoke-check。断言失败测试名必须出现在报告中判决为 FAIL判决后消息必须指引先修复再交接 QA必须建议重跑/smoke-check。Case 3人工确认 覆盖缺口 —— PASS WITH WARNINGSFixture 状态tests/存在、引擎为 Godot自动化测试 8/8 全过但某个 Logic story 没有匹配测试文件MISSING coverage开发者确认 Batch 1、Batch 2 全 PASS。预期行为链自动化测试 PASS → 覆盖率扫描发现 1 个 MISSINGLogic story→AskUserQuestion确认冒烟项全 PASS → 报告显示自动化测试 PASS、人工检查全 PASS、1 个 MISSING 覆盖率条目 → 判决为PASS WITH WARNINGS而非 PASS 或 FAIL并附建议说明构建可交 QA但该 MISSING 条目必须在/story-done关闭受影响故事前解决。断言人工冒烟必须用AskUserQuestion而非内联文本提示MISSING 条目必须出现在报告中判决必须是 PASS WITH WARNINGS建议性说明必须提到/story-done前置条件。Case 4无测试目录 —— 停止并给出补救指引Fixture 状态tests/目录不存在引擎配置为 Godot。预期行为Phase 1 检测不到tests/→ 输出No test directory found attests/. Run/test-setupto scaffold the testing infrastructure, or create the directory manually if tests live elsewhere.→技能立即停止不运行自动化测试、不做人工冒烟、不写报告。断言错误消息指明缺失的tests/目录建议/test-setup作为补救步骤技能在消息后停止不再执行后续阶段不写任何报告文件。Case 5导演关卡检查 —— 无门通过Fixture 状态测试环境合法、自动化测试通过、人工冒烟确认完成。预期行为技能跑完所有阶段并产出 PASS 或 PASS WITH WARNINGS全程不唤起任何 director agent输出中不出现任何 gate IDCD-*、TD-*、AD-*、PR-*不调用/gate-check。断言未调用任何导演关卡无 gate skip 消息判决只在 PASS / PASS WITH WARNINGS / FAIL 三选一与门控判决体系完全无关。六、协议合规要求协作协议是硬性约束规格文档将以下行为列为必须遵守的协议Protocol Compliance也是自动化断言的基础所有人工冒烟批次Batch 1、Batch 2、Batch 3一律使用AskUserQuestion禁止用内联文本提问先经 Bash 运行自动化测试再询问任何人工问题写报告文件前必须问 May I write未经批准绝不写入判决词汇严格限定为 PASS / PASS WITH WARNINGS / FAIL无其他判决FAIL 仅由自动化测试失败或 Batch 1/Batch 2 的 FAIL 响应触发PASS WITH WARNINGS 仅在存在 MISSING 测试覆盖但无关键失败时触发NOT RUN引擎二进制不可用记为警告而非 FAIL全程不调用导演关卡。这套协议与 skill-test-spec.md 模板中的通用 Protocol Compliance写前询问、先展示再请求批准、以推荐下一步收尾、未经批准不自动创建文件完全一致体现了 CCGS 对Agent 写文件必须经过用户授权这一协作原则的强制落地。七、变体与边界quick、--platform 与 NOT RUN规格文档的 Coverage Notes 明确声明了三类未单独 fixture 测试的变体其行为模式如下quick参数跳过 Phase 3 覆盖率扫描与 Batch 3其余流程与 Case 1 相同输出中会附带 coverage-skip 说明--platform参数追加平台专属的AskUserQuestion批次并生成按平台分列的判决表NOT RUN 场景引擎二进制不在 PATH 时按 PASS WITH WARNINGS 模式处理由上述协议合规断言覆盖。八、引擎无关性三种引擎下的运行命令虽然规格文档的用例以 Godot 为主 fixture但/smoke-check的引擎检测逻辑使其天然跨引擎工作。引擎选择在 Phase 4Pre-Production由/test-setup依据technical-preferences.md完成脚手架搭建见 test-setup.md引擎测试框架冒烟阶段运行命令Godot 4 GDScriptGdUnit4godot --headless --script tests/gdunit4_runner.gdUnity C#Unity Test RunnerTests/ asmdefEditMode/PlayModeUnity 无头批处理运行器Unreal EngineUnreal headless runner无头运行器-nullrhi参数/smoke-check只需读取检测到的引擎配置即可拼装对应的自动化测试命令若tests/缺失则回退到 Case 4 的停止-指引行为。这也解释了为什么 Case 1 的 fixture 中technical-preferences.md是关键输入——它是引擎检测的唯一权威来源。九、与周边技能的完整协同/smoke-check不是孤岛它处在一条完整的 QA 工具链中全部在 catalog.yaml 中注册为 utility 类别上游/qa-plan依据coding-standards.md的测试证据表为每个 story 分配测试类型Logic → 单元测试 BLOCKING、Config/Data → smoke check ADVISORY产出production/qa/qa-plan-sprint-NN.md供冒烟阶段核对/test-setup保证tests/基础设施就绪下游PASS 后进入/regression-suite覆盖缺口 回归测试清单、/test-evidence-review证据质量而非仅存在性、/test-flakinessflaky 测试报告最终由/story-done关闭故事FAIL 分支转/bug-report登记缺陷修复后重跑/smoke-check团队级/team-qa的 Phase 4 将 smoke check 作为硬门FAIL 时整个 QA 循环停止。十、如何验证与扩展这套规格/skill-test系列命令提供了验证入口/skill-test static在无 fixture 条件下验证静态断言frontmatter、阶段标题、判决关键词、协作协议、交接指引/skill-test spec则按本文第五节的测试用例逐一验证行为。若需新增变体场景如新的引擎、新的平台批次可参照本文结构在规格文档中追加 fixture 预期行为 断言三元组并同步更新 catalog.yaml 中对应条目。小结/smoke-check用一套可自动断言的规格把实现是否达到 QA 交接标准这一模糊判断变成了可重复、可验证、有人工兜底的工程协议自动化证据先行、人工冒烟分批确认、覆盖率缺口显式暴露、写文件全程征求授权、判决词汇严格三选一。无论你的 CCGS 项目运行在 Godot、Unity 还是 Unreal 上这套关口都能以同一套心智模型守住实现与 QA 之间的最后一道防线。【免费下载链接】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），仅供参考