wtf.verify-task

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Verify Task

验证任务

Pick up an existing Task as a QA engineer. Core value: uses the Gherkin scenarios as the executable test script — each scenario is a concrete test case with Given/When/Then steps to run against the implementation.

Read

references/qa-verdict-guide.md

before starting — it defines the status symbols, verdict options, and the expected Test Mapping table format used throughout this skill.

以QA工程师的身份接手一项已有的任务。核心价值：将Gherkin场景作为可执行测试脚本——每个场景都是包含Given/When/Then步骤的具体测试用例，可对照实现运行。

开始前请阅读

references/qa-verdict-guide.md

——该文档定义了本Skill全程使用的状态符号、 verdict选项以及预期的测试映射表格式。

Process

流程

0. GitHub CLI setup

0. GitHub CLI 设置

Run steps 1–2 of

../references/gh-setup.md

(install check and auth check). Stop if

gh

is not installed or not authenticated. Extensions are not required for this skill.

Skip this step if invoked from

implement-task

or another skill that already ran gh-setup this session.

执行

../references/gh-setup.md

中的步骤1–2（安装检查和授权检查）。如果

gh

未安装或未完成授权，请停止操作。本Skill不需要扩展。

如果是从

implement-task

或其他已在本次会话中运行过gh-setup的Skill调用，则跳过此步骤。

1. Identify the verification scope

1. 确定验证范围

Call

AskUserQuestion

with:

```
question
```
: "Are you verifying a single Task or a full Feature?"
```
header
```
: "Scope"

options

[{label: "Single Task", description: "Verify one Task's Gherkin scenarios"}, {label: "Full Feature", description: "Verify all Tasks under a Feature using its sub-issues"}]

If Single Task:

Search for recent open issues with labels

task

implemented

to populate options. Call

AskUserQuestion

with

question: "Which Task are you testing?"

header: "Task"

, and

options

pre-filled with 1–2 likely open Task issue references.

Fetch the Task first, extract the Feature number from its Context section, then fetch the Feature:

bash

gh issue view <task_number>    # Gherkin, Contracts, Edge Cases, Test Mapping, DoD — also yields feature number

调用

AskUserQuestion

，参数如下：

```
question
```
: "你要验证单个Task还是完整Feature？"
```
header
```
: "范围"

options

[{label: "单个Task", description: "验证一个Task的Gherkin场景"}, {label: "完整Feature", description: "使用子工单验证某个Feature下的所有Task"}]

如果选择单个Task：

搜索带有

task

或

implemented

标签的近期未关闭工单来填充选项。调用

AskUserQuestion

，参数为

question: "你要测试哪个Task？"

，

header: "Task"

，且

options

预填充1–2个可能的未关闭Task工单引用。

先获取该Task，从其Context部分提取Feature编号，然后获取对应的Feature：

bash

gh issue view <task_number>    # 获取Gherkin、契约、边缘案例、测试映射、DoD——同时得到Feature编号

Extract feature number, then:

提取Feature编号后执行：

gh issue view <feature_number> # ACs, edge cases for additional probe scenarios


Check task labels. If `implemented` is **absent**, warn and call `AskUserQuestion` with:

- `question`: "This task hasn't been implemented yet. How would you like to proceed?"
- `header`: "Implement first?"
- `options`: `[{label: "Implement first", description: "Go back and run wtf:implement-task (default)"}, {label: "Verify anyway", description: "Skip and proceed with verification"}]`

- **Implement first** → follow the `wtf:implement-task` process, passing the Task number in as context.
- **Verify anyway** → proceed.

**If Full Feature:**

Call `AskUserQuestion` with `question: "Which Feature are you verifying?"`, `header: "Feature"`, and `options` pre-filled from open feature issues.

Fetch all sub-issues of the Feature using the extension:

```bash
gh sub-issue list <feature_number>

This returns the authoritative list of Tasks — do not search by label or title matching. Spawn one sub-agent per Task in parallel using the Agent tool with

isolation: "worktree"

, each running steps 3–9 independently. Pass the task number and feature context to each sub-agent so it does not need to re-fetch. Wait for all sub-agents to complete, then aggregate results into a feature-level summary (total tasks, pass/fail/blocked counts) and present it.

gh issue view <feature_number> # 获取验收标准、边缘案例以补充测试场景


检查Task的标签。如果**没有**`implemented`标签，发出警告并调用`AskUserQuestion`，参数如下：

- `question`: "这个任务尚未完成开发。你想如何继续？"
- `header`: "先开发？"
- `options`: `[{label: "先开发", description: "返回并执行wtf:implement-task（默认选项）"}, {label: "直接验证", description: "跳过开发步骤继续验证"}]`

- **先开发** → 遵循`wtf:implement-task`流程，传入Task编号作为上下文。
- **直接验证** → 继续执行后续步骤。

**如果选择完整Feature：**

调用`AskUserQuestion`，参数为`question: "你要验证哪个Feature？"`，`header: "Feature"`，且`options`预填充未关闭的Feature工单。

使用扩展工具获取该Feature的所有子工单：

```bash
gh sub-issue list <feature_number>

返回的结果是Task的权威列表——请勿通过标签或标题匹配进行搜索。使用Agent工具为每个Task并行生成一个子Agent，设置

isolation: "worktree"

，每个子Agent独立执行步骤3–9。将Task编号和Feature上下文传递给每个子Agent，避免重复获取。等待所有子Agent完成后，将结果汇总为Feature级别的总结（总Task数、通过/失败/阻塞数量）并展示。

2. Load the QA steering document

2. 加载QA指导文档

Use the Read tool to attempt reading

docs/steering/QA.md

If the file exists: keep its content in context. Use its test strategy, coverage thresholds, definition of done, and known flaky areas to inform every verification decision in this session. Do not surface it to the user — just apply it silently.

If the file does not exist, call

AskUserQuestion

with:

```
question
```
: "docs/steering/QA.md doesn't exist yet. This document captures your test strategy, coverage thresholds, and definition of done. Would you like to create it now?"
```
header
```
: "QA steering doc missing"

options

[{label: "Create it now", description: "Run

steer-qa

 before continuing (recommended)"}, {label: "Skip for this session", description: "Continue without it — QA decisions won't reference project standards"}]

Create it now → follow the
```
steer-qa
```
process, then return to this skill and continue from step 3.
Skip for this session → continue without it.

使用Read工具尝试读取

docs/steering/QA.md

。

如果文件存在：将其内容保留在上下文中。使用其中的测试策略、覆盖阈值、完成定义以及已知不稳定区域来指导本次会话中的所有验证决策。无需向用户展示该文档内容，只需静默应用即可。

如果文件不存在，调用

AskUserQuestion

，参数如下：

```
question
```
: "docs/steering/QA.md 不存在。该文档记录你的测试策略、覆盖阈值和完成定义。你现在想要创建它吗？"
```
header
```
: "缺失QA指导文档"

options

[{label: "现在创建", description: "先执行

steer-qa

再继续（推荐）"}, {label: "本次会话跳过", description: "继续执行——QA决策不会参考项目标准"}]

现在创建 → 遵循
```
steer-qa
```
流程，完成后返回本Skill并从步骤3继续。
本次会话跳过 → 继续执行后续步骤。

3. Establish the test surface

3. 确定测试范围

From the Task, extract and present:

All Gherkin scenarios (these are the test cases)
The contracts (request/response schemas to verify against)
Edge Cases & Risks (additional scenarios to probe)
Observability requirements (logs, metrics, alerts to verify)

Call

AskUserQuestion

with

question: "I found [n] Gherkin scenarios and [m] edge cases to cover. Does this match what you expect?"

(replace [n] and [m] with actual counts),

header: "Test surface"

, and

options: [{label: "Yes — that's everything", description: "Proceed to testing"}, {label: "There are more scenarios", description: "I want to add some"}]

从Task中提取并展示：

所有Gherkin场景（即测试用例）
契约（需要验证的请求/响应 schema）
边缘案例与风险（需要额外测试的场景）
可观测性要求（需要验证的日志、指标、告警）

调用

AskUserQuestion

，参数为

question: "我找到了[n]个Gherkin场景和[m]个边缘案例需要覆盖。这符合你的预期吗？"

（将[n]和[m]替换为实际数量），

header: "测试范围"

，

options: [{label: "是的——全部涵盖", description: "开始测试"}, {label: "还有更多场景", description: "我想要添加一些"}]

。

4. Walk through each Gherkin scenario

4. 逐一执行Gherkin场景

For each scenario, one at a time:

Present it as a concrete test case — restate the Given/When/Then in plain language.

Call

AskUserQuestion

with:

```
question
```
: "Did this scenario pass?"
```
header
```
: "Result"

options

[{label: "Yes ✅", description: "Scenario passed"}, {label: "No ❌", description: "Scenario failed"}, {label: "Blocked 🚫", description: "Could not test due to dependency or environment issue"}, {label: "N/A or Conditional ⚠️", description: "Not applicable, or passes only under a specific condition"}]

Yes ✅ → mark ✅ in the running Test Mapping table. Set
```
bug filed
```
to
```
—
```
.

No ❌ → call

AskUserQuestion

with

question: "What actually happened?"

header: "Failure details"

, and

options

pre-filled with 1–2 plausible failure modes inferred from the scenario (e.g. "No error shown", "Wrong data returned"). Record findings with repro steps. Then call

AskUserQuestion

with

question: "Would you like to file a bug report now?"

header: "File bug?"

options: [{label: "File now", description: "Run

report-bug

 immediately (default)"}, {label: "Continue and file later", description: "Defer and move to the next scenario"}]

— if "File now", follow the

report-bug

process immediately with the task number and scenario details before moving on. Mark

bug filed

yes

(filed now) or

no

(deferred). Set

bug filed

accordingly.

Blocked 🚫 → call
```
AskUserQuestion
```
with
```
question: "What dependency or environment issue prevented testing?"
```
,
```
header: "Blocker"
```
, and
```
options
```
pre-filled with common blockers inferred from the task context (e.g. "Missing test environment", "Depends on unmerged task"). Set
```
bug filed
```
to
```
—
```
.

N/A or Conditional ⚠️ → call

AskUserQuestion

with

question: "Is this N/A, or does it pass only under a condition?"

header: "Condition"

, and

options: [{label: "N/A — not applicable", description: "This scenario does not apply"}, {label: "Conditional — specify the condition", description: "Passes only under a specific circumstance"}]

. Record appropriately. Set

bug filed

—

(track the condition separately).

After recording the result, immediately update the Task issue with the current state of the Test Mapping table (do not wait until all scenarios are done). The table must include a
```
Bug Filed
```
column:
The running Test Mapping table format (update after every scenario):
Scenario Result Bug Filed
<scenario name>
✅/❌/🚫/N/A/⚠️ yes / no / —
bash
```
gh issue view <task_number> --json body -q .body > /tmp/updated-task-body.md
```
Programmatically replace the Test Mapping table section in
```
/tmp/updated-task-body.md
```
using the Write or Edit tool, preserving all other sections unchanged. Then push:
bash
```
gh issue edit <task_number> --body-file /tmp/updated-task-body.md
```
Keep a running tally. After updating, confirm: "Updated. Moving to next scenario..."

Scenario	Result	Bug Filed
`<scenario name>`	✅/❌/🚫/N/A/⚠️	yes / no / —

针对每个场景，依次执行以下操作：

将其作为具体测试用例展示——用通俗语言重述Given/When/Then步骤。

调用

AskUserQuestion

，参数如下：

```
question
```
: "这个场景通过了吗？"
```
header
```
: "结果"

options

[{label: "是 ✅", description: "场景通过"}, {label: "否 ❌", description: "场景失败"}, {label: "阻塞 🚫", description: "因依赖或环境问题无法测试"}, {label: "不适用或有条件 ⚠️", description: "不适用，或仅在特定条件下通过"}]

是 ✅ → 在实时测试映射表中标记✅。将
```
bug filed
```
设为
```
—
```
。
否 ❌ → 调用
```
AskUserQuestion
```
，参数为
```
question: "实际发生了什么？"
```
，
```
header: "失败详情"
```
，
```
options
```
预填充1–2个从场景推断出的合理失败模式（例如“未显示错误”、“返回错误数据”）。记录问题及重现步骤。然后调用
```
AskUserQuestion
```
，参数为
```
question: "你现在想要提交Bug报告吗？"
```
，
```
header: "提交Bug？"
```
，
```
options: [{label: "现在提交", description: "立即执行
```
report-bug
```
（默认选项）"}, {label: "稍后提交", description: "先继续测试下一个场景"}]
```
——如果选择“现在提交”，则在继续之前立即使用Task编号和场景详情执行
```
report-bug
```
流程。将
```
bug filed
```
设为
```
yes
```
（已提交）或
```
no
```
（延后提交）。
阻塞 🚫 → 调用
```
AskUserQuestion
```
，参数为
```
question: "是什么依赖或环境问题导致无法测试？"
```
，
```
header: "阻塞原因"
```
，
```
options
```
预填充从Task上下文推断出的常见阻塞因素（例如“缺少测试环境”、“依赖未合并的任务”）。将
```
bug filed
```
设为
```
—
```
。

不适用或有条件 ⚠️ → 调用

AskUserQuestion

，参数为

question: "是不适用，还是仅在特定条件下通过？"

，

header: "条件说明"

，

options: [{label: "不适用", description: "该场景不适用"}, {label: "有条件——说明条件", description: "仅在特定情况下通过"}]

。进行相应记录。将

bug filed

设为

—

（单独记录条件）。

记录结果后，立即更新Task工单中的实时测试映射表（不要等到所有场景测试完成）。该表必须包含
```
Bug Filed
```
列：
实时测试映射表格式（每个场景测试完成后更新）：
场景名称结果是否提交Bug
<scenario name>
✅/❌/🚫/不适用/⚠️ 是 / 否 / —
bash
```
gh issue view <task_number> --json body -q .body > /tmp/updated-task-body.md
```
使用Write或Edit工具以编程方式替换
```
/tmp/updated-task-body.md
```
中的测试映射表部分，保留其他所有内容不变。然后推送更新：
bash
```
gh issue edit <task_number> --body-file /tmp/updated-task-body.md
```
保持实时统计。更新完成后，确认：“已更新。正在进行下一个场景测试...”

场景名称	结果	是否提交Bug
`<scenario name>`	✅/❌/🚫/不适用/⚠️	是 / 否 / —

5. Probe the edge cases

5. 测试边缘案例

For each Edge Case listed in the Task (and the parent Feature), one at a time:

Derive a concrete test action from the edge case description.

Call

AskUserQuestion

with:

```
question
```
: "Did this edge case pass?"
```
header
```
: "Result"

options

[{label: "Yes ✅", description: "Edge case passed"}, {label: "No ❌", description: "Edge case failed"}, {label: "Blocked 🚫", description: "Could not test"}, {label: "N/A", description: "Not applicable"}]

No ❌ → call
```
AskUserQuestion
```
with
```
question: "What actually happened?"
```
,
```
header: "Failure details"
```
, and
```
options
```
pre-filled with 1–2 plausible failure modes inferred from the edge case. Record findings with repro steps, then ask to file a bug report as in step 4.

After each result, update the Task issue — append an Edge Cases section (or update it if present) with the same table format used in step 4.

针对Task（以及父Feature）中列出的每个边缘案例，依次执行以下操作：

从边缘案例描述中推导具体的测试操作。

调用

AskUserQuestion

，参数如下：

```
question
```
: "这个边缘案例通过了吗？"
```
header
```
: "结果"

options

[{label: "是 ✅", description: "边缘案例通过"}, {label: "否 ❌", description: "边缘案例失败"}, {label: "阻塞 🚫", description: "无法测试"}, {label: "不适用", description: "不适用"}]

否 ❌ → 调用
```
AskUserQuestion
```
，参数为
```
question: "实际发生了什么？"
```
，
```
header: "失败详情"
```
，
```
options
```
预填充1–2个从边缘案例推断出的合理失败模式。记录问题及重现步骤，然后按照步骤4的流程询问是否提交Bug报告。

每个结果记录完成后，更新Task工单——添加边缘案例部分（如果已存在则更新），使用与步骤4相同的表格格式。

6. Verify observability

6. 验证可观测性

For each item in the Observability section (logs, metrics, alerts), one at a time:

Call

AskUserQuestion

with:

```
question
```
: "Was this observability item present and correct?"
```
header
```
: "Result"

options

[{label: "Yes ✅", description: "Present and correct"}, {label: "No ❌", description: "Missing or incorrect"}, {label: "N/A", description: "Not applicable to this task"}]

Record the result. On ❌, ask for details and offer to file a bug report as in step 4.
After each result, update the Task issue with an Observability Results section.

针对可观测性部分中的每个项（日志、指标、告警），依次执行以下操作：

调用

AskUserQuestion

，参数如下：

```
question
```
: "这个可观测性项存在且正确吗？"
```
header
```
: "结果"

options

[{label: "是 ✅", description: "存在且正确"}, {label: "否 ❌", description: "缺失或不正确"}, {label: "不适用", description: "不适用于此任务"}]

记录结果。如果结果为❌，询问详情并按照步骤4的流程提供提交Bug报告的选项。
每个结果记录完成后，在Task工单中添加可观测性结果部分。

7. Finalize results and post QA summary

7. 最终确定结果并发布QA总结

The Test Mapping table has been updated after each scenario (step 4). Now do a final update: check off DoD items that passed; leave failing ones unchecked.

bash

gh issue view <task_number> --json body -q .body > /tmp/verify-final-body.md

Programmatically update the DoD checklist in

/tmp/verify-final-body.md

using the Write or Edit tool. Then push:

bash

gh issue edit <task_number> --body-file /tmp/verify-final-body.md

Post a QA summary comment:

bash

gh issue comment <task_number> --body "<qa_summary>"

The QA summary must include:

Total scenarios tested and pass/fail/conditional count
Any findings with repro steps
Conditional passes: list each ⚠️ scenario with its required condition
Clear verdict: ✅ Ready for merge / ❌ Needs fixes / ⚠️ Conditional pass (list conditions)

If the verdict is ✅ or ⚠️, add the

verified

lifecycle label:

bash

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

Print the updated Task issue URL.

测试映射表已在每个场景测试完成后更新（步骤4）。现在进行最终更新：勾选已通过的DoD项；未通过的项保持未勾选状态。

bash

gh issue view <task_number> --json body -q .body > /tmp/verify-final-body.md

使用Write或Edit工具以编程方式更新

/tmp/verify-final-body.md

中的DoD检查清单。然后推送更新：

bash

gh issue edit <task_number> --body-file /tmp/verify-final-body.md

发布QA总结评论：

bash

gh issue comment <task_number> --body "<qa_summary>"

QA总结必须包含：

测试的场景总数以及通过/失败/有条件通过的数量
所有问题及重现步骤
有条件通过的场景：列出每个⚠️场景及其所需条件
明确的结论：✅ 可合并 / ❌ 需要修复 / ⚠️ 有条件通过（列出条件）

如果结论为✅或⚠️，添加

verified

生命周期标签：

bash

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

打印更新后的Task工单URL。

8. Offer to open a PR and close the issue

8. 提供创建PR并关闭工单的选项

If the verdict is ✅ or ⚠️, call

AskUserQuestion

with:

```
question
```
: "Task verified. What would you like to do next?"
```
header
```
: "Next step"

options

[{label: "Open PR now", description: "Create a pull request — the task closes automatically when the PR is merged (recommended)"}, {label: "Skip for now", description: "Exit — I'll open the PR later"}]

Open PR now → follow the
```
wtf:create-pr
```
process, passing the Task number in as context. The Task (and Feature / Epic) will be closed automatically when the PR with
```
Closes #<task_number>
```
is merged — do not close issues directly.
Skip for now → continue.

Closing policy: Issues are only "closed as completed" via a merged PR that contains
Closes #<n>
. Never call
gh issue close <n>
for completed work. Direct closes are reserved for:
gh issue close <n> --reason "not planned"
— won't implement
gh issue close <n> --reason "duplicate"
— duplicate of another issue

如果结论为✅或⚠️，调用

AskUserQuestion

，参数如下：

```
question
```
: "任务已验证。接下来你想做什么？"
```
header
```
: "下一步"

options

[{label: "现在创建PR", description: "创建拉取请求——PR合并时任务将自动关闭（推荐）"}, {label: "稍后再创建", description: "退出——我稍后再创建PR"}]

现在创建PR → 遵循
```
wtf:create-pr
```
流程，传入Task编号作为上下文。当包含
```
Closes #<task_number>
```
的PR合并时，Task（以及Feature/Epic）将自动关闭——请勿直接关闭工单。
稍后再创建 → 继续执行后续步骤。

关闭规则： 只有当包含
Closes #<n>
的PR合并时，工单才会被标记为“已完成关闭”。请勿为已完成的工作调用
gh issue close <n>
。直接关闭仅适用于：
gh issue close <n> --reason "not planned"
—— 不计划开发
gh issue close <n> --reason "duplicate"
—— 重复工单

9. Offer bug reports for remaining failures

9. 为未提交的失败案例提供Bug报告选项

Check all result tables (Gherkin scenarios from step 4, edge cases from step 5, observability from step 6): find all rows where Result is ❌ and

Bug Filed

no

. These are the unfiled failures.

If none exist, skip this step entirely.

If unfiled failures exist, present them as a numbered list, then call

AskUserQuestion

with:

```
question
```
: "[n] failing scenario(s) without a bug report. How would you like to handle them?" (replace [n] with the actual count)
```
header
```
: "File bugs?"

options

[{label: "File separately", description: "File one bug report per failing scenario (default)"}, {label: "File combined", description: "File one combined bug report for all failures"}, {label: "Skip", description: "Exit — I'll handle it manually"}]

File separately → spawn one sub-agent per failing scenario in parallel using the Agent tool, each running the
```
report-bug
```
process with the task number and the specific failing scenario. Wait for all sub-agents to complete before exiting.
File combined → follow the
```
report-bug
```
process once, passing in the task number and all failing scenarios together.
Skip → exit without filing reports.

检查所有结果表（步骤4的Gherkin场景、步骤5的边缘案例、步骤6的可观测性）：找出所有结果为❌且

Bug Filed

为

no

的行。这些是未提交的失败案例。

如果没有此类案例，直接跳过此步骤。

如果存在未提交的失败案例，将其列为编号列表，然后调用

AskUserQuestion

，参数如下：

```
question
```
: "有[n]个失败场景未提交Bug报告。你想如何处理？"（将[n]替换为实际数量）
```
header
```
: "提交Bug？"

options

[{label: "单独提交", description: "为每个失败场景提交一份Bug报告（默认选项）"}, {label: "合并提交", description: "为所有失败场景提交一份合并的Bug报告"}, {label: "跳过", description: "退出——我将手动处理"}]

单独提交 → 使用Agent工具为每个失败场景并行生成一个子Agent，每个子Agent使用Task编号和具体失败场景执行
```
report-bug
```
流程。等待所有子Agent完成后再退出。
合并提交 → 执行一次
```
report-bug
```
流程，传入Task编号和所有失败场景。
跳过 → 不提交报告直接退出。