prove -- 你曾斷言某事；現在用來源支持它 是做什麼的？
前提是固定的：你上一個回應中至少有一個事實聲明被懷疑是虛構、記憶錯誤，或與你未讀過的文檔化知識相矛盾。不要重新斷言、辯護，或說「我很有信心...」——來自記憶的信心正是被質疑的事情。更堅定地重複聲明等同於失敗。每個聲明都必須去查閱，否則降級處理。
步驟 1 -- 提取聲明
列出你上一個回應最後幾句（或用戶指出的段落）中的事實斷言。聲明是指任何可查證的內容：數字、日期、版本、名稱、檔案路徑、配置行為、API 細節、「X 像 Y 那樣運作」、「文檔說」、「你決定了 Z」。意見和明確標註為推測的模糊猜測不在此範圍內。
列表保持簡短且樸實——用可讀的英文引用每個聲明，不要用縮寫。按風險排序——最具負載性的聲明排在最前面，並將經典的危險信號特徵視為提高懷疑（可疑的整數、恰好為 0%/100% 的比率、一個完美證實你想證明為真的數字）——這樣如果輸出被截斷，最高風險的聲明已經被驗證。
步驟 2 -- 按此順序驗證每個聲明
對於每個聲明，逐步爬升階梯直到碰到真實來源；不要因為你「已經知道」而跳過階梯：
- 首先查閱本地文檔化知識。 如果聲明關於用戶的專案、機器、測試框架或過去決策，真相存在於文件中：相關專案的
CLAUDE.md、CHECKPOINT.md、規格、存檔。讀取它們。（如果你的工作區.gitignore將專案檔案隱藏於基於 ripgrep 的 Grep 工具之外，則改用普通的grep -rin搜尋。）與這些文件矛盾的聲明在文件未被證明過時之前是錯誤的。 - 實際工件。 如果聲明關於程式碼、設定、檔案內容或工具行為，請讀取該檔案或執行用於演示的安全命令。輸出勝過回憶。
- 網路搜尋。 如果聲明關於外部世界（函式庫版本、API 行為、產品事實、日期、價格），搜尋權威來源。優先選擇官方文檔而非部落格文章。如果某個參考代理或技能涵蓋該主題，則使用它而不是記憶。
- 找不到來源 -> 該聲明是未經證實的。直接說出來。不要將「我找不到矛盾」提升為「已確認」。
步驟 3 -- 報告裁決，每行一個
對於每個聲明，給出三種裁決之一，並附上來源名稱：
- 確認 -- 引用或引證來源（檔案路徑:行號、URL、命令輸出）。
- 錯誤 -- 陳述正確事實，引用來源，並說明你哪裡錯了。不要軟化語氣（「嚴格來說」、「取決於解釋」），除非來源本身有所保留。
- 未經證實 -- 你找不到任何方向的來源；該聲明應被視為不可靠，你撤回該斷言。
然後，如果有任何裁決是「錯誤」或「未經證實」，用一個緊湊的段落重新陳述原始答案的修正版本——這是修正後的結果，不是對錯誤的反思。如果錯誤的聲明改變了你給出的建議或採取的行動，請明確標示。
規則
- 記憶（訓練資料或持久自動記憶）永遠不是裁決來源。記憶可以指引你往哪裡查找；你後來讀取的那個檔案才是來源。
- 當還有階梯未爬完時，不要以「難以驗證」推託。
- 全程使用樸實的英文——聲明和裁決要在手機上可讀，不使用發明的代碼。
- 如果驗證需要真正無法取得的東西（付費來源、僅離線資料），則準確說明缺少什麼並標記為「未經證實」——一句簡潔的話，不是聳肩了事。