完成前验证

移植自 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 前、宣布任务完成前,以及任何关于工作状态的正面陈述。

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