qa

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

QA

You are performing functional validation of a feature, bugfix, or deployment. Your job is to prove it works (or doesn't) by executing test scenarios and capturing evidence.

你正在对功能、Bug修复或部署执行功能验证。你的任务是通过执行测试场景并捕获证据来证明其可用（或不可用）。

Working Agreement

工作约定

All user-facing questions go through
AskUserQuestion
(when not Autopilot) — see

desplega:ask-user

for conventions.

File-review is on by default — invoke it on the QA report when ready (skip only if Autopilot).

所有面向用户的问题均通过
AskUserQuestion
提交（非自动驾驶模式下）——请参考

desplega:ask-user

的约定。

文件审核默认开启——准备好后在QA报告上调用该功能（仅自动驾驶模式下可跳过）。

Ownership: QA Doc Lives Here, Not in Plans

归属：QA文档存放在此处，而非计划中

QA test cases live in QA docs (

thoughts/<username|shared>/qa/YYYY-MM-DD-<feature>.md

), not inline in plans. When a plan has a

### QA Spec (optional):

block, that block links to a QA doc this skill produces.

This skill is reserved for cross-cutting or evidence-heavy QA — not routine per-phase checks. Routine per-phase agent verification belongs in the plan's inline

#### Automated QA:

bucket, executed by phase-running. Use this skill when:

The QA work spans multiple phases or the whole feature
Evidence (screenshots, recordings, logs) needs to live somewhere durable
A formal verdict (pass/fail/blocked) is required

Invocation paths:

Planning Step 3 ("Generate QA docs") calls this skill before handoff, for any phase whose QA needs a separate doc.
Implementing / phase-running call this skill at phase-completion if the phase reports
```
QA Doc: <path>
```
.
Direct user invocation (
```
/qa
```
) creates a standalone doc not linked to a plan.

QA测试用例存放在QA文档（

thoughts/<用户名|shared>/qa/YYYY-MM-DD-<功能名>.md

）中，而非内联在计划里。当计划包含

### QA Spec (optional):

块时，该块会链接到此Skill生成的QA文档。

此Skill专为跨阶段或需大量证据的QA工作保留——不适用于常规的阶段性检查。常规的阶段性Agent验证应放在计划内联的

#### Automated QA:

模块中，由阶段运行功能执行。在以下场景使用此Skill：

QA工作跨越多个阶段或整个功能
需要将证据（截图、录屏、日志）存储在持久化位置
需要正式的结论（通过/失败/阻塞）

调用路径：

规划步骤3（"生成QA文档"）在移交前调用此Skill，适用于任何需要单独文档的QA阶段。
实现/阶段运行在阶段完成时调用此Skill，如果阶段报告包含
```
QA Doc: <路径>
```
。
用户直接调用（
```
/qa
```
）创建不关联计划的独立文档。

QA Approach

QA方法

Unless Autopilot, ask once at the start:

Question	Options
"How would you like to execute test cases?"	1. Browser automation (qa-use) — if available, 2. Manual testing with guided steps, 3. Mixed — automate what we can, manual for the rest

Note on qa-use availability: Check if

qa-use

is available (look for

qa-use:*

in available skills). Also check if the project's

CLAUDE.md

specifies a different testing tool. If qa-use is not available and no alternative is specified, default to manual testing.

除非处于自动驾驶模式，否则在开始时需询问一次：

问题	选项
"你希望如何执行测试用例？"	1. 浏览器自动化（qa-use）——若可用，2. 带引导步骤的手动测试，3. 混合模式——尽可能自动化，其余手动执行

关于qa-use可用性的说明：检查

qa-use

是否可用（在可用Skill中查找

qa-use:*

）。同时检查项目的

CLAUDE.md

是否指定了其他测试工具。若qa-use不可用且无替代工具指定，默认使用手动测试。

When to Use

使用场景

This skill activates when:

User invokes
```
/qa
```
command
Another skill references
```
desplega:qa
```
User asks to test, validate, or QA a feature
The implementing skill encounters a phase with a QA spec

当出现以下情况时激活此Skill：

用户调用
```
/qa
```
命令
其他Skill引用
```
desplega:qa
```
用户要求测试、验证或对功能执行QA
实现Skill遇到包含QA规范的阶段

Autonomy Mode

自主模式

At the start of QA, adapt your interaction level based on the autonomy mode:

Mode	Behavior
Autopilot	Execute all test cases, capture evidence, present summary at end
Critical (Default)	Ask about test case design, present results for review
Verbose	Walk through each test case, confirm before executing

The autonomy mode is passed by the invoking command. If not specified, default to Critical.

在QA开始时，根据自主模式调整交互程度：

模式	行为
自动驾驶	执行所有测试用例，捕获证据，最后呈现总结
关键模式（默认）	询问测试用例设计方案，呈现结果供审核
详细模式	逐步讲解每个测试用例，执行前确认

自主模式由调用命令传递。若未指定，默认使用关键模式。

Process Steps

流程步骤

Step 1: Context & Scope

步骤1：上下文与范围

Determine the source of QA specs:

Plan-driven (called from planning/implementing/phase-running) → A plan path + phase reference is supplied. Read the relevant phase, design test cases for the deliverable named in its Overview, and produce the QA doc the plan's QA Spec block will link to.

Separate QA spec document provided → Read the standalone spec, use it as the basis for the QA session.

Direct user invocation, no source → Build test cases from scratch with the user. Use AskUserQuestion to establish:

Question	Options
"What are we validating? Please describe the feature or provide context."	[Free text response]

In all cases, create the QA document from

cc-plugin/base/skills/qa/template.md

thoughts/<username|shared>/qa/YYYY-MM-DD-<topic>.md

. Use the user's name when known; fall back to

thoughts/shared/qa/

For plan-driven invocation: after the doc exists, update the plan's

### QA Spec (optional):

block in the relevant phase to point at the doc path. Do not inline scenarios in the plan.

确定QA规范的来源：

计划驱动（从规划/实现/阶段运行调用） → 提供计划路径和阶段引用。读取相关阶段，为其概述中命名的交付物设计测试用例，并生成计划的QA Spec块将链接的QA文档。

提供独立QA规范文档 → 读取独立规范，以此为基础开展QA会话。

用户直接调用，无来源 → 与用户从头构建测试用例。使用AskUserQuestion确认：

问题	选项
"我们要验证什么？请描述功能或提供上下文。"	[自由文本回复]

在所有情况下，从

cc-plugin/base/skills/qa/template.md

模板创建QA文档，存储路径为

thoughts/<用户名|shared>/qa/YYYY-MM-DD-<主题>.md

。若已知用户名则使用用户名；否则默认使用

thoughts/shared/qa/

。

对于计划驱动的调用：文档创建完成后，更新相关阶段计划中的

### QA Spec (optional):

块，使其指向文档路径。请勿将场景内联到计划中。

Step 2: Test Case Design

步骤2：测试用例设计

Define test cases covering:

Happy path — The main scenario works as intended
Edge cases — Boundary conditions, empty inputs, large inputs
Error scenarios — Invalid inputs, permission failures, network errors

If sourced from a plan: Aggregate phase QA specs into the test case list. Augment with additional exploratory cases.

If sourced from a separate spec: Use those scenarios as the starting point and augment with exploratory cases.

If browser automation was selected and qa-use is available: Design qa-use test steps for each test case (explore → snapshot → interact → screenshot).

Write all test cases into the QA document's

## Test Cases

section.

定义涵盖以下内容的测试用例：

正常路径——主场景按预期工作
边缘情况——边界条件、空输入、大输入
错误场景——无效输入、权限失败、网络错误

若来源于计划：将阶段QA规范汇总到测试用例列表中，并补充探索性用例。

若来源于独立规范：以这些场景为起点，补充探索性用例。

若选择浏览器自动化且qa-use可用：为每个测试用例设计qa-use测试步骤（探索→快照→交互→截图）。

将所有测试用例写入QA文档的

## 测试用例

部分。

Step 3: Execute Tests

步骤3：执行测试

For browser automation (qa-use):

Use
```
qa-use:explore
```
to navigate to the target page
Take snapshots to understand page state
Interact with elements (click, type, navigate)
Capture screenshots as evidence

For manual testing:

Present each test case's steps to the user
Guide them through execution
Use AskUserQuestion to collect results:

Question	Options
"TC-N: [Test case name]. Did it pass?"	1. Pass, 2. Fail — [describe what happened], 3. Blocked — [describe blocker], 4. Skipped

For CLI verification:

Execute the CLI commands directly
Compare output against expected results
Record pass/fail automatically

OPTIONAL SUB-SKILL: When a CLI test case needs the same multi-step probe re-run later (regression coverage, post-deploy smoke, multi-environment validation) and no existing script captures it, invoke

desplega:script-builder

inline. The generated script is committed to the project's

scripts/

directory with the PASS/FAIL +

/tmp

log convention; this QA session uses it for the current run, and future QA/verifying sessions discover it via the auto-added

<important if>

block in CLAUDE.md.

For each test case, record the actual result and pass/fail status.

对于浏览器自动化（qa-use）：

使用
```
qa-use:explore
```
导航到目标页面
拍摄快照以了解页面状态
与元素交互（点击、输入、导航）
捕获截图作为证据

对于手动测试：

向用户展示每个测试用例的步骤
引导用户执行
使用AskUserQuestion收集结果：

问题	选项
"TC-N: [测试用例名称]。测试通过了吗？"	1. 通过，2. 失败——[描述情况]，3. 阻塞——[描述阻塞原因]，4. 跳过

对于CLI验证：

直接执行CLI命令
将输出与预期结果对比
自动记录通过/失败状态

可选子Skill：当CLI测试用例需要稍后重新运行相同的多步骤探测（回归覆盖、部署后冒烟测试、多环境验证）且无现有脚本实现时，内联调用

desplega:script-builder

。生成的脚本将以PASS/FAIL +

/tmp

日志规范提交到项目的

scripts/

目录；本次QA会话将使用该脚本执行当前测试，未来的QA/验证会话将通过CLAUDE.md中自动添加的

<important if>

块发现该脚本。

为每个测试用例记录实际结果和通过/失败状态。

Step 4: Capture Evidence

步骤4：捕获证据

Gather evidence for the QA report:

Screenshots: Via qa-use browser screenshots or user-provided
Videos: Session recording URLs (Loom, etc.)
Logs: Console output, error messages, relevant log lines
External links: Sentry issues, CI/CD runs, Grafana dashboards, PR URLs

Add all evidence to the QA document's

## Evidence

section.

为QA报告收集证据：

截图：通过qa-use浏览器截图或用户提供
视频：会话录屏链接（如Loom等）
日志：控制台输出、错误消息、相关日志行
外部链接：Sentry问题、CI/CD运行记录、Grafana仪表板、PR链接

将所有证据添加到QA文档的

## 证据

部分。

Step 5: Record Results

步骤5：记录结果

Update the QA document with:

Actual results for each test case
Pass/fail/blocked/skipped status per test case
Evidence links inline with relevant test cases
Any issues found in the
```
## Issues Found
```
section with severity tags (critical/major/minor)

更新QA文档：

每个测试用例的实际结果
每个测试用例的通过/失败/阻塞/跳过状态
相关测试用例内联的证据链接
在
```
## 发现的问题
```
部分记录发现的问题，并标注严重程度标签（critical/major/minor）

Step 6: Verdict

步骤6：结论

Aggregate results into an overall verdict:

Verdict	When
PASS	All test cases pass, no critical/major issues
FAIL	Any test case fails, or critical/major issues found
BLOCKED	Cannot complete testing due to environment/dependency issues

Write a 1-2 sentence summary in the QA document's

## Verdict

section. Update the frontmatter

status

field to match (pass/fail/blocked).

汇总结果得出整体结论：

结论	适用场景
通过	所有测试用例通过，无严重/主要问题
失败	任何测试用例失败，或发现严重/主要问题
阻塞	因环境/依赖问题无法完成测试

在QA文档的

## 结论

部分撰写1-2句话的总结。更新前置元数据的

status

字段以匹配结论（pass/fail/blocked）。

Step 7: Persist QA Knowledge

步骤7：留存QA知识

If the project's

CLAUDE.md

agents.md

doesn't document how QA is done for this project, offer to add a QA section describing:

Testing approach used (manual, browser automation, CLI)
Tools used (qa-use, Playwright, etc.)
Common test patterns discovered

Use AskUserQuestion with:

Question	Options
"This project doesn't have documented QA practices. Would you like me to add a QA section to CLAUDE.md?"	1. Yes, add QA documentation, 2. No, skip this

Also persist useful patterns to memory if they emerge across QA sessions.

如果项目的

CLAUDE.md

或

agents.md

未记录该项目的QA执行方式，主动提议添加QA部分，内容包括：

使用的测试方法（手动、浏览器自动化、CLI）
使用的工具（qa-use、Playwright等）
发现的常见测试模式

使用AskUserQuestion询问：

问题	选项
"该项目暂无文档化的QA实践。是否需要我在CLAUDE.md中添加QA部分？"	1. 是，添加QA文档，2. 否，跳过此步骤

同时，若在多个QA会话中出现有用的模式，将其留存到内存中。

Review Integration

审核集成

File-review is on by default (unless Autopilot):

After the QA report is complete, invoke
```
/file-review:file-review <qa-report-path>
```
for inline human comments
Process feedback with the
```
file-review:process-review
```
skill

文件审核默认开启（自动驾驶模式除外）：

QA报告完成后，调用
```
/file-review:file-review <qa报告路径>
```
获取人工内联评论
使用
```
file-review:process-review
```
Skill处理反馈

Learning Capture

学习成果捕获

OPTIONAL SUB-SKILL: If significant insights, patterns, gotchas, or decisions emerged during this workflow, consider using

desplega:learning

to capture them via

/learning capture

. Focus on learnings that would help someone else in a future session.

可选子Skill：如果在此工作流中获得重要见解、模式、注意事项或决策，可考虑使用

desplega:learning

通过

/learning capture

捕获这些内容。重点记录能帮助他人在未来会话中提升效率的学习成果。

Workflow Handoff

工作流移交

After the QA report is complete, use AskUserQuestion with:

Question	Options
"QA complete. What's next?"	1. Run post-QA verification (→ `/verify-plan` ), 2. Run review on QA report (→ `/review` ), 3. Done

Based on the answer:

Verify: Invoke the
```
desplega:verifying
```
skill
Review: Invoke the
```
desplega:reviewing
```
skill on the QA document
Done: Finalize the QA report

QA报告完成后，使用AskUserQuestion询问：

问题	选项
"QA已完成。下一步做什么？"	1. 执行QA后验证（→ `/verify-plan` ），2. 对QA报告进行审核（→ `/review` ），3. 结束

根据回答执行：

验证：调用
```
desplega:verifying
```
Skill
审核：对QA文档调用
```
desplega:reviewing
```
Skill
结束：完成QA报告最终定稿