team-qa

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

When this skill is invoked, orchestrate the QA team through a structured testing cycle.

Decision Points: At each phase transition, use

AskUserQuestion

to present the user with the subagent's proposals as selectable options. Write the agent's full analysis in conversation, then capture the decision with concise labels. The user must approve before moving to the next phase.

当调用该技能时，将统筹QA团队完成结构化测试周期。

决策节点：在每个阶段过渡时，使用

AskUserQuestion

向用户展示子Agent的提议作为可选选项。在对话中写入Agent的完整分析，然后用简洁标签记录决策。必须获得用户批准才能进入下一阶段。

Phase 0: Resolve Review Mode

阶段0：确定评审模式

If
```
--review [mode]
```
was passed as an argument, use that mode.
Else read
```
production/review-mode.txt
```
— use whatever is written there.
Else default to
```
lean
```
.

Modes:

```
full
```
— spawn all director and lead gates as described
```
lean
```
— skip director gates unless they are PHASE-GATE type (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE)
```
solo
```
— skip all director gate spawning entirely; run the skill without any agent gates

Store the resolved mode for use in all subsequent phases.

如果传入了
```
--review [mode]
```
参数，则使用该模式。
否则读取
```
production/review-mode.txt
```
文件——使用其中记录的模式。
否则默认使用
```
lean
```
模式。

模式说明：

```
full
```
— 按照描述启用所有主管和负责人关卡
```
lean
```
— 跳过主管关卡，除非是PHASE-GATE类型（CD-PHASE-GATE、TD-PHASE-GATE、PR-PHASE-GATE、AD-PHASE-GATE）
```
solo
```
— 完全跳过所有主管关卡的启用；无需任何Agent关卡即可运行该技能

保存确定后的模式，供后续所有阶段使用。

Team Composition

团队构成

qa-lead — QA strategy, test plan generation, story classification, sign-off report
qa-tester — Test case writing, bug report writing, manual QA documentation

qa-lead — QA策略制定、测试计划生成、需求分类、验收报告出具
qa-tester — 测试用例编写、缺陷报告撰写、手动QA文档整理

How to Delegate

任务委派方式

Use the Task tool to spawn each team member as a subagent:

```
subagent_type: qa-lead
```
— Strategy, planning, classification, sign-off
```
subagent_type: qa-tester
```
— Test case writing and bug report writing

Always provide full context in each agent's prompt (story file paths, QA plan path, scope constraints). Launch independent qa-tester tasks in parallel where possible (e.g., multiple stories in Phase 5 can be scaffolded simultaneously).

使用Task工具将每个团队成员作为子Agent启动：

```
subagent_type: qa-lead
```
— 负责策略、规划、分类、验收工作
```
subagent_type: qa-tester
```
— 负责测试用例编写和缺陷报告撰写

在每个Agent的提示中始终提供完整上下文（需求文件路径、QA计划路径、范围约束）。尽可能并行启动独立的qa-tester任务（例如，阶段5中的多个需求可同时搭建测试框架）。

Pipeline

流程管线

Phase 1: Load Context

阶段1：加载上下文

Before doing anything else, gather the full scope:

Detect the current sprint or feature scope from the argument:
- If argument is a sprint identifier (e.g.,
```
sprint-03
```
  ): Glob
```
production/sprints/
```
  for files matching
```
*[sprint-identifier]*.md
```
  . Read the matched file. If multiple match, use the most recently modified.
- If argument is
```
feature: [system-name]
```
  : glob story files tagged for that system
- If no argument: read
```
production/session-state/active.md
```
  and
```
production/sprint-status.yaml
```
  (if present) to infer the active sprint
Read
```
production/stage.txt
```
to confirm the current project phase.
Count stories found and report to the user:

"QA cycle starting for [sprint/feature]. Found [N] stories. Current stage: [stage]. Ready to begin QA strategy?"

在执行任何操作前，先收集完整范围：

从参数中检测当前迭代或功能范围：
- 如果参数是迭代标识符（如
```
sprint-03
```
  ）：在
```
production/sprints/
```
  目录下匹配所有
```
*[sprint-identifier]*.md
```
  文件。读取匹配的文件。如果有多个匹配项，使用最近修改的文件。
- 如果参数是
```
feature: [system-name]
```
  ：匹配标记为该系统的需求文件
- 如果无参数：读取
```
production/session-state/active.md
```
  和
```
production/sprint-status.yaml
```
  （若存在）以推断当前活跃迭代
读取
```
production/stage.txt
```
确认当前项目阶段。
统计找到的需求数量并向用户报告：

"QA周期针对[迭代/功能]启动。共找到[N]个需求。当前阶段：[stage]。是否准备开始制定QA策略？"

Phase 2: QA Strategy (qa-lead)

阶段2：QA策略制定（qa-lead）

Spawn

qa-lead

via Task to review all in-scope stories and produce a QA strategy.

Prompt the qa-lead to:

Read each story file
Classify each story by type: Logic / Integration / Visual/Feel / UI / Config/Data
Identify which stories require automated test evidence vs. manual QA
Flag any stories with missing acceptance criteria or missing test evidence that would block QA
Estimate manual QA effort (number of test sessions needed)
Before assessing smoke status, check for an existing smoke check report: Glob
```
production/qa/smoke-*.md
```
and read the most recently modified file (if found). If a report exists, use its verdict and findings directly — do not re-interview the user. If no report exists, note: "No prior smoke check report found — run
```
/smoke-check sprint
```
before proceeding." and set smoke check status to UNKNOWN (treat as PASS WITH WARNINGS for the purpose of continuing). Produce a smoke check verdict: PASS / PASS WITH WARNINGS [list] / FAIL [list of failures] / UNKNOWN (no report found)
Produce a strategy summary table and smoke check result:

Story Type Automated Required Manual Required Blocker?
Smoke Check: [PASS / PASS WITH WARNINGS / FAIL / UNKNOWN] — [source:
```
production/qa/smoke-[date].md
```
or "no report found"] — [details if not PASS]

If the smoke check result is FAIL, the qa-lead must list the failures prominently. QA cannot proceed past the strategy phase with a failed smoke check.

Present the qa-lead's full strategy to the user, then use

AskUserQuestion

question: "QA Strategy Review"
options:
  - "Looks good — proceed to test plan"
  - "Adjust story types before proceeding"
  - "Skip blocked stories and proceed with the rest"
  - "Smoke check failed — fix issues and re-run /team-qa"
  - "Cancel — resolve blockers first"

If smoke check FAIL: do not proceed to Phase 3. Surface the failures from the smoke check report and stop. The user must fix them, re-run

/smoke-check sprint

, and then re-run

/team-qa

. If smoke check UNKNOWN: surface a warning — "No smoke check report found. Recommend running

/smoke-check sprint

before QA. Proceeding with caution." If smoke check PASS WITH WARNINGS: note the warnings for the sign-off report and continue. If blockers are present: list them explicitly. The user may choose to skip blocked stories or cancel the cycle.

通过Task启动

qa-lead

，让其审阅所有范围内的需求并制定QA策略。

向qa-lead提示以下要求：

读取每个需求文件
按类型对每个需求分类：逻辑类 / 集成类 / 视觉/体验类 / UI类 / 配置/数据类
确定哪些需求需要自动化测试证据，哪些需要手动QA
标记任何缺少验收标准或测试证据、会阻碍QA推进的需求
估算手动QA工作量（所需测试会话次数）
在评估冒烟测试状态前，检查是否存在现有冒烟测试报告：在
```
production/qa/smoke-*.md
```
目录下匹配文件并读取最近修改的文件（若找到）。如果存在报告，直接使用其结论和发现——无需再次询问用户。如果没有报告，记录："未找到之前的冒烟测试报告——请先运行
```
/smoke-check sprint
```
。" 并将冒烟测试状态设为UNKNOWN（为了继续流程，视为带警告通过）。生成冒烟测试结论：PASS / PASS WITH WARNINGS [问题列表] / FAIL [失败列表] / UNKNOWN (未找到报告)
生成策略汇总表和冒烟测试结果：

需求类型是否需要自动化测试是否需要手动测试是否阻塞？
冒烟测试：[PASS / PASS WITH WARNINGS / FAIL / UNKNOWN] — [来源：
```
production/qa/smoke-[date].md
```
或 "未找到报告"] — [非PASS时的详情]

如果冒烟测试结果为FAIL，qa-lead必须突出列出失败项。QA无法在冒烟测试失败的情况下推进到策略阶段之后。

向用户展示qa-lead的完整策略，然后使用

AskUserQuestion

：

question: "QA策略评审"
options:
  - "看起来没问题——推进到测试计划阶段"
  - "先调整需求类型再推进"
  - "跳过阻塞的需求，继续处理其余部分"
  - "冒烟测试失败——修复问题后重新运行`/team-qa`"
  - "取消——先解决阻塞问题"

如果冒烟测试FAIL：不要推进到阶段3。展示冒烟测试报告中的失败项并停止流程。用户必须修复问题，重新运行

/smoke-check sprint

，然后重新运行

/team-qa

。如果冒烟测试UNKNOWN：展示警告——"未找到冒烟测试报告。建议在QA前运行

/smoke-check sprint

。将谨慎推进。" 如果冒烟测试PASS WITH WARNINGS：在验收报告中记录警告并继续。如果存在阻塞项：明确列出。用户可选择跳过阻塞需求或取消周期。

Phase 3: Test Plan Generation

阶段3：测试计划生成

Using the strategy from Phase 2, produce a structured test plan document.

The test plan should cover:

Scope: sprint/feature name, story count, dates
Story Classification Table: from Phase 2 strategy
Automated Test Requirements: which stories need test files, expected paths in
```
tests/
```
Manual QA Scope: which stories need manual walkthrough and what to validate
Out of Scope: what is explicitly not being tested this cycle and why
Entry Criteria: what must be true before QA can begin. Always include: (1) Smoke check PASS or PASS WITH WARNINGS report exists at
```
production/qa/smoke-*.md
```
, (2) build is stable (no crashes on launch), (3) all Must Have stories have Status: in-progress or done in
```
production/sprint-status.yaml
```
. Add any sprint-specific criteria beyond these.
Exit Criteria: what constitutes a completed QA cycle (all stories PASS or FAIL with bugs filed)

Ask: "May I write the QA plan to

production/qa/qa-plan-[sprint]-[date].md

Write only after receiving approval.

使用阶段2的策略，生成结构化测试计划文档。

测试计划应包含：

范围：迭代/功能名称、需求数量、日期
需求分类表：来自阶段2的策略
自动化测试要求：哪些需求需要测试文件，
```
tests/
```
目录中的预期路径
手动QA范围：哪些需求需要手动走查，以及需要验证的内容
排除范围：本周期明确不测试的内容及原因
准入标准：QA开始前必须满足的条件。始终包含：(1)
```
production/qa/smoke-*.md
```
目录下存在冒烟测试PASS或PASS WITH WARNINGS报告，(2) 构建稳定（启动无崩溃），(3) 所有Must Have需求在
```
production/sprint-status.yaml
```
中的状态为in-progress或done。添加任何迭代特有的额外标准。
准出标准：构成QA周期完成的条件（所有需求PASS或FAIL并已提交缺陷）

询问："是否可以将QA计划写入

production/qa/qa-plan-[sprint]-[date].md

？"

仅在获得批准后写入。

Phase 4: Test Case Writing (qa-tester)

阶段4：测试用例编写（qa-tester）

Smoke check is performed as part of Phase 2 (QA Strategy). If the smoke check returned FAIL in Phase 2, the cycle was stopped there. This phase only runs when the Phase 2 smoke check was PASS, PASS WITH WARNINGS, or UNKNOWN.

For each story requiring manual QA (Visual/Feel, UI, Integration without automated tests):

Spawn

qa-tester

via Task for each story (run in parallel where possible), providing:

The story file path
The relevant section of the QA plan for that story
The GDD acceptance criteria for the system being tested (if available)
Instructions to write detailed test cases covering all acceptance criteria

Each test case set should include:

Preconditions: game state required before testing begins
Steps: numbered, unambiguous actions
Expected Result: what should happen
Actual Result: field left blank for the tester to fill in
Pass/Fail: field left blank

Present the test cases to the user for review before execution. Group by story.

Use

AskUserQuestion

per story group (batched 3-4 at a time):

question: "Test cases ready for [Story Group]. Review before manual QA begins?"
options:
  - "Approved — begin manual QA for these stories"
  - "Revise test cases for [story name]"
  - "Skip manual QA for [story name] — not ready"

冒烟测试已在阶段2（QA策略）中执行。如果阶段2中冒烟测试返回FAIL，周期已在该处停止。本阶段仅在阶段2冒烟测试结果为PASS、PASS WITH WARNINGS或UNKNOWN时运行。

对于每个需要手动QA的需求（视觉/体验类、UI类、无自动化测试的集成类）：

通过Task为每个需求启动

qa-tester

（尽可能并行运行），提供：

需求文件路径
该需求对应的QA计划相关章节
被测系统的GDD验收标准（若可用）
编写覆盖所有验收标准的详细测试用例的指令

每组测试用例应包含：

前置条件：测试开始前所需的系统状态
步骤：编号的明确操作
预期结果：应发生的情况
实际结果：留空供测试人员填写
通过/失败：留空

在执行前将测试用例提交给用户评审。按需求分组。

对每组需求（批量3-4个）使用

AskUserQuestion

：

question: "[需求组]的测试用例已准备好。手动QA开始前是否评审？"
options:
  - "已批准——开始这些需求的手动QA"
  - "修改[需求名称]的测试用例"
  - "跳过[需求名称]的手动QA——尚未准备好"

Phase 5: Manual QA Execution

阶段5：手动QA执行

Walk through each story in the approved manual QA list.

Batch stories into groups of 3-4 and use

AskUserQuestion

for each:

question: "Manual QA — [Story Title]\n[brief description of what to test]"
options:
  - "PASS — all acceptance criteria verified"
  - "PASS WITH NOTES — minor issues found (describe after)"
  - "FAIL — criteria not met (describe after)"
  - "BLOCKED — cannot test yet (reason)"

After each FAIL result: use

AskUserQuestion

to collect the failure description, then spawn

qa-tester

via Task to write a formal bug report in

production/qa/bugs/

Bug report naming:

BUG-[NNN]-[short-slug].md

(increment NNN from existing bugs in the directory).

After collecting all results, summarize:

Stories PASS: [count]
Stories PASS WITH NOTES: [count]
Stories FAIL: [count] — bugs filed: [IDs]
Stories BLOCKED: [count]

遍历已批准的手动QA列表中的每个需求。

将需求分成3-4个一组，对每组使用

AskUserQuestion

：

question: "手动QA — [需求标题]\n[测试内容简要描述]"
options:
  - "PASS — 所有验收标准已验证"
  - "PASS WITH NOTES — 发现次要问题（后续描述）"
  - "FAIL — 未满足标准（后续描述）"
  - "BLOCKED — 暂时无法测试（原因）"

每次得到FAIL结果后：使用

AskUserQuestion

收集失败描述，然后通过Task启动

qa-tester

在

production/qa/bugs/

目录下撰写正式缺陷报告。

缺陷报告命名规则：

BUG-[NNN]-[short-slug].md

（NNN从目录中现有缺陷的编号递增）。

收集所有结果后汇总：

通过的需求：[数量]
带备注通过的需求：[数量]
失败的需求：[数量] — 已提交缺陷：[ID列表]
阻塞的需求：[数量]

Phase 6: QA Sign-Off Report

阶段6：QA验收报告

Spawn

qa-lead

via Task to produce the sign-off report using all results from Phases 4–6.

The sign-off report format:

markdown

undefined

通过Task启动

qa-lead

，使用阶段4至阶段6的所有结果生成验收报告。

验收报告格式：

markdown

undefined

QA Sign-Off Report: [Sprint/Feature]

QA验收报告: [迭代/功能]

Date: [date]

日期: [date]

Test Coverage Summary

测试覆盖汇总

Story	Type	Auto Test	Manual QA	Result
[title]	Logic	PASS	—	PASS
[title]	Visual	—	PASS	PASS

需求	类型	自动化测试	手动QA	结果
[标题]	逻辑类	PASS	—	PASS
[标题]	视觉类	—	PASS	PASS

Bugs Found

发现的缺陷

ID	Story	Severity	Status
BUG-001	[story]	S2	Open

ID	需求	严重程度	状态
BUG-001	[需求]	S2	打开

Verdict: APPROVED / APPROVED WITH CONDITIONS / NOT APPROVED

结论: APPROVED / APPROVED WITH CONDITIONS / NOT APPROVED

Conditions (if any): [list what must be fixed before the build advances]

条件（若有）：[构建推进前必须修复的问题列表]

Next Step

下一步

[guidance based on verdict]


Verdict rules:
- **APPROVED**: All stories PASS or PASS WITH NOTES; no S1/S2 bugs open
- **APPROVED WITH CONDITIONS**: S3/S4 bugs open, or PASS WITH NOTES issues documented; no S1/S2 bugs
- **NOT APPROVED**: Any S1/S2 bugs open; or stories FAIL without documented workaround

Next step guidance by verdict:
- APPROVED: "Build is ready for the next phase. Run `/gate-check` to validate advancement."
- APPROVED WITH CONDITIONS: "Resolve conditions before advancing. S3/S4 bugs may be deferred to polish."
- NOT APPROVED: "Resolve S1/S2 bugs and re-run `/team-qa` or targeted manual QA before advancing."

Ask: "May I write this QA sign-off report to `production/qa/qa-signoff-[sprint]-[date].md`?"

Write only after receiving approval.

[基于结论的指导]


结论规则：
- **APPROVED**：所有需求PASS或PASS WITH NOTES；无未解决的S1/S2级缺陷
- **APPROVED WITH CONDITIONS**：存在未解决的S3/S4级缺陷，或已记录PASS WITH NOTES问题；无未解决的S1/S2级缺陷
- **NOT APPROVED**：存在任何未解决的S1/S2级缺陷；或需求FAIL且无记录的解决方案

基于结论的下一步指导：
- APPROVED: "构建已准备好进入下一阶段。运行`/gate-check`验证是否可以推进。"
- APPROVED WITH CONDITIONS: "推进前解决条件问题。S3/S4级缺陷可推迟到优化阶段处理。"
- NOT APPROVED: "解决S1/S2级缺陷后，重新运行`/team-qa`或针对性手动QA，再推进。"

询问："是否可以将这份QA验收报告写入`production/qa/qa-signoff-[sprint]-[date].md`？"

仅在获得批准后写入。

Error Recovery Protocol

错误恢复协议

If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete:

Surface immediately: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases
Assess dependencies: Check whether the blocked agent's output is required by subsequent phases. If yes, do not proceed past that dependency point without user input.
Offer options via AskUserQuestion with choices:
- Skip this agent and note the gap in the final report
- Retry with narrower scope
- Stop here and resolve the blocker first
Always produce a partial report — output whatever was completed. Never discard work because one agent blocked.

Common blockers:

Input file missing (story not found, GDD absent) → redirect to the skill that creates it
ADR status is Proposed → do not implement; run
```
/architecture-decision
```
first
Scope too large → split into two stories via
```
/create-stories
```
Conflicting instructions between ADR and story → surface the conflict, do not guess

如果任何通过Task启动的Agent返回BLOCKED、错误或无法完成任务：

立即告知用户：在推进到依赖阶段前，向用户报告"[AgentName]: BLOCKED — [原因]"
评估依赖关系：检查被阻塞Agent的输出是否为后续阶段所需。如果是，在未获得用户输入前不要越过该依赖点。
通过AskUserQuestion提供选项：
- 跳过该Agent并在最终报告中记录缺口
- 缩小范围后重试
- 在此处停止并先解决阻塞问题
始终生成部分报告——输出所有已完成的工作。不要因单个Agent阻塞而丢弃已完成的工作。

常见阻塞原因：

输入文件缺失（未找到需求、缺少GDD）→ 引导至创建该文件的技能
ADR状态为Proposed → 不要执行；先运行
```
/architecture-decision
```
范围过大 → 通过
```
/create-stories
```
拆分为两个需求
ADR与需求之间存在冲突指令 → 告知用户冲突，不要自行猜测

Output

输出

A summary covering: stories in scope, smoke check result, manual QA results, bugs filed (with IDs and severities), and the final APPROVED / APPROVED WITH CONDITIONS / NOT APPROVED verdict.

Verdict: COMPLETE — QA cycle finished. Verdict: BLOCKED — smoke check failed or critical blocker prevented cycle completion; partial report produced.

包含以下内容的汇总：范围内的需求、冒烟测试结果、手动QA结果、已提交的缺陷（含ID和严重程度），以及最终的APPROVED / APPROVED WITH CONDITIONS / NOT APPROVED结论。

结论：COMPLETE — QA周期完成。结论：BLOCKED — 冒烟测试失败或关键阻塞导致周期无法完成；已生成部分报告。

Session State Update

会话状态更新

After the final phase completes (sign-off report written or BLOCKED verdict reached), silently append to

production/session-state/active.md

<!-- QA RUN: [date] | Sprint: [sprint identifier or "ad-hoc"] | Verdict: [PASS/FAIL/CONCERNS] | Report: production/qa/qa-[date].md -->

在最终阶段完成（验收报告已写入或得出BLOCKED结论）后，静默追加内容到

production/session-state/active.md

：

<!-- QA RUN: [date] | Sprint: [迭代标识符或"临时"] | Verdict: [PASS/FAIL/CONCERNS] | Report: production/qa/qa-[date].md -->