| name | verify |
| description | 当用户要验证、确认完成、收尾、检查是否做完，或 implement 实现完成后使用。对照 spec 的 DoD 逐条验证，运行测试，端到端跑通。高回报。关键词：验证、确认完成、收尾、verify、测一下、跑通、做完了吗。
|
verify — 完成前验证（做对了吗）
触发词
验证、确认完成、收尾、verify、测一下、跑通、做完了吗、检查、验收
概述
在声明"做完了"之前，对照 spec.md 的完成标准（DoD）逐条验证，跑测试，端到端走一遍。这是 Anthropic 实测对 agent 输出质量提升最明显的一类 skill——会自己验收的 agent 和只会交作业的 agent，是两个物种。
何时该用
- implement 完成后，声明"做完了"之前
- 用户问"做完了吗""能用了吗"
- 任何节点要确认某功能是否真的可用
工作流
1. 读 spec.md 的 DoD
把 spec.md 里每个功能的"完成标准（DoD）"列出来。这是验收清单。
若无 spec（小修小补），基于用户最初的需求提炼出可验证的检查点。
2. 逐条验证 DoD
对每条 DoD：
- 明确怎么验：跑哪个测试 / 执行什么命令 / 手动操作什么
- 实际执行：不要"我觉得应该没问题"，要真跑
- 记录结果：通过 / 失败 / 未覆盖
没有验证手段的 DoD = 无法确认完成。先补一个能跑的检查（哪怕一个 assert）。
3. 运行测试
- 跑项目已有测试套件
- 若 implement 产生了新逻辑但没测试，补一个最小的可运行检查（见 coding_principles "留一个可运行的检查"）
- 用
scripts/smoke_test.template 快速搭冒烟测试
4. 端到端走核心流程
不只是单元测试通过，还要把用户视角的核心流程完整走一遍：
- 从入口开始，按真实使用路径操作
- 每一步断言状态符合预期
- 失败的步骤记录下来
例：登录功能——不只测"密码校验函数返回 true"，要真跑"输入账号密码 → 点登录 → 成功跳首页 / 失败显提示"。
5. 产出验证报告
在 .agents/specs/{feature}/verification.md 写入：
# 验证报告
## DoD 逐条验证
| DoD | 验证方式 | 结果 |
|-----|---------|------|
| 用户可用账号密码登录 | 跑 test_login.py | ✅ 通过 |
| 登录失败有提示 | 手动输入错密码 | ✅ 通过 |
| 成功跳首页 | 端到端走一遍 | ❌ 失败：跳转目标写错 |
## 测试结果
- 单元测试：N 通过 / M 失败
- 冒烟测试：通过 / 失败
## 端到端核心流程
1. [步骤1] → ✅
2. [步骤2] → ❌ {问题描述}
## 未通过项
- {问题} → 需修复
## 结论
- [ ] 全部通过，可声明完成
- [x] 有未通过项，需修复后重验
6. 报告给用户
- 全通过：明确说"已验证完成"，列出验证了什么。
- 有失败：列出失败项，问用户是修复还是记为已知问题。
坑点清单（Gotchas）
- "我觉得应该没问题"：没真跑就说通过 = 假验收。每条 DoD 都要实际执行验证。
- 只跑单元测试不跑端到端：单元测试通过不代表用户流程能走通。
- DoD 不可验证：spec 写"支持登录"没法验，要"输入账号密码→成功跳首页→失败显提示"才可验。
- 新逻辑没测试：implement 写了新代码但没留检查，verify 时无法确认。
- 不产出报告：只在对话说"测了没问题"，没存 verification.md，无法追溯。
- 声明完成却留未通过项：失败项要么修要么明确标"已知问题"，不能藏起来。
关键规则
- 必须对照 spec 的 DoD 逐条验证，每条都要实际执行。
- 必须跑测试 + 端到端走核心流程。
- 必须产出 verification.md 存档。
- 未通过项必须修复或明确标注，不得隐藏。
- 声明"完成"前必须本 skill 通过。
脚本
scripts/smoke_test.template — 通用冒烟测试模板（复制后按项目改）
参考
.agents/rules/coding_principles.md 第四章 Goal-Driven Execution- 上游 skill：
implement（实现）
- 相关 skill：
diagnosing-bugs（验证失败时排查复杂 bug）；简单 bug 走 anti-hallucination Step 5 轻量 log
