skills/superpowers/verification-before-completion/SKILL.md
在你准备声称“已完成/已修复/已通过”之前使用(尤其在 commit 或提 PR 前):必须运行 verification 命令并核对输出;永远 Evidence before assertions。
npx skillsauth add lyfe2025/lyfes-coding-skills verification-before-completionInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
不做验证就声称完成,不是效率,而是失信。
核心原则: 永远先给证据(evidence),再做断言(claim)。
只遵守字面、不遵守精神,就是在违反这条规则。
没有新的验证证据,就不能做“完成/通过”的声明
如果你没有在“当前这条消息/当前这次操作”里运行验证命令,就不能声称它通过。
在声称任何状态或表达满意之前:
1. IDENTIFY:什么命令能证明你的说法?
2. RUN:执行完整命令(fresh、完整)
3. READ:阅读完整输出,检查 exit code,统计失败数
4. VERIFY:输出是否真的支持你的结论?
- NO:如实说明当前状态,并给出证据
- YES:带证据给出结论
5. ONLY THEN:再做声明
漏一步 = 在撒谎(不是在验证)
| 声明 | 需要的证据 | 不够的证据 | |------|------------|------------| | 测试通过 | 测试命令输出:0 failures | 之前跑过、“应该能过” | | Linter 干净 | linter 输出:0 errors | 只跑了部分检查、凭感觉外推 | | Build 成功 | build 命令:exit 0 | linter 过了、日志看起来不错 | | Bug 修复了 | 复现原症状:通过 | 代码改了、假设修好了 | | Regression test 有效 | 验证过 TDD red-green cycle | 测试只跑过一次 | | Agent 完成了 | VCS diff 展示了变更 | agent 口头“成功” | | 满足需求 | 逐条 checklist 验证 | 仅仅“测试过了” |
| 借口 | 现实 | |------|------| | “现在应该能行了” | 去跑验证 | | “我很有把握” | 信心 ≠ 证据 | | “就这一次” | 没有例外 | | “linter 过了” | linter ≠ compiler/build | | “agent 说 OK 了” | 你要独立验证 | | “我太累了” | 疲惫 ≠ 免检 | | “部分检查够了” | 部分不能证明整体 | | “换个说法就不算” | 以精神为准,不钻字眼 |
Tests:
✅ [运行测试命令] [看到:34/34 pass] “测试全部通过”
❌ “现在应该能过了” / “看起来没问题”
Regression tests(TDD Red-Green):
✅ 写测试 → 跑(通过)→ 回滚修复 → 再跑(必须失败)→ 恢复修复 → 再跑(通过)
❌ “我写了回归测试”(但没验证 red-green)
Build:
✅ [运行 build] [看到:exit 0] “Build 通过”
❌ “linter 过了”(linter 不保证能编译/打包)
Requirements:
✅ 重读 plan → 做 checklist → 逐条验证 → 汇报缺口或完成
❌ “测试过了,这个阶段完成了”
Agent delegation:
✅ agent 汇报成功 → 检查 VCS diff → 验证变更 → 如实汇报状态
❌ 直接相信 agent
来自真实失败案例的教训:
永远在以下情况之前使用:
规则覆盖:
验证没有捷径。
跑命令,读输出,然后再做结论。
不可协商。
tools
在编写 skill 内容、验证 skill 是否有效、或需要用 TDD 方法测试 skill 能否被正确遵守时使用。
tools
当你有 spec/requirements 且任务需要多步推进时使用;在动代码之前先写出可执行的 implementation plan。
tools
在任何对话开始时使用:建立“如何发现并使用 skills”的规则,要求在任何回应(包括澄清问题)之前先 invoke Skill tool。
tools
当你要开始需要与当前 workspace 隔离的 feature 开发,或在执行 implementation plan 之前使用:创建隔离的 git worktree,并包含目录选择与安全校验。