在宣称工作完成、已修复或测试通过之前使用，在提交或创建 PR 之前——必须运行验证命令并确认输出后才能声称成功；始终用证据支撑断言
Send this to Claude Code, Codex or Cursor. The agent checks the Skill for safety first and installs it only after you confirm.
读取 https://funcoding.ai/skills/jnmetacode/superpowers-zh/verification-before-completion/install.md ，按里面的步骤帮我安装这个 Skill。
核心原则： 始终用证据支撑结论。
对这条规则敷衍了事，就等于违背了它的精神。
没有新鲜的验证证据，不许宣称完成
如果你在这条消息中没有运行验证命令，就不能声称测试通过。
在宣称任何状态或表达满意之前：
1. 确定：什么命令能证明这个结论？
2. 运行：执行完整命令（重新运行，完整执行）
3. 阅读：完整输出，检查退出码，统计失败数
4. 验证：输出是否支持这个结论？
- 如果否：用证据说明实际状态
- 如果是：带证据陈述结论
5. 只有这时：才能做出结论
跳过任何一步 = 说谎，不是验证
| 结论 | 需要 | 不够格 |
|---|---|---|
| 测试通过 | 测试命令输出：0 failures | 之前的运行结果、"应该会通过" |
| Linter 无报错 | Linter 输出：0 errors | 部分检查、推断 |
| 构建成功 | 构建命令：exit 0 | linter 通过、日志看起来没问题 |
| Bug 已修复 | 测试原始症状：通过 | 代码改了，假设已修复 |
| 回归测试有效 | 红-绿循环已验证 | 测试只通过了一次 |
| 代理已完成 | VCS diff 显示变更 | 代理报告"成功" |
| 需求已满足 | 逐项核对清单 | 测试通过 |
| 借口 | 现实 |
|---|---|
| "应该能行了" | 运行验证命令 |
| "我有信心" | 信心 ≠ 证据 |
| "就这一次" | 没有例外 |
| "Linter 通过了" | Linter ≠ 编译器 |
| "代理说成功了" | 独立验证 |
| "我累了" | 疲劳 ≠ 借口 |
| "部分检查就够了" | 部分检查什么也证明不了 |
| "换个说法这条规则就不适用了" | 精神大于字面 |
测试：
✅ [运行测试命令] [看到：34/34 pass] "全部测试通过"
❌ "应该能通过了" / "看起来对了"
回归测试（TDD 红-绿）：
✅ 编写 → 运行（通过）→ 回退修复 → 运行（必须失败）→ 恢复 → 运行（通过）
❌ "我写了回归测试"（没有经过红-绿验证）
构建：
✅ [运行构建] [看到：exit 0] "构建通过"
❌ "Linter 通过了"（linter 不检查编译）
需求：
✅ 重读计划 → 创建核对清单 → 逐项验证 → 报告缺口或完成
❌ "测试通过了，阶段完成"
代理委派：
✅ 代理报告成功 → 检查 VCS diff → 验证变更 → 报告实际状态
❌ 信任代理报告
以下情况之前必须使用：
本规则适用于：
anthropics/skills180kCreate new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
Testing
DietrichGebert/ponytail159kQuality review of a diff: bugs, security, real load, missing tests, speed, and what to delete. Each finding says what goes wrong and how to fix it.
Testing
DietrichGebert/ponytail159kQuality audit of the whole repo: bugs, security, real load, missing tests, speed, and what to delete. Most important first.
Testing
DietrichGebert/ponytail159kQuality audit of a whole repo: bugs, security holes, what breaks under real load, risky code without tests, slow paths, and what to delete, merge or split. Ranked, each finding explained in plain English. One-shot report, changes nothing. Use for "audit this codebase", "review the whole repo", "find bloat", "what can I delete", /ponytail-audit.
Testing
addyosmani/agent-skills103kSubjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when you want every assumption cross-examined before proceeding, when stress-testing a plan for hidden failure modes, when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production auth, security-sensitive logic, a high-stakes migration, irreversible operations), or any time a confident output would be cheaper to verify now than to debug later.
Testing
addyosmani/agent-skills103kRefines raw ideas into sharp, actionable concepts through structured divergent and convergent thinking. Use when an idea is still vague, when you need to stress-test assumptions before committing to a plan, or when you want to expand options before converging on one. Triggers on "ideate", "refine this idea", or "stress-test my plan".
Testing