session-handoff

ハンドオフセッション

応答形式

このスキル呼び出しに対する最初の応答は、次の行から始めます。

Entire Session Handoff:

その後に空行を入れ、本文を続けます。このヘッダーはこの呼び出しの最初の応答のみに付けてください。後続のターンや、エラー／早期終了の応答（セッションが見つからない場合、トランスクリプトがない場合）には付けません。ヘッダーがあることで、このスキルが実行され、実際の出力が生成されたことを示します。「未回答の質問」の分岐でもヘッダーを付けます。

停止 — 何かをする前に以下のルールを読んでください

1. 明確化の質問をしないでください。 セッションを自動検出し、トランスクリプトを読みます。
2. git log、git status、git branch、ps aux、その他の探索的なコマンドを実行しないでください。 以下に記載された entire CLI コマンドのみを使用してください。
3. 「続けてもよろしいですか？」や「続きを希望する場合はお知らせください」と言わないでください。 トランスクリプトを読み、作業を開始してください。例外：前のエージェントがユーザーに質問し、まだ回答を得ていない場合は、作業を続ける前に必ずその質問をしてください。

必須 CLI：entire 0.6.2+（session list --json、session info --transcript、session current --json|--transcript、checkpoint explain --json|--transcript|--raw-transcript --session-index N）。フラグが拒否された場合は、ユーザーにアップグレードを案内して停止してください。

フロー：アクティブセッションのハンドオフ（デフォルト — 引数なしの呼び出しと「current」／「active」にも適用）

ステップ 1：正規のワークツリーのパスを解決する

entire session current --json

出力が有効な JSON の場合は、worktree_path フィールドを読み取ります。これは Entire 自身が設定した、この呼び出しにおける正規のワークツリーのルートです。次のステップでは、出力された値をそのまま使用してください（cwd による推測は不要です。シンボリックリンク、/private/var／/var の違い、サブディレクトリからの呼び出しはすべて処理されます）。

出力が JSON でない場合（アクティブなセッションがないとき、Entire は No active session found in this worktree. を出力します）、正規のワークツリーのパスを null に設定し、ステップ 2 の双方向プレフィックス一致フォールバックを使用します。

ステップ 2：セッションを選択する

entire session list --json

各エントリには session_id、agent、status、worktree_path、started_at、last_active、turns、last_prompt、files_touched が含まれます。以下の順序でフィルターを適用します。

1. ワークツリーの範囲。 ステップ 1 で正規のワークツリーのパスを取得した場合は、worktree_path がその値と完全に一致するエントリを残します。取得できなかった場合は、cwd が worktree_path で始まるエントリ、または worktree_path が cwd で始まるエントリを残します。どちらのフィルターでもエントリが 0 件になった場合は、範囲を限定しないリストに戻します。ハンドオフを拒否するより、少し対象がずれたセッションを要約するほうが適切です。
2. ユーザーが指定したエージェントのフィルター（任意）。ユーザーが「codex」「claude」「kiro」「gemini」などを指定した場合は、agent が大文字と小文字を区別せず、その文字列を含むエントリのみを残します（そのため、gemini は Gemini CLI に一致します）。
3. 自分自身を除外。 このスキルを現在実行しているエージェント（例：Claude Code、Codex、Cursor、Gemini CLI、Copilot CLI、Factory AI Droid、OpenCode）に agent が一致するエントリを除外します。これによりリストが空になる場合は、このフィルターを取り消して自分自身を残します。これは、ユーザーがコンパクションのために自身の現在のセッションの要約を求めていることを意味します。この事実をアナウンス（ステップ 5）に記載してください。
4. 最新のセッションを選択。 last_active（なければ started_at）の降順で並べ、先頭を選びます。

フィルターを適用してもエントリが 0 件の場合（自分自身を含め、リストに該当するものが何もない場合）は、ヘッダーを付けずに 1 行のエラーを出力して停止します。

ステップ 3：生のトランスクリプトをストリーム出力する

entire session info <session_id> --transcript > /tmp/handoff-<session_id>.jsonl

スナップショットのサイズは、コマンド開始時点のファイルサイズで制限されます。ほとんどのエージェントでは出力は JSONL 形式で、Gemini CLI では単一の JSON ドキュメントです。

ステップ 4：会話内容を抽出する

JSONL エージェント（Claude Code / Codex / Cursor / Copilot CLI / Factory AI Droid / OpenCode）：

grep -E '"type":"(message|function_call|user|assistant)"' /tmp/handoff-<session_id>.jsonl | cut -c1-2000 | head -20    # original task
grep -E '"type":"(message|function_call|user|assistant)"' /tmp/handoff-<session_id>.jsonl | cut -c1-2000 | tail -100   # final state

Gemini CLI（単一の JSON ドキュメント — JSONL grep は使用しません）：

jq 'keys' /tmp/handoff-<session_id>.jsonl

Gemini CLI の最上位の構造はバージョンによって異なりますが、メッセージは messages、contents、history、turns のいずれかの下にあります。各エントリには role（user／model／function／tool）と、parts[].text、content、text のいずれかの下にあるコンテンツペイロードが含まれます。次のように、役割とテキストを時系列順に抽出します。

# Example — adapt the path based on what `jq 'keys'` showed.
jq -r '.messages[] | "\(.role): \([.parts[]? | .text // ""] | join(" "))"' /tmp/handoff-<session_id>.jsonl | head -20
jq -r '.messages[] | "\(.role): \([.parts[]? | .text // ""] | join(" "))"' /tmp/handoff-<session_id>.jsonl | tail -100

どちらの形式でもうまくいかない場合は、JSON ファイルに対して Read ツールを使い、確認してメッセージ配列を特定します。

抽出した行をそのままユーザーに見せないでください。これらはステップ 5 で使う入力です。

ステップ 5：告知し、要約し、提示する

告知。 本文の最初の行は次の形式にします：Handing off <agent> session — <turns> turns, last active <relative time>, ID <first-8-of-session-id>. 選択したセッションが自分自身のもの（ステップ 2 の自己フィルターのフォールバック）である場合は、前に1節の注記を付けます：Self-handoff (no other sessions in this worktree)。これにより、ユーザーは要約を読む前に選択ミスに気づくことができます。

要約の構成（内容がないセクションは省略してください。内容を捏造して埋めないでください）：

1. タスクの概要 — ユーザーの中心的な依頼、成功の基準、明示された制約。
2. 現在の状態 — 完了した作業：作成・変更したファイル、重要な決定、生成した成果物。
3. 重要な発見 — 見つかった技術的制約、決定の理由、発生したエラーとその解決方法、失敗したアプローチとその理由。
4. 次のステップ — 具体的な残作業、ブロッカー、優先順位。
5. 引き継ぐコンテキスト — ユーザーの好み、ドメインの詳細、セッション中に行った約束。
6. 未回答の質問（該当する場合のみ）— 前のエージェントの最後のメッセージでユーザーに質問した、または選択肢を提示したものの、回答がなかった場合は、その内容をそのまま記録します。

1つのバグ修正だけのセッションでは、「タスクの概要」＋「現在の状態」＋「次のステップ」だけでよい場合があります。調査のみのセッションでは、「タスクの概要」＋「重要な発見」だけでよい場合があります。空のセクションはあっても問題ありません。実際の内容がある場合にのみ補足してください。

続行。 告知と要約を提示します。

• セクション 6 がある場合は、その質問をユーザーに尋ね、回答を待ちます。デフォルトを選んではいけません。
• それ以外の場合は、ただちに作業を引き継いで進めます — 計画、コーディングなど、次のステップを実行します。許可を求めてはいけません。

フロー：チェックポイントの引き継ぎ（ユーザーがチェックポイント ID を提示した場合）

ステップ 1：セッションを列挙する

entire checkpoint explain <checkpoint-id> --json

エンベロープの sessions 配列には、各セッションが記載されています。複数セッションからなるチェックポイントはよくあります（並列エージェント、再試行、複数フェーズの作業など）。以前のセッションには、最新のセッションで前提とされている根拠、失敗したアプローチ、ユーザーの制約が含まれていることがよくあります。

ステップ 2：ストリームするセッションを選ぶ

• 1 セッション。 正規化されたコンパクトなトランスクリプトをストリームします。

  entire checkpoint explain <checkpoint-id> --transcript > /tmp/handoff-ckpt-<checkpoint-id>.jsonl
  

• 2～8 セッション。 インデックス 0～N-1 のすべてを順に処理します。--transcript のデフォルト（最新のセッションのみ）に依存してはいけません。

  # for N in 0 .. sessions.length-1
  entire checkpoint explain <checkpoint-id> --raw-transcript --session-index <N> > /tmp/handoff-ckpt-<checkpoint-id>-<N>.jsonl
  

• 8 セッション超。 sessions 配列をタイムスタンプ（started_at、またはエンベロープにある該当フィールド）の降順で並べ替え、直近の 8 セッションを選びます。告知に上限を記載します：<M of N> sessions summarized; oldest <M-N> elided as too old to matter. これにより、直近の根拠を網羅しつつ、スキルの範囲を適切に保てます。

--raw-transcript を指定すると、エージェントごとの生バイト列が保持されるため、同じ JSONL grep 抽出を使用できます。インデックス 0 は時系列で最初のセッションです。

ステップ 3：抽出、告知、要約、続行

各 /tmp/handoff-ckpt-*.jsonl に対して、ファイルごとに先頭と末尾を抽出するステップ 4 を実行し、5 セクションの要約を 1 つに統合します。「重要な発見」と「引き継ぐコンテキスト」には以前のセッションを情報源として使用し、「現在の状態」と「次のステップ」には最新のセッションを反映します。空のセクションに関するルールは、アクティブセッションのフローに従います。その後、アクティブセッションのフローのステップ 5 に従って告知して提示します。ただし、告知はチェックポイントのコンテキストに合わせて調整します（Handing off checkpoint <short-id> — <M> sessions, <total turns> turns total.）。