verifying

验证

你正在对计划进行实施后审查，将计划与实际变更交叉核对，确保没有遗漏、没有过时内容，并且实施符合计划。

协作约定

所有面向用户的问题都通过 AskUserQuestion 提出——有关约定，请参阅 desplega:ask-user。

所有读取、研究和验证工作都通过子 Agent 完成——默认设置 run_in_background: true。

默认启用文件审查（Autopilot 模式除外）——准备好验证报告后，对其进行审查。

适用场景

在以下情况下，此技能会启用：

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

自主模式

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

模式	行为
Autopilot	执行所有检查、更新计划，并在最后汇报摘要
Critical（默认）	就差异和阻碍项提问
Verbose	逐项检查并确认解释

自主模式由调用命令传入。如果未指定，默认使用 Critical。

流程步骤

第 1 步：加载计划

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

1. 在 thoughts/*/plans/ 中搜索状态为 in-progress 或 completed 的计划
2. 如果找到多个计划，使用 AskUserQuestion 让用户选择
3. 如果未找到计划，报告并停止

第 2 步：复选框审查

解析计划中的所有 - [ ] 和 - [x] 项。报告：

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

标出仍未勾选的自动化验证项或自动化 QA 项——实施技能或阶段执行技能应当勾选这些项。

第 3 步：Git Diff 关联核对

检查计划的 frontmatter 中是否有 git_commit 字段。

如果存在 git_commit：

1. 运行 git diff <git_commit>..HEAD --name-only 获取变更文件
2. 提取计划中“Changes Required”部分提及的所有文件路径
3. 进行比较并标出：
   • 意外变更：已变更但未在计划中提及的文件
   • 实施缺失：计划中提及但未发生变更的文件

如果不存在 git_commit：

• 跳过此步骤，并注明：“计划 frontmatter 中没有 git_commit——跳过 Git diff 关联核对”

如果当前分支与计划所属分支不同：

• 注明分支差异，并尽可能进行比较

第 4 步：范围验证

阅读计划中的“What We're NOT Doing”部分。检查 git diff，查找范围蔓延的迹象：

• 查找与明确排除在范围之外的事项相关的文件或模式
• 检查是否有提交涉及范围外功能

对此应采取保守判断——只标出明确的范围违规，不标出边界情况。

第 5 步：重新运行成功标准

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

自动化验证（命令）：

1. 提取每个复选框项目中的命令
2. 重新运行每条命令
3. 报告通过／失败

自动化 QA（由 Agent 驱动的场景）：

1. 使用合适的工具（browser-use、截图差异、CLI 演练）重新执行每个场景
2. 按场景报告通过／失败

边缘情况（适用于两者）：

• 跳过引用的文件或路径显然已不存在的项目
• 如果某项失败，记录错误／输出并纳入报告
• 不要重新运行会造成破坏或修改状态的项目——只执行只读检查
• 如果某个阶段的 QA 规范链接到外部 QA 文档，请在报告中注明其路径；重新运行该文档是 qa 技能的职责，不属于此技能

可选子技能： 如果缺少验证命令、命令不稳定，或输出过于冗长以至于重新运行会污染报告，请调用 desplega:script-builder 将其封装为可重复运行的脚本。生成的脚本会强制输出 PASS／FAIL，并将日志写入 /tmp，让后续验证只需返回一行简洁结果，而不是整屏标准输出。封装后的命令仍保留在计划中；后续验证会通过 script-builder 添加到 CLAUDE.md 的 <important if> 块发现新脚本。

第 6 步：检查计划时效性

将阶段描述与实际实现进行比较：

• 计划中的文件路径是否仍然准确？
• “需要进行的更改”描述是否与实际完成的工作一致？
• 实施过程中是否对任何阶段进行了重大调整？

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

第 7 步：验证报告

按以下类别呈现结果：

类别	含义	示例
阻塞项	必须解决后才能将计划标记为完成	未勾选的自动化项目、失败的成功标准
警告	应进行审查，但不妨碍完成	意外变更的文件、可能超出范围
信息	仅供参考，无需采取行动	过时的描述、轻微不一致、分支差异

第 8 步：更新状态

如果所有阻塞项都已解决：

• 提议将计划 frontmatter 中的 status: completed
• 更新 last_updated 和 last_updated_by 字段

如果仍有阻塞项：

• 清楚列出并建议后续步骤

经验总结

可选子技能： 如果此工作流中出现了重要见解、模式、注意事项或决策，可考虑使用 desplega:learning 通过 /learning capture 记录。重点记录有助于他人在未来会话中开展工作的经验。

与审查技能集成

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

问题	选项
“验证已完成。接下来要做什么？”	1. 运行 QA（→ /qa），2. 运行审查（→ /review），3. 完成

审查集成

默认启用文件审查（Autopilot 除外）：

• 验证报告完成后，调用 /file-review:file-review <plan-path> 添加行内人工评论
• 使用 file-review:process-review 技能处理反馈