read-claude-code-history

Claude Code の履歴を読む

Claude Code の証拠のみを読み取ってください。以前のプロセスを再開したり、そのプロジェクトを編集したり、読み取りの依頼を継続タスクに変えたりしないでください。後でユーザーから作業を依頼された場合は、確認済みの証拠を daymade-claude-code:continue-claude-code-work に渡してください。

求められている結果に応じて振り分ける

ユーザーの要望	使用するもの
最近の Claude Code セッション、タイトル、日付、ID	インデックス化されたメタデータのみを使用してください。同梱の list_local_history.py は現在、日付や件数で絞り込む前に候補となるすべての本文を読み取るため、広範な一覧の作成には使用しないでください
既知のセッションを時系列の証拠ブリーフィングとして再構成する	scripts/read_claude_session.py --session <ID>
特定のセッションから、ツール名、リテラルテキスト、序数、または時刻で選んだ、あるツールの元の入力と対応する結果	scripts/read_claude_session.py --session <ID> --tool-evidence --contains '<literal>'。以下の元のツール呼び出し／結果の証拠を参照してください
セッションIDとコマンドのSHA-256ではなくテキストを記録しているフック監査行の、正確なコマンド	scripts/read_claude_session.py --session <ID> --find-command-sha256 <HEX>。以下のフック監査行のコマンドを参照してください
1つのセッションにおけるすべての Agent/Task tool_use を、逐語的に引用する（たとえば、独立したレビュアーエージェントに渡された正確なプロンプト）	scripts/read_claude_session.py --session <ID> --agent-prompts（任意で --agent-description-prefix TEXT を指定）。同じプロンプトが2回送信された場合は、2回表示されます
既知の時間範囲内に、どのセッションがプログラムを起動したかを、複数のセッションから調べる	scripts/analyze_sessions.py tool-calls --from <ISO> --to <ISO> --pattern <REGEX> [--tool NAME]。本文を読み取る前にファイルシステムのメタデータから候補を選び、その後セッションごとにグループ化します。Codex のロールアウトは対象外であり、その欠落は出力に記載されます
複数のセッションにわたるフック実行の結果、所要時間、実行ごとの終了コードを調べる（たとえば「セッションの起動が遅かった理由は何か」「今日このガードは作動したか」）	scripts/analyze_sessions.py hook-events --from <ISO> --to <ISO> [--pattern <REGEX>] [--event NAME]。候補を先に絞り込む方法は tool-calls と同じです。フォークされたセッションにある実行の複製は1つにまとめられます。Codex のロールアウトは対象外であり、その欠落は出力に記載されます
ユーザーの最近の発言（ユーザーがキューに入れたプロンプトを含む）	scripts/extract_user_messages.py
キーワードで会話や引用を探す	scripts/history_index.py recall --mode bm25 を実行し、その後、該当する正確なセッションを読み取ります
表現が変わっている可能性のある過去の作業	インデックスの状態を確認してから、scripts/history_index.py recall を実行します
セッションIDが不明なトピック	scripts/history_index.py status を実行してから、recall を実行します。インデックスの対象範囲と鮮度を明示してください
特定したセッションや、物理的に範囲を限定したプロジェクトの終了時の状況	references/workflow_examples.md のセッションの終了状況を調べるに従ってください
Claude のファイル履歴記録に保存されている、削除または上書きされたファイル	scripts/recover_content.py
各スキルの実行回数と、誰が開始したか（ユーザーのコマンド、ユーザーがスキル名を指定した後のモデル、自発的なモデルの実行）を調べる。たとえば、モデルに表示するか、ユーザーからの呼び出しのみとするかを決める場合	scripts/skill_usage_ledger.py index を実行し、その後 report を実行します（Claude と Codex の両方が対象です）。以下のスキル使用台帳を参照してください
Kimi CLI のセッション	history_index.py recall --provider kimi を実行し、名前が示されたセッションの wire.jsonl を読み取ります。以下のKimi CLIを参照してください
確認済みの Claude セッションを続行する	読み取りを中止し、daymade-claude-code:continue-claude-code-work を呼び出してください

「以前作ったあの X」（成果物系の対象）を探すときの基準

単語で見つからない場合は、検索語をむやみに増やすのではなく、次の基準に切り替えてください。

1. 時間の制約を最初の絞り込み条件にします。ユーザーが期間（「一昨日」「今週」）を指定した場合は、まず mtime でファイルシステムを絞り込みます（find <root> -newermt '<日期>' -name '*.html'）。候補を数十件まで絞ってから、形式で分類してください。全体を対象にしたキーワード検索は、時間で絞り込んだ後に行い、前には行いません。
2. セッションの scratchpad も必ず検索対象に含めます（/private/tmp/claude-$(id -u)/**/scratchpad/。macOS のシングルユーザー環境では通常 claude-501 です）。Claude セッションの成果物は通常ここに保存され、workspace には保存されません。「以前作った X」は scratchpad にある可能性がかなり高いため、成果物系の対象を探すときは明示的に含めてください。
3. 復元したバージョンが最終版とは限りません。session jsonl からファイルを復元しても（Write の content を取得しても）、ある時点での全量書き込みしか得られません。その後の増分 Edit は自動的には反映されず、復元した成果物は実ファイルのごく一部にすぎない可能性があります（実例：復元した断片は 28KB、完全版は 2.45MB）。開いて表示した際に「対象と違う」と感じたら、まず「完全版ではないのでは」と考えてください（元のパスにファイルが残っているか、session に後続の Edit がないか）。すぐに対象から除外しないでください。

事例（2026-09-18）：以前作った「クラスタリングの Web ページ」を探した際、全体を対象にしたキーワード検索を十数回行っても見つかりませんでした。対象は 9-13 の session scratchpad にずっとありました（favorites-ledger.html、2.45MB）。復元した 28KB の断片はスタイルなしで表示され、誤って対象外と判断されました。ユーザーが正確なパスを示した後、ようやく特定できました。

求められた出力を優先してください。ユーザーが生の入力を時系列で並べた表を求めているなら、その表を返してください。動機としてインシデントに触れていても、話題の分析に置き換えないでください。

証拠の範囲と網羅性

既定では、Claude の有効な設定ホームをすべて検出し、~/.claude/history-sources.json に登録されているすべてのアーカイブも対象にします。Session ID と内容の同一性に基づいて物理コピーの重複を除き、ファイルの mtime ではなくレコードのタイムスタンプを使います。明示的に 1 つの --home に限定した結果は、診断用の一部分であり、網羅性を保証するものではありません。

Claude のレコードラベルは保存用メタデータとして扱い、誰が書いたかの証明とはみなさないでください。トップレベルの type: user レコードには、コマンドのエンベロープ、フックの定型文、貼り付けられた文書全体、エージェントの口調の文章、またはシステムのプレースホルダーが含まれる場合があります。アシスタントが処理中に入力された人間のテキストは、origin.kind: human を持つ attachment.queued_command.prompt に保存されていることがあります。user レコードだけを読んで、こうした修正を見落とさないでください。

スキーマ、作成者、サイドチェーン、添付レコード、コンパクション、ファイル履歴のスナップショットを解釈する際は、references/session_file_format.md を読んでください。任意の BM25／ベクトルインデックスを構築または修復する前に、references/hybrid_history_recall.md を読んでください。インデックスを使った検出、トリアージ、復元の例については、references/workflow_examples.md を読んでください。メッセージのスキーマではなく、ディレクトリ構成が必要な場合は、references/claude_session_format.md を読んでください。ここでは、セッションがディスク上のどこにあるか、プロジェクトパスがどのようにディレクトリ名へ正規化されるか、sessions-index.json のフィールド、そしてトランスクリプトが切り詰められたのではなく要約されたことを示す compact_boundary マーカーを説明しています。

コマンド

スクリプトはすべて、この SKILL.md を基準に解決してください。同名のヘルパーをマシン内で探したり、JSONL パーサーをその場で作り直したりしないでください。

インデックスを使った検出

<skill-dir>/scripts/history_index.py status
<skill-dir>/scripts/history_index.py recall '<topic>' --provider claude --mode bm25

期待される出力：候補の Session ID とインデックスのカバレッジ。これはトピックの検出であり、最近のセッションを漏れなく一覧にするものではありません。完全な一覧が必要な場合は、現在バンドルされているインベントリーでは生の本文をスキャンすることになると伝えてください。

正確なセッション証拠

<skill-dir>/scripts/read_claude_session.py --session <SESSION_ID>

# Add this only when the caller intentionally wants to restrict lookup to one workspace.
<skill-dir>/scripts/read_claude_session.py --session <SESSION_ID> --project <workspace>

期待される出力：# Claude Code Session Evidence Briefing、セッションの識別情報、圧縮境界、時系列でのユーザー／アシスタント間の引き継ぎ、キューに入った人間からのプロンプト、終了理由、未解決の呼び出し、サブエージェントの状態、変更されたファイル、メモリ、現在のワークスペースの状態です。正確なリーダーは、圧縮前のレコードも含め、すべての物理的なセッションレコードを解析します。デフォルトの表示では長いターンを省略し、isMeta: true で、同じ記録上の系譜にある Skill 呼び出しと一致する一意の先行 sourceToolUseID を持つ、単一テキストのランタイム Skill 本文のみを折りたたみます。Skill 名とレコードの位置を示します。--full を指定すると、これらの本文を展開し、文字数による省略を解除します。人間が貼り付けた内容、キューに入ったプロンプト、混在レコード、出所が不確かな内容は、通常の省略制限の範囲で表示されます。生のレコード、抽出されたタイムラインテキスト、ツール証拠のエクスポートは変更されません。アクティブなコピーと登録済みアーカイブのコピーを確認し、同一のコピー、または厳密な追記のみの上位コピーだけを受け入れます。コピーの不一致、複数のセッション識別情報、レコードレベルのセッション識別情報の欠落、不正な JSONL、または読み取り不能なバイト列がある場合は、明示的に失敗します。正確な Session ID が指定され、--project が指定されていない場合は、検出されたすべてのアクティブなホームと登録済みアーカイブを対象に、すべてのプロジェクトを検索します。--project が明示的に指定された場合は、そのスコープに厳密に限定されます。ファイル名だけではセッションの識別情報を証明できません。タスクの終了、ローカルコマンドの出力、cwd の記録を解釈する前に、ローカルランタイムと作業ディレクトリの証拠をお読みください。

元のツール呼び出し／結果の証拠

特定のバックアップ、転送、継続コマンド、またはツールの受領記録にこのモードを使用します。まず対象の Session を正確に 1 つ特定してください。ブリーフィング全体を出力したり、生の履歴パーサーを再作成したりしてツールの証拠を取得しないでください。

<skill-dir>/scripts/read_claude_session.py --session <SESSION_ID> \
  --tool-evidence --tool Bash --contains 'scp' --contains 'backup'
<skill-dir>/scripts/read_claude_session.py --session <SESSION_ID> \
  --tool-evidence --ordinal 4:6 --from <ISO_WITH_TIMEZONE> --to <ISO_WITH_TIMEZONE>
<skill-dir>/scripts/read_claude_session.py --session <SESSION_ID> \
  --tool-evidence --subagent-path workflows/<run>/agent-<id>.jsonl --tool Bash

# Save the complete selected payload when it exceeds the bounded response.
<skill-dir>/scripts/read_claude_session.py --session <SESSION_ID> \
  --tool-evidence --tool Bash --contains 'scp' --full > /absolute/path/tool-evidence.json

元の tool_use と tool_result ブロック、選択したソースの SHA-256、1 から始まる物理行番号とコンテンツブロック座標、レコード UUID／親 UUID、タイムスタンプ、cwd、記録されたエージェント／サイドチェーン ID を含む JSON エンベロープが 1 つ返されます。 デフォルトでは、このモードは選択したメインのトランスクリプトのみを読み取り、保存されたサイドチェーンも含めます。既知のサブエージェントのリーフを 1 つ読み取るには、--subagent-path agent-<id>.jsonl または --subagent-path workflows/<run>/agent-<id>.jsonl を追加します。パスは、その Session の subagents/ ディレクトリからの相対パスです。実行全体からの相対パスを指定してください。ベース名だけでは、Workflow の実行間で重複するエージェント ID を区別できません。パスが存在しない、空である、範囲外に出る、または不明な場合は、証拠をエクスポートせずに失敗します。選択されたリーフのツールブロックには、一致するエージェント ID と親 Session ID が含まれている必要があります。JSON のソース範囲と subagent_files_read に、実際に読み取られた対象が示されます。それ以外のリーフは除外されます。 どちらのモードも、現在の Git 状態やメモリは読み取りません。 そのトランスクリプト内のすべての物理レコードを検証します。証拠の出力では、無関係な会話の文章は省略されます。グローバル検索で確認するのは、アクティブなホームディレクトリと登録済みアーカイブにある、名前が正確に <SESSION_ID>.jsonl のファイルのみです。名前を変更したアーカイブは、その検索対象外です。既存の検出機能で名前変更後のファイルを検出できる場合は、範囲を明示的に限定した --project を渡してください。レコードレベルの ID、不正な形式／読み取り不能な入力、異なる内容のコピーに対する制限も引き続き適用されます。読み取り中にソースが変更されると、明示的に失敗します。この読み取りだけを再実行してください。

セレクターを少なくとも 1 つ指定してください。正確で大文字と小文字を区別するツール名の候補を指定するには、--tool NAME を繰り返します。--contains TEXT を繰り返すと、各グループの元の文字列値のどこか（ネストされた呼び出し入力や結果のコンテンツを含む）に、指定したすべての大文字と小文字を区別するリテラルが含まれていることを必須にできます。孤立した結果は、ツール名フィルターには一致しません。--tools は --tool-evidence のエイリアスです。--ordinal N または N:M は、他のフィルターを適用する前に、最初に物理的に現れた順に 1 から始まるグループ番号を選択します。 時間範囲の境界は両端を含み、最初の呼び出しのタイムスタンプ、または最初の孤立した結果のタイムスタンプを使用します。日時にはタイムゾーンが必要です。日付のみの境界には、マシンのローカル日付が使用されます。時間フィルターによって除外されたタイムスタンプの欠損または無効の件数が集計されます。

記録されたエージェント／サイドチェーンのコンテキスト内で、どちらが先に現れたかに関係なく、ツール使用 ID を基準に対応付けます。ID が重複する場合もすべてのブロックを保持し、ambiguous とラベル付けします。対応する相手がない場合は missing_call または missing_result、ID がない場合は missing_id とラベル付けします。これらのステータスは、証拠が利用可能かどうかを示すものであり、実行の成功を示すものではありません。アクションが成功したと主張する前に、元の結果の error／content フィールドを確認してください。

返された一致を完全なものとして扱う前に、coverage.output_complete を確認してください。--max-output-bytes は、末尾の改行を含む UTF-8 JSON エンベロープ全体のサイズを制限します。現在のデフォルト値については、CLI ヘルプを参照してください。 一致した内容が大きい場合、block の代わりに、元の文字数を含む不完全であることが明示された block_json_prefix が返されることがあります。後続のグループが省略され、その件数と first_omitted_ordinal が示される場合もあります。上限を増やすか、--full を絶対パスのローカル出力先にリダイレクトして、選択したペイロード全体を取得してください。--full を指定すると、このモードのバイト数上限が解除されます。メタデータだけでも収まらない場合は、証拠を出力せずに読み取りが失敗します。終了コード 0 は選択されたグループが 1 つ以上あることを示し、1 は一致なし、またはソース／読み取りエラーを示し、2 は無効な引数を示します。stderr と coverage を確認して、これらのケースを区別してください。時間範囲に空白がある場合やソースが除外された場合に一致が 0 件でも、アクションが発生しなかった証拠にはなりません。

フック監査行の背後にあるコマンド

フック監査ログには、コマンドのテキストではなく、sid=<SESSION_ID> cmd_sha256=<HEX> が記録されることがよくあります。行を、それを生成したツール呼び出しに照合します。

<skill-dir>/scripts/read_claude_session.py --session <SESSION_ID> --find-command-sha256 <HEX>

想定される出力は、# Tool calls whose command has SHA-256 … という見出し、調査したトランスクリプトファイル数とツール呼び出し数、一致数、そして各一致についてファイルと行、タイムスタンプ、レコードの UUID、ツール名と ID、cwd、およびフェンスで囲まれた完全なコマンドです。終了コード 0 は 1 件以上の一致、1 は一致なし、2 はダイジェストの形式不正または --session の指定漏れを意味します。ダイジェストは、UTF-8 としてエンコードされた tool_input.command の SHA-256 です。サブエージェント内で発生したフックイベントには親の Session ID が付与されるため、照合では <SESSION_ID>/subagents/*.jsonl と <SESSION_ID>/subagents/workflows/*/agent-*.jsonl も検索します。メイントランスクリプトだけを検索すると、これらの呼び出しを見落とします。エージェント／Task のプロンプト照合とブリーフィングのサブエージェント一覧でも、再帰的な履歴の検出は行わず、同じ Session の範囲内のレイアウトを使用します。一致結果と一覧には、相対パス内の Workflow 実行が保持されます。形式不正または対象外の一覧項目はカバレッジ不明として報告され、完了済みのエージェントとして扱われることはありません。ツールの証拠として数えるのは、元のアシスタント／ユーザーイベントレコードのみです。診断用のリクエスト形式のコピーは除外されます。ブリーフィングとは異なり、この照合では解析できない行をスキップして件数を数えるため、書き込み中の Session でも動作します。スキップされた行がある状態で一致数が 0 でも、呼び出しが存在しないことの証明にはなりません。

インデックス化されたコンテンツの検索

<skill-dir>/scripts/history_index.py status
<skill-dir>/scripts/history_index.py recall '<keyword>' \
  --mode bm25 --provider claude --exclude-session <CURRENT_ID>

インデックスのプロバイダーのカバレッジと最終インデックス作成時刻を確認します。該当する Session ID のみを、完全一致セッションリーダーで開き、元のレコードを検証します。インデックス検索で返されるのは、順位付けされた文章の候補であり、思考、ツールの結果、添付ファイル、またはインデックス化されていないレコードの全件一覧ではありません。生の analyze_sessions.py search エントリーは、ライブストアでは無効になっています。日付フラグによる絞り込みは、ファイルを読み込んだ後に行われるためです。

保存されたロールを絞り込むには --role user または --role assistant を使用し、完全一致する部分文字列を必須にするには --phrase '<literal text>' を繰り返し指定します。これらのフィルターは BM25 とベクトルの両方の候補を絞り込みます。--terms が絞り込むのは FTS の検索経路のみです。返される record_key、source_kind、human_authorship は出所を示すものであり、人間の発言者であることを認証するものではありません。「あなたが言った」と述べる前に、元のレコードを確認してください。Codex のツール結果はこの文章インデックスの対象外です。選択した Codex の候補は、read-codex-history の元のツール／レコードの証拠を確認する経路に渡してください。元の値は、コンテンツを自動的に編集せずにエクスポートします。関連する事実についての結果が返っても、要求された命題への回答になるとは限りません。

人間の入力のエクスポート

<skill-dir>/scripts/extract_user_messages.py \
  <persistent-output-base> --days 7 --group-by session

これにより Markdown と HTML が生成されます。ストレージに混入したデータと人間の文章を分離し、キューに入ったプロンプトを復元します。タイムスタンプ、重複、Session の境界を保持してください。依頼がない限り、テーマ別の分類を追加で行わないでください。

削除されたコンテンツの復元

復元ではファイルが書き込まれるため、通常の読み取りとは分けてください。まず、対象の Session ファイルに対して復元レポートを実行し、提案されたすべての保存先を確認します。その後、ユーザーからコンテンツの復元を依頼された場合にのみ書き込みます。現在のプロジェクトツリーに直接上書きして復元してはいけません。

スキル使用状況の台帳

「実際にどのスキルを使っているのか、誰が起動するのか」に答えます。これは増分インデックス（~/.claude-history-index/skill-usage-v1.db）です。最初の index では、Claude と Codex のすべてのセッションを一度解析し、その後の実行ではサイズまたは更新日時が変わったファイルだけを再解析します。レポートは台帳を読み取り、生の履歴は読み取りません。

python3 scripts/skill_usage_ledger.py index            # --no-codex to skip Codex
python3 scripts/skill_usage_ledger.py report --override user-invocable-only
python3 scripts/skill_usage_ledger.py report <skill> [<skill> ...] --since 2026-06-01 --until 2026-09-24
python3 scripts/skill_usage_ledger.py status           # freshness + what is not covered

列は次のとおりです。user_command（ユーザーが /X または Codex の $X と入力）、model_named（モデルが X を呼び出し、直近の人間のプロンプトに X の名前が含まれていた）、model_auto（モデルがプロンプトなしで X を呼び出した）、last_model_use、blocked（X はモデルから呼び出せないため Claude がモデル呼び出しを拒否したもの。モデルは X を使おうとしたものの、使えなかったため、使用回数には含めません）、およびスキルの現在の skillOverrides 値です。--override STATE を指定すると、記録された使用がない、その状態のスキルも一覧表示します。行は単純な名前でグループ化されます。これは skillOverrides がキーとして使う名前です。identities には、1 行にまとめられた修飾名が一覧表示されます。複数の名前空間（review、suite:review など）がある場合、同じ名前のスキルがまとめて集計されています。分けて集計するには --exact を指定して再実行します。

結論を出す際は、必ず次の制限を踏まえてください。

• ユーザーのみが呼び出せるスキルは、モデルから呼び出せません。そのため、model_auto の件数は非表示になった日で止まります。生涯の合計ではなく、その日より前と後の使用状況を比較してください。
• Codex でのモデル使用は、モデルが 1 つの .../X/SKILL.md を読み取ったことから推定されます。通常のシェル読み取りで X の SKILL.md を編集または監査したセッションも、同じように見えます。1 つのコマンドで複数の SKILL.md を読み取った場合は bulk_read として記録され、除外されます。
• 対象外：Claude のサブエージェント内で呼び出されたスキル、Kimi CLI、読み取りを行わず記憶に基づいて使用された Codex のスキル。使用記録がゼロというのは「対象のストアでは確認できなかった」という意味であり、「一度も使われていない」という意味ではありません。

読み取り結果の契約

すべての回答には、次の内容を記載する必要があります。

1. 読み取ったソース — 有効なホーム、登録済みアーカイブ、対象の Session ファイル。
2. 対象範囲 — Session ID と内部の時間範囲。
3. 結果 — 生の時系列または該当する証拠を、指定された形式で提示します。
4. 不足事項 — 読み取れないファイル、欠落している親レコードや添付ファイルのバイト列、除外されたサイドチェーン、または検索対象に含めなかった範囲。

「見つからない」とは「記載された対象範囲内で見つからない」という意味であり、「一度も起きていない」という意味ではありません。インデックスによる想起では、一部のレコードタイプが省略されます。この制限とインデックスの到達範囲を明記してください。順位付けされたヒットがゼロでも、ラベルを完全に調査できたかのように提示してはいけません。簡潔な要約を逐語的な履歴と呼ばないでください。これは継続作業のための補助情報であり、重要な主張は生のレコードと現在のワークスペースに照らして確認する必要があります。

否定的または断定的な主張（「一度も言っていない」「一度も出てこない」「起きるはずがなかった」「満たすことは不可能」など）を書く前に、次のチェックリストを完了してください。

1. ユーザー／アシスタントのテキストだけでなく、すべてのレコードタイプを確認します。 リテラル文字列の grep では、attachment（queued_command.prompt）、tool_result、thinking も検索対象にする必要があります。レコードのトップレベルの type／isMeta だけでは、人間が作成したものかどうかを証明も否定もできません。attachment を確認せずに、type:user と assistant でヒットを分類すると、ターンの途中に実際に人間が入力したコマンドが「言われていない」と報告されることになります。
2. 「復元不可能」とする前に、手間の少ない次の手段を試します。 インデックスによる想起、または特定済みの Session の再読み込みで不足を埋められるなら、実行してください。検証していない境界は、境界の証拠にはなりません。
3. 矛盾する当事者の証言があれば、問題を再調査します。証言を読んだ結果より優先度を下げてはいけません。 ユーザーが何かをしたと述べているのに、証拠がそれに反する場合は、それを結論として擁護するのではなく、(1) と (2) をやり直すべき合図として扱ってください。

ツール結果に切り捨てまたはページ分割の警告（「X〜Y 行を表示中。全 Z 行……このページだけを根拠に回答しないでください」など）がある場合、その警告に従ってください。それに依存する結論を出す前に、残りも読み取ってください。

ガードレール

• 通常の読み取りモードは読み取り専用にしてください。
• claude --resume や claude --continue を実行しないでください。
• 会話の時系列を判断するためにファイルの mtime を使わないでください。
• 履歴全体をそのまま走査しないでください。インデックスを使うか、まず対象のセッションを正確に選択してください。全ファイルを読んだ後に日付フィルターを適用しても、処理量は制限されません。インデックスのカバレッジが不完全な場合は、走査せずにその不足を報告してください。
• ユーザーの明示的な承認なしに、未加工の履歴をローカルマシンの外部と共有しないでください。履歴には認証情報や非公開の業務情報が含まれている可能性があります。
• タイムアウトや不正なソースが発生した場合、検索が完了したと報告しないでください。
• Read-result contract のチェックリストをすべて確認せずに、否定的な断定（「一度も言っていない」「一度も現れない」「実現不可能」など）をしないでください。

サーフェスの契約

セッションで初めて使うときは、python3 scripts/surface_version.py を一度実行し、12 文字のフィンガープリントを記録してください。これは、このスキルの scripts/**/*.py コードサーフェスの sha256 です。このスキルについて最後に確認したフィンガープリントと異なる場合、コードが変更されています。コンテキスト内に残った記憶をもとに作業する前に、ディスクからこの SKILL.md と参照資料を読み直してください。フィンガープリントが対象とするのはコードのみで、ドキュメントの編集では変わりません。

CC の動作に関する主張

references/cc-behavior-claims.json は、このスキルが依存する「Claude Code は X のように動作する」という主張（Read の行番号付け、tool_use/tool_result の順序、AUQ の回答形式、中断マーカー、プランのバインド、サイドチェーンの意味論）をリリースごとに記録する台帳です。python3 scripts/verify_cc_claims.py --fixtures は CI ゲートです。終了コード 1 は、実装、フィクスチャ、または台帳のいずれかで主張された形式に問題があることを意味します。--corpus <dir> は、実際のトランスクリプトに照らして台帳を再検証します。終了コード 2 はスキーマの変化を意味します。これはテスト失敗ではなく、正確性に関わる作業です。observed/last_verified/ evidence を更新するか実装を修正し、変化した主張を CHANGELOG に記載してください。

ルーターとレガシー互換性

daymade-claude-code:local-conversation-history はプロバイダー横断型のルーターです。Claude の読み取りとすべての Kimi CLI リクエストをここに送り、このスキルのアイデンティティや証拠に関する契約を置き換えるものではありません。新しい Codex リクエストは daymade-claude-code:read-codex-history にルーティングされます。

Kimi CLI はこのスキルの現行サーフェスであり、レガシーではありません。 Kimi CLI 独自のリーダーはありません。検出にはインデックス付き検索を使い、その後、指定されたセッションのワイヤーレコードを調べてください。Claude のデータだけをもとに Kimi に関する質問に答えると、「一度も起きていない」という誤った結論になります。ホームの解決順序は --kimi-home > KIMI_HOME > ~/.kimi-code です。

デフォルトのホームが存在しない場合でも、ストアが見つからないわけではありません。別の場所にあり、ツールもそのことを示します。 Kimi デスクトップクライアントは CLI を独自の Electron ランタイムに同梱しており、セッションをホームディレクトリではなくそのランタイム内に保存します。そのため、実際の会話が何百件もあるマシンでも、デフォルトのパスに対しては何も見つからないことがあります。インベントリには診断用の行として試したホームが表示されます。Kimi の結果が空であると報告する前に、その行を確認してください。「ホームが見つからない」と「会話がない」は異なる結果です。

推測せず、次の順に実際のホームを見つけてください：

1. Kimiを対象にしてインデックスが作成されたことがある場合は、リコールインデックスに問い合わせます。 scripts/history_index.py status を実行すると scope.sources が表示され、そこに provider: kimi のエントリがあれば、インデックス作成元の絶対パス home が含まれています。Kimiのインデックスが一度作成された後でないと結果は返されないため、設定済みのマシンでは最速の方法ですが、新規環境では何も表示されません。
2. 実行中のプロセスからデスクトップクライアントのユーザーデータディレクトリを確認します。 Electronアプリのコマンドラインには --user-data-dir が含まれます （ps ax | grep -i <client>）。バンドルされたCLIはその直下にはありません。ホームは <user-data-dir>/daimon-share/daimon/runtime/kimi-code/home です。 末尾の home に注意してください。.../runtime/kimi-code はCLIのインストールディレクトリで、ステップ4のテストに失敗します。その子ディレクトリである home/ がストアです。
3. トランスクリプトレコードの meta.sourcePath をたどります。 クライアントは会話を <user-data-dir>/daimon-share/daimon/agents/<agent>/memory/transcripts/days/<YYYY-MM-DD>/conv-*.jsonl に複製します。各レコードの meta.sourcePath は、元となった絶対パスで、そこにホームが含まれています。kimi-agent/conversation-archive.json は確認しないでください。このファイルに含まれるのはタイトルとタイムスタンプだけで、パス情報はありません。
4. 使用前に確認します。 実際のKimiホームには session_index.jsonl と sessions/wd_<workspace>_<hash>/ ツリーがあります。両方が存在することを確認してから、--kimi-home に指定します。このテストによって、ストアと1階層上のCLIインストールディレクトリを区別できます。

見つかったストアから正しく読み取れるかどうかは、スキーマの情報で判断します。新しいビルドでは各セッションの state.json から id と cwd が削除され、作業ディレクトリは session_index.jsonl にのみ保持されます。そのため、セッションのプロジェクトはセッション自身の状態ファイルではなく、そのマップから取得する必要があります。また、同じ sessions/ ツリーには、実際の会話と並んで内部エージェントの実行記録も保存されています。これらはディレクトリ名のプレフィックスだけで区別されています。タイトル生成、Vaultのメンテナンス、スキルの要約は機械による記録であり、履歴ではありません。実際のストアでは、こうした記録が本物の会話を上回っていました。

Kimiのカバレッジ確認。 history_index.py status にKimiが含まれていることを確認し、インデックスの最新対象時点を確認します。インデックス未作成のKimiセッションや、それより新しいKimiセッションは、リコールの対象として認識されません。

見つかったKimiセッションを読み取るための同梱コマンドはありません。 read_claude_session.py が解決するのはClaudeのセッションファイルだけで、KimiのセッションIDを指定するとゼロ以外の終了コードで終了します。Kimiで利用できるのは、インベントリとインデックス済みのリコールです。会話の内容を表示するには、セッションの agents/<agent>/wire.jsonl を直接読み取り、上記のレコードタイプに基づいて解釈してください。Claudeリーダーが生成する検証済みの再構成と同じものとして示すのではなく、ファイルを直接読み取ったものであることを伝えてください。

以前の claude-code-history-files-finder には、オプションのCodexおよびKimi向けブランチもありました。その元の説明は、移行とリグレッションの証拠としてのみ、変更されていないスナップショットとして references/legacy_cross_provider_workflow.md に保存されています。旧仕様の内容を確認するために読むものとし、現在提供されている機能の説明としては参照しないでください。