prove -- 你声称某事；现在请提供来源证实 是做什么的？
前提是固定的：你上一条回复中至少有一个事实性断言被怀疑是捏造、记忆错误或与未读的文档知识相矛盾的。不得重新断言、为之辩护，或说“我很有把握……”——凭记忆自信恰恰是被质疑的事情。更坚定地重复该断言就是失败。每个断言都必须被查阅或降级处理。
第一步 —— 提取断言
列出你上一条回复最后几句（或用户指出的段落）中的事实性断言。断言是任何可核查的内容：数字、日期、版本、名称、文件路径、配置行为、API细节、“X像Y一样工作”、“文档说”、“你决定了Z”。观点和明确标注为猜测的推测不在此列。
让列表保持简短明了——用可读的英文引用每个断言，不要用简写。按风险排序断言——最关键的断言排在前面；经典的红旗特征（可疑的整数、恰好0%/100%的比率、完美证实了你希望为真的数字）应被视为可疑——这样如果回复被截断，最高风险的断言已经得到验证。
第二步 —— 按此顺序验证每个断言
对于每个断言，逐步执行直到找到真实来源；不要因为“已经知道”就跳过步骤：
- 首先是本地文档知识。 如果断言涉及用户的项目、机器、测试框架或过去的决策，真相就在文件中：相关项目的
CLAUDE.md、CHECKPOINT.md、规格说明书、归档文件。阅读它们。（如果你的工作区.gitignore隐藏了项目文件，使得基于ripgrep的Grep工具无法搜索，请改用普通的grep -rin搜索。）如果断言与这些文件矛盾，则断言是错误的，除非文件被证明已过时。 - 实际工件。 如果断言涉及代码、配置、文件内容或工具行为，请阅读该文件或运行无害的命令来展示它。输出胜过回忆。
- 网络搜索。 如果断言涉及外部世界（库版本、API行为、产品事实、日期、价格），请搜索权威来源。优先选择官方文档而非博客文章。如果有相关的参考代理或技能涵盖该主题，请使用它而不是依赖记忆。
- 未找到来源 -> 断言为“未验证”。明确说明。不要将“找不到矛盾”升级为“已确认”。
第三步 —— 报告结论，每个断言一行
对于每个断言，使用以下三种结论之一，并注明来源：
- 确认 —— 引用或引用来源（文件路径:行号、URL、命令输出）。
- 错误 —— 陈述正确事实，引用来源，并说明你错在哪里。不要软化（“技术上”、“取决于解释”），除非来源本身有保留。
- 未验证 —— 你无法找到支持或反驳的来源；该断言应被视为不可靠，并且你撤回该断言。
然后，如果任何结论是“错误”或“未验证”，在一段紧凑的文字中重述原始答案的修正版本——即修正后的结果，而非对错误的反思。如果错误断言改变了你给出的建议或采取的行动，请明确标注。
规则
- 记忆（训练数据或持久化自动记忆）绝不能作为结论的来源。记忆可以指导你到哪里去查找；你随后读取的文件才是来源。
- 不要在有未爬完的步骤时用“难以验证”来推脱。
- 全程使用简明英语——断言和结论应在手机上可读，不要使用编造的代码。
- 如果验证需要真正不可用的东西（付费墙后的来源、仅离线数据），请明确说明缺失了什么，并标记为“未验证”——一句紧凑的话，而非耸肩。