完成前验证

要解决的具体问题

在提交、建 PR、任务完成或委派子智能体之前，「改好了」「测试通过」「Bug 已修复」这类声明经常缺少本轮可复现的证据。有人依赖上一次运行结果，有人只看局部检查，有人听到智能体回一句「成功」就信了。结果是：失败计数没被读取，退出码被跳过，原症状用例没重跑，回归风险带着模糊措辞流入 code-review、debugging 和 CI。

技能如何工作

这个技能把「证据优先」变成完成声明前的门禁函数，核心铁律是：无新鲜验证证据，不声明完成。它不是替代测试或构建，而是要求声明者先说清楚要验证什么，再真正运行完整命令。

关键步骤按门禁函数展开：

• 识别：判断哪条命令能证明当前声明，例如测试命令、构建命令、lint、原始症状用例或 VCS diff。
• 运行：执行完整且新鲜的命令，不接受「上次应该过了」。
• 读取：查看完整输出、退出码和失败数量。
• 验证：判断输出是否支持声明；不支持就陈述真实状态并给出下一步。
• 然后：只有在证据成立时，才带证据做完成声明。

例如用户说「我改完登录按钮了，应该好了吧？」，技能会识别出应运行测试套件验证点击行为，执行命令后看到 34/34 通过，再给出带证据的结论，并输出结构化工件 VerifyGate：

{"claim":"登录按钮已修复","command":"npm test","exit_code":0,"evidence":"34/34 pass","verified":true}

VerifyGate 包含 claim、command、exit_code、evidence 和 verified，可交给 code-review 做合并前门禁、交给 debugging 验证修复、交给 devops 接入 CI 门禁。

适用边界与注意点

适用场景包括任何「成功 / 完成 / 修复」变体、满意表达、正向工作状态陈述，以及提交、PR、任务切换和委派子智能体之前。

不适用场景包括纯计划讨论，因为尚无可验证产物；以及最终是否提交仍应由用户决定。

需要停手的红旗包括：使用「应该 / 可能 / 似乎」；未验证就满意；未验证就提交或建 PR；轻信智能体报告；只做局部验证；说「就这一次」；疲惫想结束；任何暗示成功却没跑验证的措辞。

注意，这个技能不保证测试本身设计正确，也不会替用户决定提交时机。它只保证：如果要声称通过，本轮必须真的运行验证，并用输出、退出码和失败数说话。