用途
wtf.steer-qa 用于在团队需要创建或完善 QA 标准文档时使用，例如“创建 QA 指导文档”“记录我们的测试标准”等场景。它生成或完善 docs/steering/QA.md，该文档是测试策略、覆盖率要求和测试模式的权威参考，同时定义每个实现者和 QA 工程师必须遵循的完成定义（Definition of Done）。
主要能力
- 生成或完善 QA 标准文档，路径为 docs/steering/QA.md。
- 遵循共享的 steering-doc 流程：存在性检查 → 调研 → 访谈 → 起草 → 评审 → 写入 → wiki 同步 → 继续。
- 使用技能专用输入：文档路径 docs/steering/QA.md、模板 references/qa-template.md、显示名称 / wiki 页面 WTF-QA.md、提交信息 docs: add QA standards steering document。
- 调研阶段通过 Agent 工具提取 QA 事实，不向用户询问可自行读取的内容，包括：测试框架（vitest.config.ts、jest.config.js、pytest.ini 等）、测试脚本（package.json 中的 test、test:watch、test:coverage）、覆盖率配置（测试配置文件中的覆盖率阈值）、测试文件约定（测试位置、命名模式如 .test.ts、.spec.ts、_test.go 等）、现有测试类型（单元、集成、e2e 及所用工具）、CI 配置（.github/workflows/ 中 PR 上运行的测试门禁）、CLAUDE.md 中已定义的测试规则、已知不稳定区域（skip、xit、@pytest.mark.skip 用法或测试中的 TODO 注释）。同时检查 docs/steering/TECH.md（若存在），提取其中已记录的测试相关约束。仅凭调研即可产出测试策略、测试模式和命令的具体草稿。
- 缺口主题访谈：仅询问调研无法确定的项目，对每个未回答项调用 AskUserQuestion，包括覆盖率阈值（问题：“可接受的最低测试覆盖率是多少？”）、完成定义（问题：“任何 trace 合并前必须满足什么条件？”）、测试环境（问题：“有哪些可用于测试的环境？（本地、预发、CI）”）、已知不稳定区域（问题：“是否存在已知会产生非确定性测试失败的领域？”）、Mock 策略（问题：“是否存在项目特定的、对‘仅在边界处 mock’规则的例外？”）。选项会从调研结果中预填。
- 写作规则：在写入任何持久正文前应用严格 STE（依据 ../references/ste-writing.md）；覆盖率阈值以强制最低值表述，而非目标；测试命令必须精确且与 CI 实际运行一致；若项目有 Gherkin 运行器（playwright-bdd、cucumber-js、behave 等），需在 Gherkin → Test Mapping 下命名，wtf.verify-trace 会读取该声明；完成定义项以复选框形式书写，具体且二元；已知不稳定区域需如实记录，不夸大，标记真实问题。
- 继续选项：创建 VISION.md（运行 wtf.steer-vision 记录产品愿景）、创建 TECH.md（运行 wtf.steer-tech 记录技术指南）、创建 DESIGN.md（运行 wtf.steer-design 记录设计指南）、或在此停止。
使用方式
该技能通过共享的 steering-doc 流程执行，具体步骤为：存在性检查 → 调研 → 访谈 → 起草 → 评审 → 写入 → wiki 同步 → 继续。调研阶段使用 Agent 工具自动提取项目中的 QA 事实；访谈阶段仅针对调研无法确定的缺口主题调用 AskUserQuestion；写作阶段遵循 STE 规范并应用上述写作规则。
适用场景
适用于团队需要创建或完善 QA 标准文档的场景，例如建立测试策略、定义覆盖率要求、规范测试模式、明确完成定义等。
限制
资料中未提供关于收费、价格、平台支持范围、具体效果或性能的说明。技能的具体安装命令、依赖版本要求等暂未提供。