prove -- あなたが主張したことを、出典で裏付けよ
前提は固定です。直前の応答に含まれる少なくとも1つの事実主張が、捏造、記憶違い、またはあなたが読んでいない文書知識と矛盾していると疑われています。その主張を再主張したり、弁護したり、「確信しています…」と言ったりしないでください。記憶への自信こそが正確に指摘されている問題です。主張をより強く繰り返すことは失敗です。すべての主張は調査されるか、格下げされます。
ステップ1 -- 主張を抽出する
直前の応答の最後の数文（またはユーザーが指摘した箇所）に含まれる事実の主張をリストアップしてください。主張とは、検証可能なものすべてです：数値、日付、バージョン、名前、ファイルパス、設定の動作、APIの詳細、「XはYのように動作する」、「ドキュメントには…と書いてある」、「あなたはZと判断した」。意見や推測と明示されたものは対象外です。 リストは短く平易に保ち、各主張を省略形ではなく読みやすい英語で引用してください。 リスク順に並べてください。最も重要な主張を最初に、典型的なレッドフラグ（不自然に丸い数字、ちょうど0%や100%の割合、自分が正しいと信じたいことを完璧に裏付ける数値）は疑いを高めるものとして扱います。これにより、応答が途中で切れても、最もリスクの高い主張がすでに検証されている状態になります。
ステップ2 -- 各主張をこの順序で検証する
各主張に対して、実際の出典にたどり着くまでラダーを上ってください。「もう知っている」という理由で段階を飛ばさないでください。
- まずローカルの文書化された知識。 主張がユーザーのプロジェクト、マシン、テスト環境、過去の判断に関するものであれば、真実はファイルの中にあります。該当プロジェクトの
CLAUDE.md、CHECKPOINT.md、仕様書、アーカイブを読んでください。（ワークスペースの.gitignoreがripgrepベースのGrepツールからプロジェクトファイルを隠している場合は、代わりにプレーンなgrep -rinで検索してください。）これらのファイルと矛盾する主張は、ファイルが古いと示されるまで誤りです。 - 実際の成果物。 主張がコード、設定、ファイルの内容、ツールの動作に関するものであれば、ファイルを読むか、それを示す無害なコマンドを実行してください。出力は記憶に勝ります。
- Web検索。 主張が外部の世界（ライブラリのバージョン、APIの動作、製品の事実、日付、価格）に関するものであれば、権威ある出典を検索してください。公式ドキュメントをブログ記事より優先してください。トピックをカバーするリファレンスエージェントやスキルがあれば、記憶の代わりにそれを使ってください。
- 出典が見つからない -> その主張は「未検証」です。そのまま正直に伝えてください。「矛盾が見つからなかった」を「確認済み」に格上げしないでください。
ステップ3 -- 判定を1行ずつ報告する
各主張について、以下の3つの判定のうち正確に1つを、出典名とともに報告してください。
- 確認済 -- 出典を引用または参照してください（ファイルパス:行、URL、コマンド出力）。
- 誤り -- 正しい事実を述べ、出典を引用し、何を間違えたかを説明してください。出典自体が曖昧にしている場合を除き、軟化（「厳密には」「解釈次第では」）は禁止です。
- 未検証 -- どちらの方向にも出典が見つからなかった場合。その主張は信頼できないものとして扱い、主張として撤回します。
その後、誤りまたは未検証の判定が1つでもあった場合は、元の回答の修正版を1つの簡潔な段落で言い直してください。それは修正された結果であり、誤りについての考察ではありません。誤った主張があなたの取った推奨や行動を変えた場合は、それを明示的に示してください。
ルール
- 記憶（訓練データまたは永続的な自動記憶）は決して判定の出典になりません。記憶は「どこを見るべきか」を指し示すために使えます。その後実際に読んだファイルが出典です。
- 未検証の段階が残っているのに「検証が難しい」と言ってごまかさないでください。
- 全体を通して平易な英語で。主張と判定はスマートフォンでも読めるように、独自のコードは使わないでください。
- 検証にどうしても利用できないもの（ペイウォールの出典、オフライン限定データ）が必要な場合は、何が不足しているかを正確に述べ、「未検証」とマークしてください。1つの簡潔な文で、肩をすくめるような素振りはなしです。