SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场wtf.verify-task

wtf.verify-task

测试与质量

查看项目

更新于 10-16 02:15

技能介绍

Verify Task 以 QA 工程师的身份启动对一个已有任务的验证。

该技能将 Gherkin 场景作为可执行测试脚本使用。每个场景都是一个具体的测试用例，包含需要针对实现运行的 Given/When/Then 步骤。

开始前请阅读 references/qa-verdict-guide.md。其中定义了本技能全程使用的状态符号、判定选项以及预期 Test Mapping 表格格式。

用途

本技能用于让 QA 工程师测试或验证已完成的任务：运行验收标准，对照实现检查 Gherkin 场景。支持单个任务与整个功能特性两种验证范围。

主要能力

  • 识别验证范围：单任务或完整功能特性。
  • 单任务模式：从最近标记为 task 或 implemented 的开放问题中选择任务，沿任务→特性层级提取 Gherkin、契约、边界情况、Test Mapping、DoD（任务）以及用于额外探查场景的 AC/边界情况（特性）。
  • 完整功能特性模式：使用 gh sub-issue list <feature_number> 获取该特性下所有子问题作为权威任务列表；按 conflict-graph.md 中的文件冲突着色算法将任务划分为无冲突子阶段；每个子阶段为每个任务生成一个子代理（遵循 subagent-protocol.md），并行运行，子阶段按顺序执行；汇总为特性级摘要，包含任务总数与通过/失败/阻塞计数。
  • 加载 QA 引导文档 docs/steering/QA.md，并在整个会话中静默应用其测试策略、覆盖率阈值、完成定义和已知不稳定区域。
  • 建立测试面：从任务中提取并展示所有 Gherkin 场景、契约、边界情况与风险、可观测性需求。
  • 逐条走查 Gherkin 场景，将 Given/When/Then 用平实语言重述，并询问是否通过。
  • 探查边界情况，并验证可观测性（日志、指标、告警）。
  • 结果实时写入任务的 Test Mapping 表格，包含 Bug Filed 列。
  • 汇总并发布 QA 总结，给出明确判定：✅ 可合并 / ❌ 需修复 / ⚠️ 条件性通过。
  • 若判定为 ✅ 或 ⚠️，添加 verified 生命周期标签。

使用方式

  1. GitHub CLI 设置：运行 ../references/gh-setup.md 的第 1–2 步（安装检查与认证检查）。若 gh 未安装或未认证则停止。若本会话已由其他技能运行过 gh-setup 则跳过。

  2. 识别验证范围，通过 AskUserQuestion 询问："Are you verifying a single Task or a full Feature?"（Scope：Single Task / Full Feature）。单任务时询问具体任务；完整特性时询问具体特性。

  3. 加载 QA 引导文档：按 ../references/steering-doc-process.md 加载 docs/steering/QA.md（推荐技能 wtf.steer-qa）。

  4. 建立测试面：从任务中提取并展示所有 Gherkin 场景、契约、边界情况与风险、可观测性需求，并确认覆盖范围。

  5. 逐条走查 Gherkin 场景（一次一个）：

  • Yes ✅ → 在 Test Mapping 表中标记 ✅，Bug Filed 设为 —。
  • No ❌ → 询问实际发生了什么，记录复现步骤，询问是否立即提交 bug（立即提交则运行 wtf.report-bug）。
  • Blocked 🚫 → 询问阻塞原因。
  • N/A 或 Conditional ⚠️ → 询问是 N/A 还是仅在特定条件下通过。 每条场景记录后立即更新任务问题中的 Test Mapping 表，使用：
python3 .wtf/gh-body.py read <task_number>
python3 .wtf/gh-body.py edit <task_number> --body-file "<path-from-read>"

  1. 探查边界情况（来自任务及父特性的 Edge Case），逐条派生具体测试动作，结果同样更新到任务问题。

  2. 验证可观测性：逐项询问日志、指标、告警是否存在且正确，结果更新到任务问题的 Observability Results 部分。

  3. 最终确定结果并发布 QA 总结：完成对 DoD 清单的最终更新，发布 QA 总结评论，包含测试场景总数与通过/失败/条件性计数、含复现步骤的发现、条件性通过列表、明确判定。若判定为 ✅ 或 ⚠️，添加 verified 标签：

gh issue edit <task_number> --add-label "verified"

  1. 若判定为 ✅ 或 ⚠️，询问下一步：立即打开 PR（推荐，遵循 wtf.create-pr）或稍后处理。

  2. 对剩余未提交的失败项（Result 为 ❌ 且 Bug Filed 为 no）提供 bug 报告选项：分别提交（为每个失败场景并行生成子代理）、合并提交（运行一次 wtf.report-bug）或跳过。

问题关闭策略：已完成的工作仅通过包含 Closes #<n> 的已合并 PR 关闭为 completed。绝不使用 gh issue close <n> 关闭已完成工作。直接关闭仅保留给：gh issue close <n> --reason "not planned"（不实现）和 --reason "duplicate"（重复）。

适用场景

适用于 QA 工程师验证已完成的任务或整个功能特性，逐条运行验收标准与 Gherkin 场景，并跟踪通过/失败/阻塞状态与 bug 提交情况。

限制

  • 依赖 GitHub CLI（gh），需已安装并认证；未安装或未认证时停止。
  • 完整特性模式下，子代理无法按名称加载本技能，需在生成时读取 SKILL.md 并将第 3–9 步内联粘贴到子代理提示中。
  • 本技能的收费、价格、平台等具体信息暂未提供。