Verification Before Completion

jnMetaCode/superpowers-zh/skills/verification-before-completion

作者 jnMetaCode2daf57c0fb157521de24c62ac9c3254630eefbedMIT收录于 2026年10月9日更新于 2026年10月9日

在宣称工作完成、已修复或测试通过之前使用,在提交或创建 PR 之前——必须运行验证命令并确认输出后才能声称成功;始终用证据支撑断言

AI 生成的概览

要求在宣称任务完成、已修复或测试通过之前,先运行新的验证命令并引用其输出。

功能
该技能规定了一套在宣布成功之前验证工作的纪律。它给出一个门控流程:确定能证明结论的命令,完整运行它,阅读完整输出与退出码,只有在输出支持结论时才下结论。它还列出常见失败模式、红线措辞与防止合理化的对照,并给出测试、回归红绿循环、构建、需求核对清单和代理委派等场景的模式。
适用场景
在任何成功、完成或满意的表述之前使用,也在提交、推送、创建 PR 或标记任务完成之前使用。委派给代理后需要独立确认其报告结果时同样适用。
运行要求
不附带脚本或工具,仅为指令。它假定代理能够运行测试、linter、构建等验证命令,并能查看版本控制差异。

完成前验证

概述

核心原则: 始终用证据支撑结论。

对这条规则敷衍了事,就等于违背了它的精神。

铁律

没有新鲜的验证证据,不许宣称完成

如果你在这条消息中没有运行验证命令,就不能声称测试通过。

门控函数

在宣称任何状态或表达满意之前:
1. 确定:什么命令能证明这个结论?2. 运行:执行完整命令(重新运行,完整执行)3. 阅读:完整输出,检查退出码,统计失败数4. 验证:输出是否支持这个结论?   - 如果否:用证据说明实际状态   - 如果是:带证据陈述结论5. 只有这时:才能做出结论
跳过任何一步 = 说谎,不是验证

常见失败模式

结论需要不够格
测试通过测试命令输出:0 failures之前的运行结果、"应该会通过"
Linter 无报错Linter 输出:0 errors部分检查、推断
构建成功构建命令:exit 0linter 通过、日志看起来没问题
Bug 已修复测试原始症状:通过代码改了,假设已修复
回归测试有效红-绿循环已验证测试只通过了一次
代理已完成VCS diff 显示变更代理报告"成功"
需求已满足逐项核对清单测试通过

红线——停下来

  • 使用"应该"、"大概"、"似乎"
  • 验证前就表达满意("太好了!"、"完美!"、"搞定!"等)
  • 即将提交/推送/创建 PR 却没有验证
  • 信任代理的成功报告
  • 依赖部分验证
  • 想着"就这一次"
  • 累了想赶紧收工
  • 任何暗示成功但实际未运行验证的措辞

防止合理化

借口现实
"应该能行了"运行验证命令
"我有信心"信心 ≠ 证据
"就这一次"没有例外
"Linter 通过了"Linter ≠ 编译器
"代理说成功了"独立验证
"我累了"疲劳 ≠ 借口
"部分检查就够了"部分检查什么也证明不了
"换个说法这条规则就不适用了"精神大于字面

关键模式

测试:

✅ [运行测试命令] [看到:34/34 pass] "全部测试通过"❌ "应该能通过了" / "看起来对了"

回归测试(TDD 红-绿):

✅ 编写 → 运行(通过)→ 回退修复 → 运行(必须失败)→ 恢复 → 运行(通过)❌ "我写了回归测试"(没有经过红-绿验证)

构建:

✅ [运行构建] [看到:exit 0] "构建通过"❌ "Linter 通过了"(linter 不检查编译)

需求:

✅ 重读计划 → 创建核对清单 → 逐项验证 → 报告缺口或完成❌ "测试通过了,阶段完成"

代理委派:

✅ 代理报告成功 → 检查 VCS diff → 验证变更 → 报告实际状态❌ 信任代理报告

何时使用

以下情况之前必须使用:

  • 任何形式的成功/完成声明
  • 任何满意的表达
  • 任何关于工作状态的正面陈述
  • 提交、创建 PR、标记任务完成
  • 进入下一个任务
  • 委派给代理

本规则适用于:

  • 准确措辞
  • 同义词和换一种说法
  • 暗示成功
  • 任何传达完成/正确性的沟通

来源与署名

来源:jnMetaCode/superpowers-zh位于skills/verification-before-completion提交2daf57c

许可证: MIT

内容归原作者所有。SourceWeft 从公开仓库中收录这些内容。

举报或申请下架