Claude Code Game Studios /smoke-checkQA交接前的冒烟门禁如何跑自动测试、批量确认手工检查并给出三级裁决【免费下载链接】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 里/smoke-check是实现完成和可以交给 QA之间的一道门禁它通过 Bash 运行自动测试套件扫描当前 sprint 的测试覆盖缺口再用AskUserQuestion让开发者批量确认手工冒烟项最后生成一份 PASS / PASS WITH WARNINGS / FAIL 裁决的冒烟报告。这个 skill 的定位很明确——未通过冒烟检查的构建不进入 QA报告在获得你的明确批准后写入production/qa/smoke-[date].md[date]为技能按实际日期填充的文件名模式下同。本文基于 smoke-check SKILL.md 和 冒烟检查测试规格 说明一次完整运行的操作路径、判定依据和边界。冒烟门禁的位置与前置条件/smoke-check属于 QA 与测试命令组对应工作流第 5–6 阶段推荐链路是/qa-plan→/smoke-check→/regression-suite见 工作流指南 和 skill 流程图。运行前需要满足或确认以下前提Phase 1 会逐项探测并先输出一份环境摘要再进入后续阶段tests/测试目录存在。找不到时技能直接停止输出提示No test directory found attests/. Run/test-setupto scaffold the testing infrastructure, or create the directory manually if tests live elsewhere.——此时不跑自动测试、不做手工检查、不写报告。测试框架的脚手架由/test-setup负责创建tests/unit/、tests/integration/、tests/performance/、tests/playtest/及对应引擎的 runner 配置其测试规格见 test-setup 测试规格。引擎已配置Phase 1 读取.claude/docs/technical-preferences.md中的Engine:值用于 Phase 2 选择测试命令。引擎未配置时技能会提示先运行/setup-engine。CI 检查查看.github/workflows/是否包含引用 tests 的 workflow 文件并在报告中记录 CI 是否配置。QA 计划强烈建议但不强制globproduction/qa/qa-plan-*.md取最近修改的一份供 Phase 3 覆盖扫描和 Phase 4 冒烟项清单使用。找不到时技能提示 No QA plan found. Run/qa-plan sprintbefore smoke-checking for best results.QA 计划由/qa-plan生成规格见 qa-plan 测试规格。冒烟测试清单可选依次检查production/qa/smoke-tests.md或tests/smoke/都没有时 Phase 4 回退到内置标准清单。Phase 1 结束时会给出类似这样的环境报告文档原文格式Environment: [engine]. Test directory: [found / not found]. CI configured: [yes / no]. QA plan: [path / not found].运行命令与参数选择基础调用就是/smoke-check。参数可以组合例如/smoke-check sprint --platform console参数作用sprint默认针对当前 sprint 的 stories 做完整冒烟检查包含覆盖扫描quick跳过 Phase 3 覆盖扫描和 Batch 3 检查用于修复某个失败后的快速复检--platform pc追加 PC 平台检查键盘、鼠标、窗口模式--platform console追加主机平台检查手柄、TV 安全区、平台认证要求--platform mobile追加移动端检查触控、横竖屏、电池/发热表现--platform all追加全部平台变体Phase 5 额外输出按平台的裁决表日常主路径用/smoke-check即sprint模式如果你刚修完一个失败项想快速确认用/smoke-check quick。Phase 2自动测试如何被执行技能用 Bash 按检测到的引擎选择命令。这是文档中给出的真实命令可直接在你的游戏项目里对照Godot 4首选 runner 路径godot --headless --script tests/gdunit4_runner.gd 21该路径下 GDUnit4 runner 不存在时回退到godot --headless -s addons/gdunit4/GdUnitRunner.gd 21两条路径都找不到 runner 时技能提示 GDUnit4 runner not found — confirm the runner path for your test framework.。UnityUnity 测试大多需要编辑器无法在 shell 里 headless 运行。技能改为检查最近一次测试产物ls -t test-results/ 2/dev/null | head -5存在 XML/JSON 结果文件时读取最新一份解析 PASS/FAIL 计数没有产物时提示 Unity tests must be run from the editor or CI pipeline. Please confirm test status manually before proceeding.Unreal Enginels -t Saved/Logs/ 2/dev/null | grep -i test\|automation | head -5找不到匹配日志时提示 UE 自动化测试需通过 Session Frontend 或 CI 管线运行请手动确认状态。NOT RUN 的处理如果引擎二进制不在 PATH 或 runner 脚本缺失测试记为NOT RUN并明确报告原因。NOT RUN 不是自动 FAIL——它按警告记录技能会要求你在本地 IDE 或 CI 中确认测试结果未确认的 NOT RUN 最终导向 PASS WITH WARNINGS 而非 FAIL。runner 输出会被解析出总测试数、通过数、失败数、失败测试名最多列 10 个超过则记数量、以及 runner 自身的崩溃或错误输出。Phase 3测试覆盖扫描的五个状态sprint模式下技能按优先级取 story 清单QA 计划的 Test Summary 表 →production/sprints/中最近修改的 sprint 计划然后逐个 story 判定覆盖状态从 story 文件路径提取系统 slug如production/epics/combat/story-001.md→combat在tests/unit/[system]/和tests/integration/[system]/中查找文件名包含 story slug 或相关词的测试文件检查 story 文件本身的Test file:头字段或 Test Evidence 小节。状态含义COVERED找到与该 story 系统和范围匹配的测试文件MANUALstory 类型为 Visual/Feel 或 UI且存在测试证据文档MISSINGLogic 或 Integration story 没有匹配测试文件EXPECTEDConfig/Data story——不需要测试文件抽查即可UNKNOWNstory 文件缺失或不可读MISSING 属于建议性缺口它不会触发 FAIL 裁决但必须在报告中显著标出且在/story-done完全关闭对应 story 之前必须解决。quick模式会跳过整个 Phase 3 并在输出中注明 Coverage scan skipped — run/smoke-check sprintfor full coverage analysis.Phase 4用 AskUserQuestion 批量确认手工检查冒烟项清单的来源按优先级QA 计划的 Smoke Test Scope 小节 →production/qa/smoke-tests.md→tests/smoke/目录 → 内置标准回退清单。技能最多发起3 次AskUserQuestion调用Batch 2 的占位项会替换成当前 sprint story 里的真实机制名。文档给出的选项结构如下文档示例方括号内容为运行时替换项Batch 1 — 核心稳定性始终执行question: Smoke check — Batch 1: Core stability. Please verify each: options: - Game launches to main menu without crash — PASS - Game launches to main menu without crash — FAIL - New game / session starts successfully — PASS - New game / session starts successfully — FAIL - Main menu responds to all inputs — PASS - Main menu responds to all inputs — FAILBatch 2 — 本 sprint 机制与回归始终执行选项形如 [Primary mechanic this sprint] — PASS / …FAIL: [describe what broke]以及 Previous sprints features still work (no regressions) — PASS。Batch 3 — 数据完整性与性能quick模式除外存档/读档是否丢数据、是否观察到新的掉帧或卡顿各提供 PASS / FAIL / N/A未检查选项。传入--platform时Phase 4 追加对应平台批次PC 的键鼠与窗口/分辨率、Console 的手柄/安全区/冷启动、Mobile 的触控/旋转切换/前后台切换每个选项同样分 PASS 与 FAIL 两态。每条回答会原样记录进 Phase 5 报告。Phase 5–6报告生成、写入批准与三级裁决Phase 5 组装完整报告包含这些章节Automated Tests状态行 失败测试列表或 NOT RUN 说明、Test Coverage 表story / 类型 / 测试文件 / 状态 汇总计数、Manual Smoke Checks逐项勾选及原话记录、Missing Test Evidence/story-done前必须补齐的 story 清单及预期测试文件位置如tests/unit/[system]/[story-slug]_test.[ext]传入--platform时还有一张 Platform-Specific Results 表。裁决规则第一条命中的规则生效裁决条件FAIL任一命中自动测试运行且报告了失败任一 Batch 1核心稳定性检查 FAIL任一 Batch 2sprint 主机制或回归检查 FAILPASS WITH WARNINGS全部满足自动测试 PASS 或 NOT RUN未确认Batch 1 和 Batch 2 全部 PASS存在一个或多个 Logic/Integration story 的 MISSING 测试证据PASS全部满足自动测试 PASS所有批次冒烟检查 PASS 或 N/A无 MISSING 测试证据Phase 6 先在会话中展示完整报告然后询问 May I write this smoke check report toproduction/qa/smoke-[date].md?——未经批准绝不写文件。写入后交付对应裁决的门禁结论FAILThe smoke check failed. Do not hand off to QA until these failures are resolved. 逐条列出失败的自动测试或冒烟项并提示修复后重新运行/smoke-check再走门禁。PASS WITH WARNINGS构建可以进入手工 QA但报告列出的 MISSING 测试证据项要在对受影响 story 运行/story-done之前解决交接方式是分享production/qa/qa-plan-[sprint].md给 qa-tester agent 开始手工验证。PASS干净通过同样分享 QA 计划给 qa-tester agent 开始手工验证。测试规格中的三个行为用例也印证了这条判定链Godot 环境下 12/12 测试通过且手工项全确认时裁决为 PASS8 通过 2 失败时报告列出失败测试名并裁决 FAIL测试全过但有一个 Logic story 无匹配测试文件时裁决为 PASS WITH WARNINGS。结果怎么判断以及边界一次运行完成后你实际要核对的是三样东西会话中的裁决行只能是 PASS / PASS WITH WARNINGS / FAIL 三种之一、经批准写入的production/qa/smoke-[date].md报告、以及报告里 Test Coverage 表的 MISSING 计数与 Manual Smoke Checks 的逐项记录。裁决告诉你能否交接FAIL 不交接先修后重跑另外两种都可以把 QA 计划交给 qa-tester agent 开始手工验证区别只在于 PASS WITH WARNINGS 把 MISSING 缺口记成了/story-done的前置义务。几个文档明确的限制技能不会自动修复失败——只报告并说明必须解决什么不编辑源码或测试文件/smoke-check是 QA 前置工具不调用任何 director agent输出中不应出现 CD-*/TD-*/AD-*/PR-* 门禁 ID也不调用/gate-checkNOT RUN 永不自动判 FAIL其最终走向取决于你在 Phase 4 前的手动确认FAIL 消息中的 do not hand off to QA 是该 skill 自己的门禁规则项目里 QA 交接的正式链路仍按/qa-plan→/smoke-check→/regression-suite推进通过后 story 的关闭交给/story-done。下一步在源文档中有明确指向修复失败项后重跑/smoke-check复检可用quick加速通过后按交接说明分享production/qa/qa-plan-[sprint].md给 qa-tester agent 开始手工验证。【免费下载链接】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 /smoke-checkQA交接前的冒烟门禁如何跑自动测试、批量确认手工检查并给出三级裁决【免费下载链接】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 里/smoke-check是实现完成和可以交给 QA之间的一道门禁它通过 Bash 运行自动测试套件扫描当前 sprint 的测试覆盖缺口再用AskUserQuestion让开发者批量确认手工冒烟项最后生成一份 PASS / PASS WITH WARNINGS / FAIL 裁决的冒烟报告。这个 skill 的定位很明确——未通过冒烟检查的构建不进入 QA报告在获得你的明确批准后写入production/qa/smoke-[date].md[date]为技能按实际日期填充的文件名模式下同。本文基于 smoke-check SKILL.md 和 冒烟检查测试规格 说明一次完整运行的操作路径、判定依据和边界。冒烟门禁的位置与前置条件/smoke-check属于 QA 与测试命令组对应工作流第 5–6 阶段推荐链路是/qa-plan→/smoke-check→/regression-suite见 工作流指南 和 skill 流程图。运行前需要满足或确认以下前提Phase 1 会逐项探测并先输出一份环境摘要再进入后续阶段tests/测试目录存在。找不到时技能直接停止输出提示No test directory found attests/. Run/test-setupto scaffold the testing infrastructure, or create the directory manually if tests live elsewhere.——此时不跑自动测试、不做手工检查、不写报告。测试框架的脚手架由/test-setup负责创建tests/unit/、tests/integration/、tests/performance/、tests/playtest/及对应引擎的 runner 配置其测试规格见 test-setup 测试规格。引擎已配置Phase 1 读取.claude/docs/technical-preferences.md中的Engine:值用于 Phase 2 选择测试命令。引擎未配置时技能会提示先运行/setup-engine。CI 检查查看.github/workflows/是否包含引用 tests 的 workflow 文件并在报告中记录 CI 是否配置。QA 计划强烈建议但不强制globproduction/qa/qa-plan-*.md取最近修改的一份供 Phase 3 覆盖扫描和 Phase 4 冒烟项清单使用。找不到时技能提示 No QA plan found. Run/qa-plan sprintbefore smoke-checking for best results.QA 计划由/qa-plan生成规格见 qa-plan 测试规格。冒烟测试清单可选依次检查production/qa/smoke-tests.md或tests/smoke/都没有时 Phase 4 回退到内置标准清单。Phase 1 结束时会给出类似这样的环境报告文档原文格式Environment: [engine]. Test directory: [found / not found]. CI configured: [yes / no]. QA plan: [path / not found].运行命令与参数选择基础调用就是/smoke-check。参数可以组合例如/smoke-check sprint --platform console参数作用sprint默认针对当前 sprint 的 stories 做完整冒烟检查包含覆盖扫描quick跳过 Phase 3 覆盖扫描和 Batch 3 检查用于修复某个失败后的快速复检--platform pc追加 PC 平台检查键盘、鼠标、窗口模式--platform console追加主机平台检查手柄、TV 安全区、平台认证要求--platform mobile追加移动端检查触控、横竖屏、电池/发热表现--platform all追加全部平台变体Phase 5 额外输出按平台的裁决表日常主路径用/smoke-check即sprint模式如果你刚修完一个失败项想快速确认用/smoke-check quick。Phase 2自动测试如何被执行技能用 Bash 按检测到的引擎选择命令。这是文档中给出的真实命令可直接在你的游戏项目里对照Godot 4首选 runner 路径godot --headless --script tests/gdunit4_runner.gd 21该路径下 GDUnit4 runner 不存在时回退到godot --headless -s addons/gdunit4/GdUnitRunner.gd 21两条路径都找不到 runner 时技能提示 GDUnit4 runner not found — confirm the runner path for your test framework.。UnityUnity 测试大多需要编辑器无法在 shell 里 headless 运行。技能改为检查最近一次测试产物ls -t test-results/ 2/dev/null | head -5存在 XML/JSON 结果文件时读取最新一份解析 PASS/FAIL 计数没有产物时提示 Unity tests must be run from the editor or CI pipeline. Please confirm test status manually before proceeding.Unreal Enginels -t Saved/Logs/ 2/dev/null | grep -i test\|automation | head -5找不到匹配日志时提示 UE 自动化测试需通过 Session Frontend 或 CI 管线运行请手动确认状态。NOT RUN 的处理如果引擎二进制不在 PATH 或 runner 脚本缺失测试记为NOT RUN并明确报告原因。NOT RUN 不是自动 FAIL——它按警告记录技能会要求你在本地 IDE 或 CI 中确认测试结果未确认的 NOT RUN 最终导向 PASS WITH WARNINGS 而非 FAIL。runner 输出会被解析出总测试数、通过数、失败数、失败测试名最多列 10 个超过则记数量、以及 runner 自身的崩溃或错误输出。Phase 3测试覆盖扫描的五个状态sprint模式下技能按优先级取 story 清单QA 计划的 Test Summary 表 →production/sprints/中最近修改的 sprint 计划然后逐个 story 判定覆盖状态从 story 文件路径提取系统 slug如production/epics/combat/story-001.md→combat在tests/unit/[system]/和tests/integration/[system]/中查找文件名包含 story slug 或相关词的测试文件检查 story 文件本身的Test file:头字段或 Test Evidence 小节。状态含义COVERED找到与该 story 系统和范围匹配的测试文件MANUALstory 类型为 Visual/Feel 或 UI且存在测试证据文档MISSINGLogic 或 Integration story 没有匹配测试文件EXPECTEDConfig/Data story——不需要测试文件抽查即可UNKNOWNstory 文件缺失或不可读MISSING 属于建议性缺口它不会触发 FAIL 裁决但必须在报告中显著标出且在/story-done完全关闭对应 story 之前必须解决。quick模式会跳过整个 Phase 3 并在输出中注明 Coverage scan skipped — run/smoke-check sprintfor full coverage analysis.Phase 4用 AskUserQuestion 批量确认手工检查冒烟项清单的来源按优先级QA 计划的 Smoke Test Scope 小节 →production/qa/smoke-tests.md→tests/smoke/目录 → 内置标准回退清单。技能最多发起3 次AskUserQuestion调用Batch 2 的占位项会替换成当前 sprint story 里的真实机制名。文档给出的选项结构如下文档示例方括号内容为运行时替换项Batch 1 — 核心稳定性始终执行question: Smoke check — Batch 1: Core stability. Please verify each: options: - Game launches to main menu without crash — PASS - Game launches to main menu without crash — FAIL - New game / session starts successfully — PASS - New game / session starts successfully — FAIL - Main menu responds to all inputs — PASS - Main menu responds to all inputs — FAILBatch 2 — 本 sprint 机制与回归始终执行选项形如 [Primary mechanic this sprint] — PASS / …FAIL: [describe what broke]以及 Previous sprints features still work (no regressions) — PASS。Batch 3 — 数据完整性与性能quick模式除外存档/读档是否丢数据、是否观察到新的掉帧或卡顿各提供 PASS / FAIL / N/A未检查选项。传入--platform时Phase 4 追加对应平台批次PC 的键鼠与窗口/分辨率、Console 的手柄/安全区/冷启动、Mobile 的触控/旋转切换/前后台切换每个选项同样分 PASS 与 FAIL 两态。每条回答会原样记录进 Phase 5 报告。Phase 5–6报告生成、写入批准与三级裁决Phase 5 组装完整报告包含这些章节Automated Tests状态行 失败测试列表或 NOT RUN 说明、Test Coverage 表story / 类型 / 测试文件 / 状态 汇总计数、Manual Smoke Checks逐项勾选及原话记录、Missing Test Evidence/story-done前必须补齐的 story 清单及预期测试文件位置如tests/unit/[system]/[story-slug]_test.[ext]传入--platform时还有一张 Platform-Specific Results 表。裁决规则第一条命中的规则生效裁决条件FAIL任一命中自动测试运行且报告了失败任一 Batch 1核心稳定性检查 FAIL任一 Batch 2sprint 主机制或回归检查 FAILPASS WITH WARNINGS全部满足自动测试 PASS 或 NOT RUN未确认Batch 1 和 Batch 2 全部 PASS存在一个或多个 Logic/Integration story 的 MISSING 测试证据PASS全部满足自动测试 PASS所有批次冒烟检查 PASS 或 N/A无 MISSING 测试证据Phase 6 先在会话中展示完整报告然后询问 May I write this smoke check report toproduction/qa/smoke-[date].md?——未经批准绝不写文件。写入后交付对应裁决的门禁结论FAILThe smoke check failed. Do not hand off to QA until these failures are resolved. 逐条列出失败的自动测试或冒烟项并提示修复后重新运行/smoke-check再走门禁。PASS WITH WARNINGS构建可以进入手工 QA但报告列出的 MISSING 测试证据项要在对受影响 story 运行/story-done之前解决交接方式是分享production/qa/qa-plan-[sprint].md给 qa-tester agent 开始手工验证。PASS干净通过同样分享 QA 计划给 qa-tester agent 开始手工验证。测试规格中的三个行为用例也印证了这条判定链Godot 环境下 12/12 测试通过且手工项全确认时裁决为 PASS8 通过 2 失败时报告列出失败测试名并裁决 FAIL测试全过但有一个 Logic story 无匹配测试文件时裁决为 PASS WITH WARNINGS。结果怎么判断以及边界一次运行完成后你实际要核对的是三样东西会话中的裁决行只能是 PASS / PASS WITH WARNINGS / FAIL 三种之一、经批准写入的production/qa/smoke-[date].md报告、以及报告里 Test Coverage 表的 MISSING 计数与 Manual Smoke Checks 的逐项记录。裁决告诉你能否交接FAIL 不交接先修后重跑另外两种都可以把 QA 计划交给 qa-tester agent 开始手工验证区别只在于 PASS WITH WARNINGS 把 MISSING 缺口记成了/story-done的前置义务。几个文档明确的限制技能不会自动修复失败——只报告并说明必须解决什么不编辑源码或测试文件/smoke-check是 QA 前置工具不调用任何 director agent输出中不应出现 CD-*/TD-*/AD-*/PR-* 门禁 ID也不调用/gate-checkNOT RUN 永不自动判 FAIL其最终走向取决于你在 Phase 4 前的手动确认FAIL 消息中的 do not hand off to QA 是该 skill 自己的门禁规则项目里 QA 交接的正式链路仍按/qa-plan→/smoke-check→/regression-suite推进通过后 story 的关闭交给/story-done。下一步在源文档中有明确指向修复失败项后重跑/smoke-check复检可用quick加速通过后按交接说明分享production/qa/qa-plan-[sprint].md给 qa-tester agent 开始手工验证。【免费下载链接】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），仅供参考
