“应该可以了”和“已经验证通过”之间，差的是与结论对应的证据。这个 Skill 放在修复或开发即将结束时使用，要求 Agent 先运行能支撑结论的检查，读完整结果，再决定自己能准确说到哪一步。
安装并开始
在 Claude Code 会话内运行下面的插件命令，安装整套 Superpowers，保留各技能之间的衔接。Codex 用户在插件界面搜索并安装 Superpowers；两个客户端需要分别安装。安装后开启新会话，在项目目录里明确提出使用 verification-before-completion，再交代任务范围。
/plugin install superpowers@claude-plugins-official
先列出要证明的事
以下是可按项目调整的首次输入：
使用 Superpowers verification-before-completion 复核本次订单导出改动。先从需求列出必须证明的行为，再选择现有测试、类型检查和构建命令；实际运行并读完输出。报告每项结果及未验证范围，不把子代理的完成说明当成测试证据。
订单导出能生成文件、没有权限的用户被拒绝、构建可以完成，是三种不同结论。它们可能需要不同检查，不能用一次 lint 通过代替所有验证。让 Agent 从本次需求和实际改动出发选择必要证据，避免机械地跑一堆与问题无关的命令。
阅读新鲜、完整的结果
检查应针对当前代码运行，而不是引用改动前的日志。运行后确认退出状态、失败项与完整输出；只看最后一句或截取绿色部分，可能漏掉前面的错误。长时间命令仍在执行时，结果也不能提前写成通过。
修复缺陷时，还要确认回归测试确实能抓住原问题。新增功能则应逐条核对要求，尤其是权限、边界输入和失败分支。子代理说“完成”只能作为进度信息，最终仍要查看改动并得到可复核的执行结果。
报告结果，也报告边界
一份简明交付可以逐项写出做了什么检查、实际结果和覆盖范围。命令因缺少本地服务无法运行，就记录环境条件与尚未证明的部分；不要把“没看到错误”改写成“全部通过”。已有失败与本次新增失败应分开，便于判断是否阻塞交付。
对于界面改动，类型检查通常看不到焦点丢失、布局遮挡或错误提示位置；必要时加入真实交互。对于数据库迁移，空数据库通过不一定覆盖已有数据。检查方式应跟着风险和变更走，而不是固定使用一套口令。
最终目的不是永远加测试，而是在准备停止时让结论与证据一致。如果当前改动的必要检查已通过，也没有新问题，就可以收束。它不能保证没有遗漏的缺陷，却能避免把推测、旧日志或别人的口头结论包装成已经完成的验证。
用证据检查一次数据库迁移
若改动给用户表新增不可为空的状态字段，“迁移脚本在空数据库运行成功”只能证明初始建表路径。需要再准备含旧用户的数据库副本，运行迁移并检查旧记录的默认值、读写路径与回滚或恢复方案。相关 API 测试通过，也不能证明后台任务或报表查询已兼容新字段；按改动影响列出每种结论与对应检查。若生产数据不可复制，就用匿名化样本说明替代验证的覆盖边界。
交付时每句话只说已证实的范围：“迁移在含 500 条旧记录的测试库成功”“新用户注册与旧用户登录测试通过”；不要浓缩成“迁移绝对安全”。实际还未运行的命令、仍在执行的构建、失败的任务都单列。审查截图或 Agent 摘要可以帮助找线索，但不能代替新鲜的退出码、日志与数据检查。验证发现新问题后修改代码，受影响的检查要重新运行，旧的绿色结果不能直接复用。
确认输出来自真正的触发路径
运行检查还不够，要确认输出是谁产生的。一次真实调试中，使用者手动触发探针留下的日志，被误读为系统钩子自动运行；后来空日志又被误读为钩子未触发。验证“钩子已执行”时，先让手动探针与真实触发使用不同标识，再记录触发动作、时间、进程和写入路径。检查证据是否能区分这两条路径；若不能，就只报告“探针可写日志”，别推断业务钩子已运行。这个做法也适用于支付回调、后台任务和发布流程。