ce-sessions

/ce-sessions

Claude Code、Codex、Cursor 全体のセッション履歴を検索し、過去のセッションで取り組んだこと、試したこと、決定したこと、学んだことについて、情報をまとめます。

使用方法

/ce-sessions [question or topic]
/ce-sessions

事前解決済みコンテキスト

Git ブランチ（事前解決済み）： !git rev-parse --abbrev-ref HEAD 2>/dev/null || true

上の行が通常のブランチ名（feat/my-branch など）に解決された場合は、その名前をブランチの絞り込みに使用し、合成サブエージェントに渡します。バッククォートで囲まれたコマンド文字列のまま、または空の場合は、実行時にブランチを特定してください。

リポジトリのルート（事前解決済み）： !git rev-parse --show-toplevel 2>/dev/null || true

上の行がパスに解決された場合は、その末尾のパス要素をリポジトリのフォルダー名として取得し、セッションの検出に使用します。空の場合、またはバッククォートで囲まれたコマンド文字列のままの場合は、実行時にリポジトリ名を特定してください。

注：2026年

現在は2026年です。セッションのタイムスタンプを解釈する際に、この情報を使用してください。

ガードレール

オーケストレーションと情報の合成を行う際は、常に以下のルールに従ってください。

• セッションファイル全体をコンテキストに読み込まないでください。 セッションファイルのサイズは1～7MBになることがあります。必ず抽出スクリプトで絞り込んでから、出力内容を検討してください。
• ツール呼び出しの入力や出力をそのまま抽出または再現しないでください。 試したことと結果を要約してください。
• 思考ブロックや推論ブロックの内容を含めないでください。 Claude Codeの思考ブロックは内部推論であり、Codexの推論ブロックは暗号化されています。どちらも実用的な情報ではありません。
• 現在のセッションを分析しないでください。 その会話履歴は呼び出し元がすでに参照できます。
• 技術的な内容を取り上げ、個人的な内容は取り上げないでください。 セッションには認証情報、不満、まとまっていない意見など、あらゆる内容が含まれます。技術的な要約に含める内容は慎重に判断してください。
• アクセスエラーが発生したら、すぐに処理を中止してください。 権限の問題でセッションの検出に失敗した場合は、直ちにその問題を報告してください。同じ処理を別のツールや方法で再試行しないでください。結果は変わらず、トークンを無駄に消費します。

実行

質問の引数が指定されていない場合は、セッション履歴について何を知りたいのか、ユーザーに尋ねてください。プラットフォームのブロッキング質問ツールを使用してください。Claude CodeではAskUserQuestion（スキーマが読み込まれていない場合は、先にToolSearchをselect:AskUserQuestionとともに呼び出してください）、Codexではrequest_user_input、Geminiではask_user、Piではask_user（pi-ask-user拡張機能が必要）を使用します。ハーネスにブロッキングツールがない場合、または呼び出しでエラーが発生した場合（Codexの編集モードなど）に限り、通常のテキストで質問してください。スキーマの読み込みが必要だからという理由で質問を省略してはいけません。

ステップ1 — スキャン期間を決める

ユーザーの質問から期間を推定してください。まず短い期間でスキャンし、関連する情報が見つからない場合にのみ期間を広げます。

目安	初期スキャン期間
「今日」「今朝」	1日
「最近」「ここ数日」「今週」、または期間の指定なし	7日
「ここ数週間」「今月」	30日
「ここ数か月」、機能の広範な履歴	90日

Claude Codeでは、デフォルトでセッション履歴が約30日間保持されます。より長い期間を指定しても、保持期間が延長されていない限り、Claude Codeのセッションは見つからないことがあります。

ステップ2 — セッションを検出してメタデータを抽出する

検出とメタデータ抽出のパイプラインを実行します（extract-metadata.pyをバッチモードで実行できるようにする、null区切りのxargsによる強化処理を維持してください）。

bash scripts/discover-sessions.sh <repo> <days> | tr '\n' '\0' | xargs -0 python3 scripts/extract-metadata.py --cwd-filter <repo>

各出力行は、セッションを記述するJSONオブジェクトです（プラットフォーム、ファイル、サイズ、タイムスタンプ、セッション、プラットフォーム固有のフィールドを含みます）。最後の_meta行には、files_processedとparse_errorsが含まれます。

インベントリの_meta行でfiles_processed: 0となっている場合は、「関連する過去のセッションはありません」と返し、処理を終了してください。

parse_errors > 0の場合は、一部のセッションを解析できなかったことを伝え、取得できた情報を使って処理を続けてください。

対象プラットフォームを絞り込むには、discover-sessions.shの呼び出しに--platform claude、--platform codex、または--platform cursorを追加してください。デフォルトでは、3つすべてを対象にします。

ステップ 3 — フィルタリングとランキング

深掘りする価値のあるセッションを選ぶため、以下のフィルターを順番に適用します。

1. ブランチフィルター（Claude Code のみ）。 branch == dispatch_branch が完全に一致するセッション、またはブランチ名に質問のトピックのキーワードが含まれるセッションを残します（例: 「auth middleware」に関する質問はブランチ feat/auth-fix、chore/auth-refactor にマッチします）。Codex のセッションは gitBranch を持たないため、このフィルターはスキップします。

2. ブランチフィルターでセッションが 0 件だった場合、または Codex セッションを処理している場合:

   • 質問のトピックから 2〜4 個のキーワードを導出します。「auth middleware で最近発生したクラッシュで、セッション検証が有効なトークンを拒否する」という場合は auth,middleware,session,token（または類似のもの）を導出します。
   • extract-metadata.py の呼び出しに --keyword K1,K2,... を追加して、ディスカバリーパイプラインを再度起動します。スクリプトは match_count が 0 でないセッションと、キーワードごとのカウントを返します。
   • files_matched: 0 の場合、「関連する過去のセッションはありません」を返して停止します。 何も抽出しないでください。
   • files_matched > 0 の場合、それらのセッションを候補として扱います。match_count でランク付けし、同点の場合はキーワードごとのカウントで順位を決定します。

3. スキャン期間外のセッションを除外します。 last_ts が利用可能な場合はそれを使用し、なければ ts にフォールバックします。両方とも期間の開始より前であるセッションは破棄します。

4. 現在のセッションを除外します — その会話履歴はすでに呼び出し元が利用できます。

5. 深掘り上限を適用します。 すべてのプラットフォームを通じて最大 5 セッション とします。ブランチマッチ → match_count → ファイルサイズ 30KB 超 → 新しさ、の順で絞り込みます。

6. フィルタリング後に少なくとも 1 つのセッションが残っている場合のみ続行します。 そうでなければ「関連する過去のセッションはありません」を返して停止します。

注意: gitBranch は最初のユーザーメッセージでのみ取得されます。 main で開始し、セッション途中の git checkout でフィーチャーブランチに切り替えて実質的な作業を行ったセッションは、branch: "main" として記録されます。ブランチマッチが何も返さないことは決定的な証拠ではありません — だからこそステップ 2 のキーワードフィルターのフォールバックが必要なのです。

ステップ 4 — スクラッチスペースのセットアップ

実行ごとの使い捨てスクラッチディレクトリを作成します:

SCRATCH=$(mktemp -d -t ce-sessions-XXXXXX)

絶対パスを取得し、ステップ 5 とステップ 6 に引き継ぎます。クリーンアップはセッション終了時に OS が処理しますが、ステップ 7 の最後に明示的な rm -rf "$SCRATCH" を実行しても害はなく、意図が明確になります。

ステップ 5 — セッションごとのコンテンツを抽出する（ファイル経由）

選択した各セッションについて、--output を付けてスケルトン抽出器を実行し、コンテンツをスクラッチファイルに直接書き込みます — 抽出バイトがオーケストレーターのツール結果を経由して往復することはありません:

python3 scripts/extract-skeleton.py --output "$SCRATCH/<session-id>.skeleton.txt" < <session-file>

標準出力には 1 行の JSON ステータス（{"_meta": true, "wrote": "...", "bytes": N, ...}）のみが出力されます。各ステータス行から bytes と parse_errors を取得します。

条件付きテール抽出 — スケルトンが調査の途中で終了した場合（最後に見えるターンが未解決のツール呼び出しである、またはアシスタントが結論なしにデバッグの途中である）、tail 形状で再抽出します:

python3 scripts/extract-skeleton.py --output "$SCRATCH/<session-id>.skeleton.tail.txt" < <session-file>

（スケルトンスクリプトは tail:N の上限を直接受け付けません。テールのみのビューが必要な場合は、抽出後にシェルでスクラッチファイルを tail -n 50 で後処理します。これは先頭の出力からセッションが調査途中で切り捨てられたことが示唆される場合にのみ使用してください。）

条件付きエラーモード — 調査の行き詰まりが価値を持つ可能性が高いセッション向け:

python3 scripts/extract-errors.py --output "$SCRATCH/<session-id>.errors.txt" < <session-file>

選択的に使用してください — 何がうまくいかなかったかを理解することが価値を加える場合にのみ。Cursor エージェントのトランスクリプトはツール結果を記録しないため、エラーモードは Cursor セッションでは何も生成しません。

ステップ 6 — 統合サブエージェントをディスパッチする

プラットフォームのサブエージェントプリミティブ（Claude Code では Agent、Codex では spawn_agent、pi-subagents 拡張機能を介した Pi では subagent）を使って、ce-session-historian サブエージェントをディスパッチします。mode パラメーターは省略し、ユーザーが設定した権限設定が適用されるようにします。中位モデル（例：Claude Code では model: "sonnet"）で実行します。統合担当に最先端の推論能力は必要ありません。

ディスパッチプロンプトは、エージェントへの入力契約です。次のフィールドを渡します。

• problem_topic — 具体的な質問を示す1文です。ユーザーの主張から引用するか、存在しない場合は引数なしプロンプトへの回答から引用します。
• scratch_dir — $SCRATCH の絶対パスです。
• sessions — 抽出したセッションごとに1つずつ、次の内容を含むオブジェクトの配列です。
  • path — スケルトンファイルの絶対パスです（抽出した場合は、エラーファイルの errors_path も任意で指定します）。
  • platform — claude、codex、cursor のいずれかです。
  • branch — 存在する場合は Git ブランチです（Claude Code のみ）。
  • cwd — 存在する場合は作業ディレクトリです（Codex のみ）。
  • ts と last_ts — セッションのタイムスタンプです。
  • match_count と keyword_matches — キーワードフィルタリングを使用した場合に指定します。
• output_schema — エージェントの応答が従うべき構造です。デフォルトのスキーマ：

  Structure your response with these sections (omit any with no findings):
  - What was tried before
  - What didn't work
  - Key decisions
  - Related context
  

  呼び出し元（例：ce-compound）がスキル引数でスキーマを指定した場合は、そのまま渡します。

ディスパッチの形式例：

Synthesize findings from these prior sessions:

Problem topic: <one-line topic>

Sessions to read (paths in $SCRATCH):
1. /tmp/ce-sessions-XXXX/abc123.skeleton.txt
   platform=claude branch=feat/auth-fix ts=2026-05-01
2. /tmp/ce-sessions-XXXX/def456.skeleton.txt  errors=/tmp/ce-sessions-XXXX/def456.errors.txt
   platform=codex cwd=/Users/.../my-project ts=2026-05-03
...

Output schema:
- What was tried before
- What didn't work
- Key decisions
- Related context

Filter rule: only surface findings directly relevant to this specific problem.
Ignore unrelated work from the same sessions or branches.

エージェントは、プラットフォーム固有のファイル読み取りツールで各パスを読み込み、文章形式の調査結果を返します。一括抽出された内容はエージェントのサブエージェントコンテキスト内にのみ保持され、オーケストレーターの作業状態にはファイルパスと小規模なインベントリメタデータのみが残ります。

ステップ 7 — 調査結果を返す

統合担当の出力テキストを、そのまま呼び出し元に返します。検出またはキーワードフィルタリングの結果、セッションが0件だった場合（ステップ 2 またはステップ 3）は、文字列 no relevant prior sessions をそのまま返します。

必要に応じて、一時ファイルをクリーンアップします。

rm -rf "$SCRATCH"

いずれにしても、最終的には OS がクリーンアップを処理します。明示的なクリーンアップは、それを期待する読者のためのものです。

出力

呼び出し元（通常は /ce-sessions と入力するユーザー、またはプラットフォームのスキル呼び出しプリミティブを介して ce-sessions を呼び出す別のスキル）が出力形式を指定していない場合は、何を検索したかを示す簡潔なヘッダーを含めます。

**Sessions searched**: [count] ([N] Claude Code, [N] Codex, [N] Cursor) | [date range]

続けて、統合担当による文章形式の調査結果を記載します。呼び出し元がスキーマを指定した場合は、そのまま従い、デフォルトのヘッダーは省略します。

時間の上限

回答が完成したら、すぐに停止します。数秒以内に確信を持って「関連する過去のセッションはありません」と判断できた場合、それで回答は完成です。時間を埋めるために検索を続けないでください。ステップ 3 の構造上の上限（詳細に調べるセッションは最大 5 件）とステップ 5 の条件付きの末尾／エラー抽出により、実行時間は設計上制限されています。

エラー処理

検出パイプラインに失敗した場合（例：ホームディレクトリを読み取れない、権限エラー）、エラーを呼び出し元に提示します。git log、ファイル一覧、その他の情報源で代用しないでください。このスキルが扱うのはセッションのメタデータと統合です。

抽出時の --output 書き込みに失敗した場合（ディスク容量不足、権限エラー）、明確なエラーを提示し、不完全なパスで統合担当をディスパッチしないでください。

いずれかのスクリプトの _meta が parse_errors > 0 を報告した場合は、ディスパッチプロンプトで抽出が不完全であることに触れて、処理を続行します。統合担当は調査結果で不完全な抽出について明示します。