bm-verification

name	bm.verification
description	完成前自验证：声明 done 之前必须列检查清单、跑一遍、看结果。Use before claiming a task is complete, finished, ready, done, 完成, 搞定, 做完, 跑通, ready, done, finish, complete. 防止虚假完成、自欺欺人、提交破损产物。
source	opencrew
version	20260521.01

Skill: Verification（完成前自验证）

声明"完成"之前，agent 必须自己跑一遍验证，列证据，不是嘴上说"我做完了"。

适用于代码、文档、设计、报告、配置——任何要交付的产物。

---

触发时机

强制触发：当 agent 准备说以下任何话之前——

• "我已经完成了 X"
• "X 修好了"
• "可以了，你试试"
• "搞定，已经写入 Y"
• "需求都实现了"
• "Done"

不触发：

• 用户明确说"先这样吧，我自己看"
• 中间产物，未声明完成

---

三步法

Step 1：列检查清单

根据这次任务的目标，列出可验证的检查项。每条必须是：

• 客观：能用证据回答 yes/no，不是主观判断
• 具体：不是"功能正常"，是"运行 X 命令返回 0"
• 可执行：你（agent）当场就能验证

清单举例：

写代码：

• 文件已写入预期路径（用 ls 或读文件验证）
• 语法正确（lint / typecheck 通过）
• 关键行为符合 spec（跑测试或手动调用）
• 没改坏其他文件（git diff 看一下范围）

写文档：

• 长度 / 结构符合要求
• 涉及的事实是从源材料来的，不是编的
• 链接 / 文件路径都能打开
• 用户提的关键点都覆盖了

修 bug：

• 复现步骤现在不再触发问题
• 没引入回归（相关测试通过）
• 修的是根因不是症状

配置/安装：

• 配置文件是合法格式（json/yaml 解析通过）
• 服务/工具能起来
• 用一个最小用例验证生效

Step 2：实际跑一遍

真的执行，不是想象。常用动作：

产物类型	验证动作
代码	跑测试 / lint / typecheck / 实际调用一次
脚本	在 sample 输入上跑一次
文档	通读一次，检查链接和事实
配置	让目标程序加载这个配置
数据/报告	抽样检查若干条目

记录每个检查项的实际证据：

• 命令的 exit code 和输出片段
• 文件实际内容片段
• 截图 / 日志关键行

Step 3：呈现验证报告

呈现给用户的格式：

## 完成报告

**做了什么**：一句话说做了啥。

**验证结果**：
- ✅ 文件写入 ./output/report.md（138 行）
- ✅ Markdown lint 通过（0 errors）
- ✅ 所有链接可访问（5/5）
- ⚠️ 一处 [需确认]：原始资料里 X 项数据缺失，已标注

**证据**：
\```
$ wc -l output/report.md
138 output/report.md

$ markdownlint output/report.md
（无输出，通过）
\```

**未覆盖**：
- 没做 Y，因为超出范围

**下一步建议**：
- 你可能想检查一下 ⚠️ 那条

---

反模式（绝对不要这样）

反模式	为什么错	正确做法
"应该可以了" / "理论上没问题"	没真跑过	必须跑
跑了一次没报错就认为 OK	没看输出，可能是 silent failure	看实际输出对照预期
自己觉得对就报完成	主观，不可信	给客观证据
验证时降低标准	自欺	验证标准 = 任务标准
报告"全部完成"但有项跳过	误导用户	跳过的项明确标注，给原因
失败的项藏起来	用户后面发现更糟	失败项用 ❌ 明确报告，给修复建议

---

边界情况

验证失败时：

• 不要硬报"完成"
• 报告"部分完成"或"未完成"，列出失败项和你的判断（继续修 / 需要用户决策）

无法验证时（比如需要外部环境）：

• 明确说"我无法本地验证 X，因为 Y"
• 给用户简单的验证步骤："请你跑一下 Z，看输出是不是 ..."

验证成本太高时（比如要部署到生产）：

• 退一步：在 staging / 本地复现一个等价场景验证
• 不能验证的部分明确标记

---

与其他 skill 的协作

• 任务起点用 bm.brainstorming 定的 spec → 验证 = 对照 spec 的成功标准
• 出错了 → 切到 bm.systematic-troubleshooting 排查根因
• 用户视角 review → bm.voice-of-user

---

文件落点

验证证据/日志 → ./working/verification-{task}.log，必要时附在报告里。