# Verification Before Completion

> 在说出任何"完成了/修好了/应该能用了/测试通过了"之前使用。任何完成声明都必须有刚刚跑出来的、亲眼读过的证据,不许靠推断或感觉。这是刚性 skill。

- Skill: `itmisx/verification-before-completion` (Agent Skill)
- Install (CLI): `npx skillmds@latest add itmisx/verification-before-completion`
- Raw SKILL.md: https://api.skillmd.com/api/skills/itmisx/verification-before-completion/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: itmisx (https://skillmd.com/u/itmisx)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/itmisx/verification-before-completion

---


# 完成前验证

> 移植自 [superpowers](https://github.com/obra/superpowers)(MIT)。这是**刚性** skill。

**铁律**:没有刚跑出来的验证证据,不许声称完成。

## 闸门流程

在说出任何状态结论之前,按顺序走完五步:

1. 想清楚:用哪条命令能验证这件事?
2. 用 `Bash` **完整、重新**跑一遍(不是翻旧输出)。
3. 读完整输出和退出码。
4. 确认输出**确实**支撑你要说的结论。
5. 此时才能说结论,并附上证据。

## 禁止的偷懒

- 用"应该好了"代替真的跑测试。
- 验证前就先表达满意/松口气。
- 不独立确认,直接信子 agent 的汇报。
- 部分验证后外推全部(只跑了一个用例就说"都过了")。
- 任何"暗示成功但没真跑验证"的措辞。

## 红旗——停
- 有信心但拿不出证据。
- 累了,想"就这一次直接说完成吧"。
- "这么小的改动肯定没问题"。

**违反这条规则的字面,就是违反它的精神**——换个说法绕过去不算例外。

## 验证常驻服务 / web 应用

服务器、watch、daemon 这类**永不退出**的进程,不能用前台 `Bash` 跑(会一直阻塞到超时,还甩出孤儿进程)。正确套路:

1. **后台启动**:`Bash` 传 `run_in_background: true`,拿到句柄 id(形如 bash_1)。
2. **等就绪再探活**:服务不会立刻起来。用 `BashOutput(id)` 读输出,确认监听成功(或日志出现 ready);别一启动就探,太早会连接被拒、误判成"坏了"。
3. **真探活**:用前台 `Bash` 跑 `curl -s localhost:<port>`(或对应健康检查),**读响应内容**,确认是预期的,而不是看见进程起来了就说"完成"。
4. **收尾**:`KillBash(id)` 结束,释放端口。验证完不 kill 会留下孤儿、占住端口。

"服务起来了" ≠ "应用好使了"。没经过第 3 步拿到真实响应,就不算验证过。

## 适用范围

提交前、提 PR 前、宣布任务完成前,以及**任何**关于工作状态的正面陈述。

为什么:假的完成声明会摧毁信任,逼得别人花时间复查、返工、纠偏——比一开始就老实验证贵得多。