verifying

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Verifying

验证工作

You are performing a post-implementation audit of a plan, cross-referencing it against actual changes to ensure nothing was missed, nothing is stale, and the implementation matches what was planned.

你正在对一项计划进行实施后审计，将其与实际变更进行交叉比对，确保没有遗漏内容、没有过时信息，且实施内容与计划一致。

Working Agreement

工作约定

All user-facing questions go through
AskUserQuestion
— see

desplega:ask-user

for conventions.

All read/research/validation work goes through sub-agents — default to

run_in_background: true

File-review is on by default (unless Autopilot) — invoke it on the verification report when ready.

所有面向用户的问题需通过
AskUserQuestion
提交——相关规范请查看

desplega:ask-user

。

所有读取/调研/验证工作需通过子代理执行——默认设置

run_in_background: true

。

文件审核默认开启（自动驾驶模式除外）——准备就绪后，在验证报告中调用该功能。

When to Use

使用场景

This skill activates when:

User invokes
```
/verify-plan
```
command
The implementing skill offers verification at completion
User asks to audit or verify a completed plan

当出现以下情况时，激活该技能：

用户调用
```
/verify-plan
```
命令
实施技能在完成时提供验证选项
用户要求审核或验证已完成的计划

Autonomy Mode

自主模式

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

Mode	Behavior
Autopilot	Run all checks, update plan, report summary at end
Critical (Default)	Ask about discrepancies and blocking items
Verbose	Walk through each check, confirm interpretation

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

验证开始时，根据自主模式调整交互级别：

模式	行为
自动驾驶模式（Autopilot）	运行所有检查，更新计划，最终提交总结报告
关键模式（Critical）（默认）	询问差异情况与阻塞项
详细模式（Verbose）	逐一讲解每项检查，确认解读内容

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

Process Steps

流程步骤

Step 1: Load Plan

步骤1：加载计划

Read the plan fully. If no path provided:

Search for plans with

status: in-progress

status: completed

thoughts/*/plans/

If multiple found, use AskUserQuestion to let the user choose
If none found, report and stop

完整读取计划。若未提供路径：

在

thoughts/*/plans/

目录中搜索状态为

status: in-progress

或

status: completed

的计划

若找到多个计划，使用 AskUserQuestion 让用户选择
若未找到任何计划，提交报告并终止流程

Step 2: Checkbox Audit

步骤2：复选框审计

Parse all

- [ ]

and

- [x]

items in the plan. Report:

Metric	Description
Total items	Count of all checkbox items
Checked items	Count of `- [x]` items
Unchecked Automated Verification	Items under `#### Automated Verification:` still unchecked
Unchecked Automated QA	Items under `#### Automated QA:` still unchecked
Unchecked Manual Verification	Items under `#### Manual Verification:` still unchecked

Flag any Automated Verification or Automated QA items that are still unchecked — these are expected to be checked by the implementing/phase-running skills.

解析计划中所有

- [ ]

和

- [x]

项。提交以下指标报告：

指标	描述
总项数	所有复选框项的数量
已勾选项	`- [x]` 项的数量
未勾选的自动化验证项	`#### Automated Verification:` 下仍未勾选的项
未勾选的自动化QA项	`#### Automated QA:` 下仍未勾选的项
未勾选的手动验证项	`#### Manual Verification:` 下仍未勾选的项

标记所有仍未勾选的自动化验证或自动化QA项——这些项应由实施/阶段执行技能完成勾选。

Step 3: Git Diff Correlation

步骤3：Git Diff关联校验

Check the plan's frontmatter for a

git_commit

field.

If
git_commit
exists:

Run
```
git diff <git_commit>..HEAD --name-only
```
to get changed files
Extract all file paths mentioned in the plan's "Changes Required" sections
Compare and flag:
- Unexpected changes: Files changed that aren't mentioned in the plan
- Missing implementation: Files mentioned in the plan that weren't changed

If
git_commit
does not exist:

Skip this step with a note: "No git_commit in plan frontmatter — skipping git diff correlation"

If on a different branch than the plan:

Note the branch difference and proceed with best-effort comparison

检查计划前置元数据中的

git_commit

字段。

若存在
git_commit
：

执行
```
git diff <git_commit>..HEAD --name-only
```
获取变更文件列表
提取计划中“所需变更”部分提及的所有文件路径
对比并标记：
- 意外变更：计划中未提及但已变更的文件
- 缺失的实施内容：计划中提及但未变更的文件

若不存在
git_commit
：

跳过此步骤并添加说明：“计划前置元数据中无 git_commit —— 跳过Git Diff关联校验”

若当前分支与计划分支不同：

记录分支差异信息，然后尽可能进行对比

Step 4: Scope Verification

步骤4：范围验证

Read the "What We're NOT Doing" section of the plan. Search the git diff for evidence of scope creep:

Look for files or patterns related to explicitly out-of-scope items
Check if any commits reference out-of-scope functionality

Be conservative here — flag only clear scope violations, not borderline cases.

读取计划的“我们不会做的内容”部分。在Git Diff中搜索范围蔓延的证据：

查找与明确标注为超出范围的项相关的文件或模式
检查是否有提交记录涉及超出范围的功能

在此步骤中需保持谨慎——仅标记明确的范围违规项，而非边缘情况。

Step 5: Success Criteria Re-run

步骤5：成功标准重检

For each phase's Success Criteria, re-run both runnable buckets:

Automated Verification (commands):

Extract the commands from each checkbox item
Re-run each command
Report pass/fail

Automated QA (agent-driven scenarios):

For each scenario, re-execute via the appropriate tool (browser-use, screenshot diff, CLI walkthrough)
Report pass/fail per scenario

Edge cases (apply to both):

Skip items that reference files or paths that clearly no longer exist
If an item fails, capture the error/output for the report
Don't re-run destructive or state-modifying items — only read-only checks
If a phase's QA Spec links to an external QA doc, note its path in the report; re-running that doc is the qa skill's job, not this one's

OPTIONAL SUB-SKILL: When a verification command is missing, flaky, or so verbose that re-running it pollutes the report, invoke

desplega:script-builder

to wrap it into a re-runnable script. The generated script enforces PASS/FAIL +

/tmp

log output, so future verifications get a clean single-line result instead of a wall of stdout. The wrapped command stays in the plan; subsequent verifications discover the new script via the

<important if>

block script-builder adds to CLAUDE.md.

针对每个阶段的成功标准，重新运行两类可执行检查：

自动化验证（命令）：

从每个复选框项中提取命令
重新执行每个命令
报告通过/失败结果

自动化QA（代理驱动场景）：

针对每个场景，通过相应工具重新执行（浏览器操作、截图对比、CLI流程演示）
按场景报告通过/失败结果

边缘情况（适用于上述两类检查）：

跳过引用已明确不存在的文件或路径的项
若某项失败，捕获错误/输出信息并纳入报告
不要重新执行破坏性或修改状态的项——仅执行只读检查
若某阶段的QA规范链接到外部QA文档，在报告中记录其路径；重新执行该文档是QA技能的工作，而非本技能的职责

可选子技能： 当验证命令缺失、不稳定或过于冗长导致报告混乱时，调用

desplega:script-builder

将其封装为可重复运行的脚本。生成的脚本会强制输出 PASS/FAIL 结果 +

/tmp

日志，以便后续验证时获得简洁的单行结果，而非大量标准输出内容。封装后的命令会保留在计划中；后续验证会通过CLAUDE.md中script-builder添加的

<important if>

块发现新脚本。

Step 6: Plan Freshness Check

步骤6：计划时效性检查

Compare phase descriptions against actual implementation:

Are file paths in the plan still accurate?
Do the "Changes Required" descriptions match what was actually done?
Were any phases adapted significantly during implementation?

Flag phases where the description no longer matches reality as stale.

对比阶段描述与实际实施内容：

计划中的文件路径是否仍然准确？
“所需变更”的描述是否与实际执行内容一致？
实施过程中是否对某些阶段进行了重大调整？

将描述与实际情况不符的阶段标记为过时。

Step 7: Verification Report

步骤7：验证报告

Present findings categorized as:

Category	Meaning	Examples
Blocking	Must be resolved before plan can be marked complete	Unchecked automated items, failing success criteria
Warning	Should be reviewed but don't block completion	Unexpected files changed, potential scope creep
Info	Informational, no action needed	Stale descriptions, minor mismatches, branch differences

按以下类别呈现检查结果：

类别	含义	示例
阻塞项	计划标记为完成前必须解决的问题	未勾选的自动化项、未通过的成功标准
警告项	需复查但不影响完成的问题	意外变更的文件、潜在的范围蔓延
信息项	仅作信息告知，无需采取行动	过时的描述、微小差异、分支差异

Step 8: Status Update

步骤8：状态更新

If all blocking items are resolved:

Offer to set plan
```
status: completed
```
in frontmatter
Update
```
last_updated
```
and
```
last_updated_by
```
fields

If blocking items remain:

List them clearly and suggest next steps

若所有阻塞项均已解决：

提议将计划前置元数据中的
```
status: completed
```
设置为完成状态
更新
```
last_updated
```
和
```
last_updated_by
```
字段

若仍存在阻塞项：

清晰列出这些项并建议后续步骤

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.

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

desplega:learning

通过

/learning capture

命令捕获这些内容。重点记录能帮助他人在未来工作中避免问题的经验。

Integration with Reviewing Skill

与审核技能的集成

After verification completes, use AskUserQuestion with:

Question	Options
"Verification complete. What's next?"	1. Run QA (→ `/qa` ), 2. Run review (→ `/review` ), 3. Done

验证完成后，使用 AskUserQuestion 询问：

问题	选项
"验证已完成。下一步操作？"	1. 运行QA（→ `/qa` ），2. 运行审核（→ `/review` ），3. 完成

Review Integration

审核集成

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

After the verification report, invoke
```
/file-review:file-review <plan-path>
```
for inline human comments
Process feedback with the
```
file-review:process-review
```
skill

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

验证报告生成后，调用
```
/file-review:file-review <plan-path>
```
获取人工 inline 评论
使用
```
file-review:process-review
```
技能处理反馈意见