Team QA 是一个用于编排 QA 团队完成结构化测试周期的技能，主要面向游戏开发项目。
用途 该技能在调用后，会按照预设的流水线阶段组织 QA 团队执行完整测试周期，包括 QA 策略制定、测试计划生成、测试用例编写、手动 QA 执行和签核。它适用于需要系统化质量保证的游戏开发项目，尤其是使用 Claude Code 进行协作开发的场景。
主要能力
- 团队编排：通过 Agent 工具生成子代理，qa-lead 负责 QA 策略、测试计划、故事分类和签核报告；qa-tester 负责测试用例编写、缺陷报告和手动 QA 文档。
- 决策点管理：在每个阶段转换时，使用 AskUserQuestion 将子代理的建议作为可选项呈现给用户。支持协作模式（用户批准后推进）、引导模式（自动推进，除非阶段被阻塞）和自主模式（端到端运行，通过 log_decision 记录每个阶段结果）。automation_always_ask 类别中的决策始终会提示用户。
- 配置解析：通过 yaml-helper.sh 解析 review_mode、automation、team.size、qa.level 等配置。qa.level 决定 Logic、Integration 或 Config/Data 故事的证据要求；review_mode 设置导演门深度，但此流水线没有导演门；team.size 决定哪些代理处于活动状态。
- 团队规模：individual（默认）仅 qa-tester，qa-lead 仅在阶段门调用；small 为 qa-lead + qa-tester 流水线；studio 为 qa-lead + 每个故事生成 qa-tester + 签核。
- 阶段流程：Phase 0 解析配置；Phase 1 加载上下文（检测冲刺或功能范围、读取项目阶段、读取开放缺陷、统计故事数量）；Phase 2 QA 策略（qa-lead 审查故事、分类、识别自动化与手动测试需求、检查冒烟报告、生成策略摘要表）；Phase 3 测试计划生成（范围、分类表、自动化测试要求、手动 QA 范围、排除范围、进入和退出标准）；Phase 4 测试用例编写（qa-tester 为每个故事编写测试用例，输出到 production/qa/test-cases/[story-slug]-cases.md）；Phase 5 手动 QA 执行（批量故事，使用 AskUserQuestion 收集结果，失败时生成缺陷报告，通过时记录证据）。
- 冒烟检查：在 Phase 2 中检查现有冒烟报告，产生 PASS / PASS WITH WARNINGS / NOT ASSESSED / FAIL / UNKNOWN 判定。FAIL 时停止流程；UNKNOWN 时警告并谨慎继续；NOT ASSESSED 时说明未运行内容并谨慎继续。
- 开放缺陷跟踪：在 Phase 1 中读取 production/qa/bugs/*.md 中的开放缺陷，开放 S1 或 S2 缺陷会导致签核为 NOT APPROVED。
- 证据记录：在 Visual/Feel 或 UI 故事通过后，将截图证据记录到 production/qa/evidence/。
使用方式 调用该技能时，可以传入冲刺标识符（如 sprint-03）或功能标识（feature: [system-name]）。技能会解析配置、加载上下文、生成 QA 策略和测试计划，然后编写测试用例并执行手动 QA。用户需要在关键决策点通过 AskUserQuestion 进行选择。写入文件前需要用户批准，但子代理在特定条件下（路径已在提示中命名、新产物位于 production/、docs/ 或 tests/ 下、阶段为阶段门）可以无需单独批准直接写入。
适用场景 适用于游戏开发项目中的 QA 测试周期管理，特别是需要多代理协作、结构化测试计划和手动 QA 执行的场景。支持不同团队规模和自动化模式，可根据项目需求调整。
限制
- 该技能依赖 Claude Code 环境和相关配置文件（如 .claude/docs/automation-modes.md、.claude/docs/config-resolution.md、.claude/docs/coding-standards.md）。
- 冒烟检查 FAIL 时无法继续；UNKNOWN 或 NOT ASSESSED 时签核不能为 APPROVED。
- 开放 S1 或 S2 缺陷会导致签核为 NOT APPROVED。
- 测试用例和缺陷报告需要遵循特定格式，以便 /bug-triage 解析。
- 具体收费、价格、平台支持等信息暂未提供。