何时使用
- 任何成功/完成声称
- 任何表达满意
- 任何关于工作状态的正向陈述
- 提交、PR、任务完成
- 委托给 Agent 后
完成前验证 (verification-before-completion)
完成前验证（verification-before-completion）
Section titled “完成前验证（verification-before-completion）”verification-before-completion 是 Superpowers 里最”诚实”的 Skill 之一。
它的核心原则非常简单：
证据在断言之前，永远如此。
很多开发者有一个坏习惯：
- 改了代码 → “应该能跑了”
- 跑了一下 → “看起来没问题”
- 测试跑过 → “应该通过了”
这种模式的问题在于：
- “应该”不是证据
- “看起来”不是验证
- 没有 freshly 运行的验证，就不能算验证
这个 Skill 明确要求：
如果你没有在这条消息里运行验证命令，你就不能声称它通过了。
门控函数（The Gate Function）
Section titled “门控函数（The Gate Function）”在声称任何状态或表达满意之前：
1. 识别：什么命令能证明这个说法？2. 运行：执行完整命令（新鲜的、完整的）3. 读取：完整输出，检查退出码，统计失败数4. 验证：输出是否确认了说法？ - 如果否：用证据说明实际状态 - 如果是：用证据说明声称5. 只有这样：才能做声称
跳过任何一步 = 说谎，而不是验证常见失败模式
Section titled “常见失败模式”| 声称 | 需要 | 不充分 |
|---|---|---|
| 测试通过 | 测试命令输出：0 failures | 之前运行、“应该能过” |
| Linter 干净 | Linter 输出：0 errors | 部分检查、推测 |
| 构建成功 | 构建命令：exit 0 | Linter 通过、日志看起来好 |
| Bug 修复 | 原始症状测试：pass | 代码改了、假设修好了 |
| 回归测试有效 | Red-green 周期验证 | 测试跑过一次 |
| Agent 完成 | VCS diff 显示变化 | Agent 报告”成功” |
| 需求满足 | 逐行检查清单 | 测试通过、阶段完成 |
常见错误与红旗
Section titled “常见错误与红旗”| 错误行为 | 为什么是错的 | 正确做法 |
|---|---|---|
| 使用”应该""大概""看起来” | 这些词没有证据支持 | 用输出结果说话 |
| 验证前表达满意 | 还没确定有什么好满意的 | 验证后再表达 |
| 信任 Agent 成功报告 | Agent 可能出错 | 自己检查 VCS diff |
| 依赖部分验证 | 部分验证 = 没有验证 | 运行完整验证 |
| 觉得”就这一次” | 规则没有例外 | 每次都要验证 |
| 累了想赶紧结束 | 疲劳不是借口 | 疲劳时更容易出错 |
✅ [运行测试命令] [看到: 34/34 通过] "所有测试通过"❌ "应该能过了" / "看起来正确"回归测试 (TDD Red-Green)
Section titled “回归测试 (TDD Red-Green)”✅ 写 → 运行 (通过) → 回滚修复 → 运行 (必须失败) → 恢复 → 运行 (通过)❌ "我写了回归测试" (没有 red-green 验证)✅ [运行构建] [看到: exit 0] "构建通过"❌ "Linter 通过了" (linter 不检查编译)✅ 重读计划 → 创建检查清单 → 验证每项 → 报告缺口或完成❌ "测试通过，阶段完成"Agent 委托
Section titled “Agent 委托”✅ Agent 报告成功 → 检查 VCS diff → 验证变化 → 报告实际状态❌ 信任 Agent 报告原文的设计哲学
Section titled “原文的设计哲学”这个 Skill 的核心观点非常直接：
声称完成而不验证，等同于欺骗。
它指出了一个在团队协作中非常常见的问题：
- 开发者说”修好了”
- 其他人或系统相信了
- 结果上线后出问题
- 信任被破坏
verification-before-completion 的目标就是在”声称”和”现实”之间架起一座桥梁：
- 先运行
- 再看输出
- 再说话
这看起来是常识，但在实际工作中：
- 时间紧迫时容易跳过
- 熟悉代码时容易假设
- 累的时候容易偷懒
这个 Skill 用非常强硬的语气把这些”合理化”全部堵死。
与日常开发的关联
Section titled “与日常开发的关联”你一定见过这类情况：
- “我刚才改了，应该没问题” —— 结果编译失败
- “测试应该能跑过” —— 结果跑挂了
- “Linter 过了，构建没问题” —— 结果构建报错
- “Agent 说成功了” —— 结果只做了第一步
这些都是因为跳过了”fresh verification”这一步。verification-before-completion 的价值就是强制你在每一步都说真话。
实际使用场景举例
Section titled “实际使用场景举例”场景 1：修复后声称 Bug 已解决
Section titled “场景 1：修复后声称 Bug 已解决”错误做法：
- 改了代码
- “应该修好了”
正确做法：
- 运行复现 Bug 的测试
- 确认测试通过
- 再声称”修复完成”
场景 2：测试通过后声称可以提交
Section titled “场景 2：测试通过后声称可以提交”错误做法：
- “测试跑过了，应该没问题”
正确做法：
- 运行完整测试套件
- 确认 0 failures
- 再提交
场景 3：Agent 任务完成后声称完成
Section titled “场景 3：Agent 任务完成后声称完成”错误做法：
- Agent 报告”success”
正确做法：
- 检查 VCS diff 确认有实际代码变化
- 验证变化是否符合预期
- 再声称”完成”
关键要点
- 必须运行验证命令
- 必须看完整输出
- 用证据说话，不是用”应该”
- Agent 报告不能替代自己验证
禁止的措辞
- “应该”
- “大概”
- “看起来”
- “可能”
- “我相信”
- 任何在验证前的满意表达
正确做法
- [运行命令] → [看到输出] → “X 测试通过”
- 先运行，再声称
- 证据在断言之前
关联 Skill
Section titled “关联 Skill”- 前置：
test-driven-development（写失败测试）和systematic-debugging（修复后验证）。 - 互补：
using-git-worktrees（在干净环境验证）、finishing-a-development-branch（分支完成前的最后验证）。
查看源文件: GitHub原始文件