Verification Before Completion（完成前必须验证）
没有当次运行过的验证证据，就不能说「完成了」「测试通过了」——包括「应该」「看起来」这类措辞
该技能针对提交、创建 PR 或声称任务完成前的验证，直接解决未经核实就报告成功这一常见问题。其“证据先于断言”原则、门控步骤和按测试、构建、需求及代理委派分类的示例具有明确任务价值。证据缺口是未明确适用的项目类型、验证命令选择边界，以及无法运行验证时的完整替代流程。
“识别命令—运行完整命令—读取完整输出并检查退出码—核对结论”的流程一致且可复现性方向明确；还覆盖了回归测试的红绿循环和代理成功报告的独立检查。证据缺口包括没有指定命令发现方法、没有处理命令不存在、环境不完整、超时、非零退出码或输出歧义的详细故障流程，也没有该技能自身的行为测试证据。
该技能能降低虚假完成声明和未经验证的提交、PR风险，并要求在代理报告后检查版本控制差异。它不要求凭据、网络访问或修改特定文件，未见恶意或破坏性默认行为。安全性仍有限，因为“运行完整命令”可能产生构建、测试、提交或其他外部副作用；技能没有最小权限、用户确认、沙箱、敏感数据处理、失败回滚或命令安全审查要求。
技能明确要求新鲜验证证据、读取完整输出、检查退出码和失败数量，并区分“测试通过”“构建成功”“需求满足”等不同主张，形成了较好的证据—结论约束。证据缺口是示例中的运行结果属于说明性文本而非本次静态审查可验证的执行记录；“24 failure memories”等背景说法没有可核查出处，且没有针对该 SKILL.md 的独立评估、测试结果或事实与推断的显式标注。
触发条件清楚，铁律、门控函数、失败模式和常见验证模式易于按步骤采用，适合编码代理和软件开发工作流。证据缺口包括缺少安装或 harness 要求、输入输出契约、命令成本和耗时说明、跨代理工具兼容性、命令失败排障示例，以及无法验证时如何安全退出或报告阻塞状态。
目标文件有名称和描述元数据；共享仓库材料显示 MIT 许可、版本 6.1.1、贡献流程、问题渠道和更新说明，能提供有限的维护背景。该技能本身没有版本、变更记录、责任人、发布责任或专门更新路径；发布者 provenance 未经 FollowSkills 企业注册表验证，因此不能据此增加治理分数。
- 不要把“运行完整命令”理解为无条件执行可能提交、删除、部署或访问外部系统的命令；应先审查副作用并在需要时取得用户同意。
- 验证命令失败、不可用或输出含糊时，不应声称成功；应报告实际状态、阻塞原因和未验证范围。
- 该评估仅基于静态材料，未执行技能、命令或测试；仓库测试材料不能替代该目标 SKILL.md 的专门行为证据。
它能做什么 & 适用场景
这是 Superpowers 里最短但态度最强硬的一个 skill：核心立场是「没有验证就声称完成，是说谎，不是效率」。规定在做任何完成/通过类的表态之前，必须先明确「用什么命令能证明这个说法」、当场跑一遍、看完整输出、确认输出真的支持这个说法，最后才允许下结论——顺序错了或跳过任何一步都算违规。
给出一张「声称→需要的证据→不够格的证据」对照表（比如「测试通过」需要「测试命令输出：0 failures」，不能只凭「之前跑过」「应该能过」）；列出一份红旗清单——用「应该」「大概」「看起来」这类措辞、在验证前就表达满意（「太好了！」「完成了！」）、直接相信子代理自己汇报「成功」而不做独立核实，这些都要立刻停下；给出回归测试的具体红绿验证流程（写测试→跑通过→还原修复代码→跑必须失败→恢复修复→再跑通过），证明测试真的在测这个 bug，而不是自己以为在测；对「子代理汇报完成」这种场景，要求额外去看版本控制的实际 diff 核实，而不是单纯相信汇报文字。
- 任何「测试通过了」「bug 修好了」「构建成功了」之类的表态之前，先跑一次对应命令拿到当次证据，而不是凭上一次运行的记忆
- 子代理汇报「任务完成」后，去看它实际提交的 diff 核实改动内容，而不是直接采信汇报文字
- 写完一个回归测试后，按红绿流程验证这个测试真的能检测到原来的 bug（还原修复代码后测试必须失败），而不是写完就默认它有效
优缺点一览
- 「声称—证据—不够格证据」的对照表把「怎样才算验证过」变成了可检查的具体标准，而不是「认真一点」这种无法执行的建议
- 专门针对「子代理汇报成功」这个场景要求额外核实，是一个容易被忽视但确实高发的可信度陷阱
- 回归测试的红绿验证流程（改回原状必须能重现失败）是个很实用的具体技巧，能真正证明测试有效而不只是「看起来测了」
- 只在会自动读取和遵循 SKILL.md 指令的 harness 里可靠工作（Claude Code、Codex CLI 等）；纯聊天式界面里等于一份说明文档，需要人工照做。
- 对每一个小结论都要求「当次运行证据」，在验证成本很高（比如跑一次要几十分钟）的场景下，会显著拖慢反馈循环，需要权衡
- 这类自我约束规则的效力完全取决于模型是否真的遵守，没有外部机制强制执行，跟其余 Superpowers skill 一样存在这个共性局限
如何安装
作为 obra/superpowers 插件的一部分安装，不能单独安装某一个 skill：
- Claude Code：官方市场
/plugin install superpowers@claude-plugins-official；或先注册 Superpowers 自建市场/plugin marketplace add obra/superpowers-marketplace，再/plugin install superpowers@superpowers-marketplace - 也支持 Antigravity、Codex App/CLI、Cursor、Factory Droid、GitHub Copilot CLI、Kimi Code、OpenCode、Pi 等 harness，具体命令见仓库 README
装好后这个 skill 会和其余 13 个 Superpowers skill 一起启用，由 using-superpowers 统一引导、按场景自动触发，无需单独调用。
如何使用
在任何要下「完成/通过/修好了」结论、提交/推送/建 PR 之前自动触发；也是 subagent-driven-development 和 systematic-debugging 流程里被显式引用的下游 skill，用来把关每个阶段的完成声明。
对比同类
跟没有这条规则、模型凭上一次运行结果或主观判断就下结论相比，这个 skill 把「完成声明」和「当次验证证据」强绑定，直接针对性解决「过早报告成功」这一类常见的 agent 幻觉/偷懒问题；跟 test-driven-development 强调的「先写测试」相辅相成——一个管「怎么写代码」，一个管「怎么汇报结果」。