name: 完成前验证 description: 在声称成功前运行验证命令并确认输出 version: 2.0.0 category: 调试 author: Jesse Vincent license: MIT source: https://github.com/obra/superpowers-skills/tree/main/skills/debugging/verification-before-completion progressive_disclosure: entry_point: summary: “证据先行：任何完成声明前的强制验证” when_to_use: “当即将声称工作完成、已修复、通过或就绪时。尤其是在提交、拉取请求或任务完成前。” quick_start: “1. 识别验证命令 2. 运行完整命令 3. 阅读完整输出 4. 验证结果 5. 然后带有证据地声明” references: - gate-function.md - verification-patterns.md - red-flags-and-failures.md - integration-and-workflows.md context_limit: 800 tags:
- 验证
- 质量保证
- 诚实
- 证据 requires_tools: []
完成前验证
概述
未经验证就声称工作完成是不诚实，不是效率。
核心原则： 证据先行，永远如此。
违反这条规则的字面意思就是违反其精神。
此技能强制要求在任何完成声明前进行验证，防止误报、构建失败和信任违规。
何时使用此技能
在声称以下事项前始终激活：
- 成功、完成或满意（“完成！”、“已修复！”、“很棒！”）
- 测试通过、代码检查干净、构建成功
- 提交、推送、创建拉取请求
- 标记任务完成或委托给代理
特别在以下情况下使用：
- 时间紧迫或疲惫时
- “快速修复”似乎显而易见或你充满信心时
- 代理报告成功或测试“应该”通过时
铁律
没有新鲜验证证据，就没有完成声明
如果你没有运行此消息中的验证命令，就不能声称它通过。
核心原则
- 证据必需：每个声明都需要支持证据
- 新鲜验证：必须现在验证，不依赖之前的运行
- 完整验证：完整命令，而非部分检查
- 诚实报告：报告实际状态，而非期望状态
快速开始
五步门函数：
- 识别：什么命令证明此声明？
- 运行：执行完整命令（新鲜、完整）
- 阅读：完整输出，检查退出代码，计算失败
- 验证：输出是否确认声明？
- 如果否：用证据说明实际状态
- 如果是：带有证据地声明
- 仅然后：做出声明
跳过任何步骤 = 撒谎，而非验证。
关键模式
正确模式：
✅ [运行 pytest] [输出: 34/34 通过] “所有测试通过”
错误模式：
❌ “现在应该通过”
❌ “看起来正确”
❌ “测试曾通过”
❌ “我自信它有效”
红旗 - 立即停止
如果你发现自己：
- 使用“应该”、“可能”、“似乎”
- 在验证前表达满意
- 即将提交/推送/拉取请求而未经验证
- 信任代理成功报告
- 依赖部分验证
所有这些意味着：停止。先运行验证。
为什么这很重要
现实世界失败的统计数据：
- 验证成本：2分钟
- 恢复成本：120+分钟（贵60倍）
- 40% 未经验证的“完成”声明需要返工
核心违规： “如果你撒谎，你将被替换”
导航
获取详细信息：
- 门函数：完整的五步验证过程与决策树
- 验证模式：测试、构建、部署等的正确验证模式
- 红旗与失败：常见失败模式、红旗和现实世界示例，带时间/成本数据
- 集成与工作流：与其他技能的集成、CI/CD 模式和代理委托工作流
底线
验证没有捷径。
运行命令。阅读输出。然后声明结果。
这是不可协商的。