用途
“完成前验证”（verification-before-completion）用于在宣称工作完成、已修复或测试通过之前，强制先运行验证命令并确认输出。它的核心原则是：始终用证据支撑结论。资料明确指出，在没有验证的情况下宣称工作完成，不是高效，而是不诚实；对这条规则敷衍了事，就等于违背了它的精神。
主要能力
该技能提供了一套可执行的验证纪律：
- 铁律：没有新鲜的验证证据，不许宣称完成。如果你在这条消息中没有运行验证命令，就不能声称测试通过。
- 门控函数：在宣称任何状态或表达满意之前，依次执行——确定什么命令能证明结论；运行完整命令（重新运行、完整执行）；阅读完整输出、检查退出码、统计失败数；验证输出是否支持结论；只有这时才能做出结论。跳过任何一步都等于说谎，而不是验证。
- 常见失败模式对照：例如“测试通过”需要测试命令输出 0 failures，而不是之前的运行结果或“应该会通过”；“Linter 无报错”需要 linter 输出 0 errors，而不是部分检查或推断；“构建成功”需要构建命令 exit 0，而不是 linter 通过或日志看起来没问题；“Bug 已修复”需要测试原始症状通过，而不是代码改了、假设已修复；“回归测试有效”需要红-绿循环已验证，而不是测试只通过了一次；“代理已完成”需要 VCS diff 显示变更，而不是代理报告“成功”；“需求已满足”需要逐项核对清单，而不是测试通过。
- 红线信号：使用“应该”“大概”“似乎”；验证前就表达满意（“太好了！”“完美！”“搞定！”等）；即将提交/推送/创建 PR 却没有验证；信任代理的成功报告；依赖部分验证；想着“就这一次”；累了想赶紧收工；任何暗示成功但实际未运行验证的措辞。
- 防止合理化：针对“应该能行了”“我有信心”“就这一次”“Linter 通过了”“代理说成功了”“我累了”“部分检查就够了”“换个说法这条规则就不适用了”等借口，分别给出对应现实：运行验证命令、信心不等于证据、没有例外、Linter 不等于编译器、独立验证、疲劳不是借口、部分检查什么也证明不了、精神大于字面。
使用方式
资料给出的关键模式包括：
- 测试：运行测试命令，看到 34/34 pass，才能说“全部测试通过”；不能只说“应该能通过了”或“看起来对了”。
- 回归测试（TDD 红-绿）：编写 → 运行（通过）→ 回退修复 → 运行（必须失败）→ 恢复 → 运行（通过）；不能只说“我写了回归测试”而没有经过红-绿验证。
- 构建：运行构建，看到 exit 0，才能说“构建通过”；不能因为“Linter 通过了”就认为构建通过，因为 linter 不检查编译。
- 需求：重读计划 → 创建核对清单 → 逐项验证 → 报告缺口或完成；不能因为“测试通过了”就认为阶段完成。
- 代理委派：代理报告成功 → 检查 VCS diff → 验证变更 → 报告实际状态；不能直接信任代理报告。
适用场景
以下情况之前必须使用：任何形式的成功/完成声明；任何满意的表达；任何关于工作状态的正面陈述；提交、创建 PR、标记任务完成；进入下一个任务；委派给代理。本规则适用于准确措辞、同义词和换一种说法、暗示成功，以及任何传达完成/正确性的沟通。
限制
资料强调验证没有捷径：运行命令、阅读输出，然后才能宣称结果，这没有商量余地。资料中未提供该技能的具体安装命令、平台支持范围、收费方式或价格信息，这些事实暂未提供。