使用方法
- 复制安装命令，在自己的智能体环境安装前先检查源码包。
- 从原始文档核对所需工具、凭据和支持的宿主。
- 说明输入材料与期望交付物，并对照来源检查输出。
npx skills add https://github.com/zenstory-ai/novel-to-game --skill game-qa开始前需了解
- 安装不包含模型订阅、API 额度或访问文件的权限。
- 仓库星数和安装量反映活跃情况，不等于独立质量或安全测试。
仓库原始内容
按源仓库内容呈现，保留标题、案例、代码、表格、链接以及原文引用的演示图片。
游戏质量验证
验证当前候选能否完成最小可玩闭环，不把自动化结果包装成趣味、平衡、权利或发布质量结论。
读取 qa-contract.md 定判据，按 test-design-method.md 设计最少但有区分力的检查。
产物语言由 PRODUCT_BRIEF.md 锁定；未锁定时跟随对话语言，不默认产出中文。
唯一必需合同
每个候选都必须用真实运行证据覆盖：launch、render、input、coreLoop、outcome、restart。 targetFinish 描述成色，不改变这组六项，也不得生成第七道门。
执行
- 读取
targetRuntime、testedRuntime和权威 verify；与 PRODUCTBRIEF/BUILDBRIEF 冲突时先报错，
不由 QA 猜值。
- 运行权威 verify：它在 testedRuntime 从 clean start → 核心动作 → 设计结果 → restart
完成整条路径，并记录 command、exit code、环境、六项结果、最小证据和实际失败。
- 对照 GAME_DESIGN 中会改变结果的不变量和结束标记；只验证批准的设计承诺，不遍历所有
代码路径。
- 若候选有可执行模型、事件日志、patch 或
signature_command，按 test-design-method 的对应合同把
项目回归嵌入权威 verify；允许定向诊断、修复和复跑，最终六项证据必须来自同一次完整运行。 失败映射到已有 checks 或 limitation，不新增通用门禁。
- 记录 limitation 和问题的 product/design/art/build 归属。
优先使用已有可观察状态；只有无法判断结果时才增加最小测试钩子。不要为了 QA 重构游戏或强制某种 框架、测试库或调试接口。
输出
qa/verification.json：唯一 QA 事实源；字段与证据要求见 qa-contract.md。
缺口写结构化 limitation，不发明 PASS_WITH_GAPS；未运行或失败的必需项不能满足整体 PASS。
