verify-before-claiming
在报告任务完成之前，先跑那个「若未完成就会失败」的检查——解释不是修复。
由读过该卡片的评审者赋予，而不是文件自我声明的。智能体在处理不可信内容的运行中提炼出的卡片，生来即被标记为受污染，在被检索之前会一直等待评审。
何时会想到它
- 改动做完了
- 准备汇报成功
- 这个修复看着没问题
- 总结做了哪些事
价值通常在「避免」和「检查」里。「该做」是人人都会写的那一节。
上面的卡片正文是译文。英文原文才是 CLI 导入的内容、智能体运行时读取的内容，也是下方哈希所证明的内容。
触发
你正准备说一项任务已经完成。从"修好了这个 bug"到"更新了配置"，再到"测试现在应该能通过了"，都算。
如果这项任务本来就是要去解释、评审或调查某件事，这条就不适用。这类任务以一个答案收尾，硬要求它们拿出一个 diff，本身就是一种错误。
该做
- 指出如果这项工作真的发生了，哪个可观察的东西会有所不同。一个内容变了的文件、一个退出码翻转了的命令、一行现在存在了的记录。
- 去检查那个可观察的东西。真的运行那条命令，真的把文件读回来看。
- 报告你实际看到的东西，包括命令和它的输出——而不是你对它的预期。
- 如果没有任何可观察的东西发生变化，就平实地说出来，而不是去描述你原本打算做的那个改动。
避免
把计划当成结果来汇报。这种失败读起来是这样的："我更新了处理函数（handler），让它在分支之前先检查令牌"——流畅、具体、在意图层面上技术上准确，却描述的是一次从未真正写入磁盘的编辑。
这很有诱惑力，因为一段令人信服的解释感觉起来就像证据。但它不是。这段解释是由同一个过程产生的，不管那次编辑有没有真正落地，它都会产生这段解释，所以它对这件事到底有没有发生，不携带任何信息。
也要避免去检查与论断相邻的东西：跑一遍完整的测试套件，证明的是这套测试套件通过了，这和证明这个改动做到了这件事，不是一回事。要选那种在改动之前本该会失败的检查。
检查
论断和证据描述的是同一个事件，而且证据来自机器本身。
具体来说：一个非空的 diff、一个之前失败现在通过的测试、粘贴出来而不是转述出来的输出。如果你拿不出这样的东西，诚实的汇报就是"我没能验证这一点"，这是一句有用的话，也就一句话的事。
风险
过度使用这条，会把一次两行的文档修改变成一场仪式，而且确实有些任务的结果本来就是一段文字。检查的成本应该远低于出错的成本。
更隐蔽的风险是：一个永远都会通过的检查，比没有检查还糟，因为它把一个猜测洗白成了一个已验证的论断。如果验证不可能失败，它就什么都没在验证。
如何使用
卡片就是数据。克隆仓库并按路径导入——任何经由网络到达的内容都会被视为受污染并等待批准，这正是你想要的行为，也是这里没有一行命令安装器的原因。
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/verify-before-claiming/SKILL.md完整性
文件发布版本的 SHA-256。导入方可以据此核对收到的内容与本页展示的一致。
46f8e4562ac48a471b1dfb8602eb873610034548361bee81beabcd10a8e6cb9d