Verification Before Completion 是一个面向开发工作收尾阶段的验证纪律技能，核心主张是：没有经过验证就宣称任务完成是不诚实的，而不是高效。
用途 该技能用于在任何“成功/完成”类表述之前建立强制验证流程，包括宣称测试通过、Linter 干净、构建成功、Bug 已修复、回归测试有效、子代理已完成任务、需求已满足等情形。它也适用于提交代码、推送、创建 PR、结束任务或切换到下一任务之前。
核心原则与铁律 技能提出“先证据，后声明，始终如此”。铁律为：没有新鲜的验证证据，不得作出完成声明。如果当前消息中没有运行过验证命令，就不能声称其通过。规则同时强调精神重于字面：任何暗示成功、正确或完成的表述都受约束，包括同义改写。
验证门流程 在作出任何状态声明或表达满意之前，需依次执行：
- 识别：哪条命令能证明这个声明？
- 运行：执行完整命令（新鲜、完整）。
- 阅读：查看完整输出，检查退出码，统计失败数。
- 核实：输出是否支持该声明？若不支持，则带证据说明实际状态；若支持，则带证据作出声明。
- 只有完成以上步骤，才可以作出声明。 跳过任何一步即视为未验证。
常见失败与所需证据 技能列举了典型声明及其充分证据：测试通过需要测试命令输出显示 0 失败，而不是上次运行结果或“应该能过”；Linter 干净需要 Linter 输出 0 错误，而不是部分检查或推测；构建成功需要构建命令退出码为 0，Linter 通过不能替代编译验证；Bug 修复需要针对原始症状的测试通过，而不是改了代码就假定修复；回归测试有效需要完成红-绿循环验证，而不是测试只跑过一次通过；代理完成任务需要查看版本控制差异，而不是信任代理的“成功”报告；需求满足需要逐条对照清单，而不是以测试通过代替。
危险信号 使用“应该”“大概”“似乎”；在验证前表达满意（如“太好了”“完美”“完成了”）；未验证就准备提交/推送/创建 PR；信任代理的成功报告；依赖部分验证；抱有“就这一次”的心态；因疲惫而想尽快结束；任何未运行验证却暗示成功的措辞。
常见借口与纠正 技能逐条反驳：说“现在应该能用了”应改为运行验证；“我有信心”不等于证据；“就这一次”没有例外；“Linter 过了”不等于编译通过；“代理说成功了”需要独立核实；“我累了”不是理由；“部分检查够了”但部分检查证明不了什么；“换个说法就不受规则约束”应遵循规则精神。
关键模式示例 测试：运行测试命令，看到 34/34 通过，才说“所有测试通过”；不应说“现在应该能过”或“看起来正确”。回归测试：编写测试→运行（通过）→撤销修复→运行（必须失败）→恢复修复→运行（通过）。构建：运行构建，看到退出码 0，才说“构建通过”。需求：重读计划→建立清单→逐项验证→报告缺口或完成。代理委派：代理报告成功后，检查版本控制差异、验证更改、报告实际状态。
适用场景与限制 该技能适用于编码与开发流程中的完成声明和质量把关，不提供具体项目的测试命令、构建命令或工具配置；这些需由使用者按项目实际情况确定。技能本身是一套行为约束和检查清单，不替代实际测试、编译或人工审查。