handoff

name	handoff
description	現在のセッションの作業状態を、次のセッションのClaudeがそのまま作業を再開できる引き継ぎブロックにまとめる
user-invocable	true
allowed-tools	Bash(git log*), Bash(git diff*), Bash(git status*), Bash(git rev-parse*)

コンテキストが膨らんできたタイミングで、現在の作業状態を「次のセッションのClaudeへの引き継ぎブロック」としてまとめる。ユーザーはこの出力を /copy でコピーし、/clear した次のセッション冒頭に貼り付けて作業を再開する。

これは作業報告書ではない。 読み手は前提知識ゼロの次セッションのClaudeであり、人間のレビュアーではない。「何をやったか」の要約ではなく、「迷わず作業を再開するために必要なブートデータ」を書く。次のClaudeが調べ直さずに済むこと・即座に手を動かせることを最優先する。

現在の状態

• 現在のブランチ: !git rev-parse --abbrev-ref HEAD

• 未コミットの変更: !git status --short

手順

1. セッション内容の把握

会話履歴と作業実態から、次のセッションが必要とする情報を抽出する。「報告」ではなく「再開に必要か」を基準に取捨選択する。

2. git履歴の確認

セッション中のコミットがあれば確認し、現在地の裏付けとする:

git log --oneline --since="today" --all

3. 引き継ぎブロックの出力

以下の3本柱で、1つのコードフェンスで囲んだブロックとして出力する。ユーザーが /copy でそのままコピーできるよう、ブロックの外には余計な説明を置きすぎない。該当内容がないセクションは省略する。

```
# セッション引き継ぎ

## ゴール
- このセッションで達成しようとしていること（次セッションが目指す到達点）
- 完了の定義が明確なら併記

## コードベースの理解
- このタスクに関係するアーキテクチャ・データフロー・前提・制約
- 調べて分かった「効いてくる事実」（次セッションが再調査しなくて済むように）
- 例: 「認証は X 層で行われ、`foo()` を経由する」「この処理は Y の制約で同期実行が必須」

## コードの現在地
- このセッションでマージしたPR・コミットで何が入ったか（リンク・概要）。このスキルは多くの場合、自分が出したPRをマージしてcleanなブランチに戻った区切りで使う
- 次の作業で触ることになる中心のファイルパス + 行番号（例: `src/auth/login.ts:42`）、関数名
- 意図的な設計判断があれば「なぜそうしたか」を一文添える（次セッションが善意で巻き戻さないように）
- 現在のブランチ・未コミットの変更があればその内容（区切りで使う場合は無いことが多い）
- 再現/再実行に使うコマンド（テスト・ビルド・起動など）

## 試したが却下した道
- このセッションで試してダメだった／意図的に見送ったアプローチと、その理由
- 例: 「`X` 方式のキャッシュは Y の制約で却下、`Z` に切り替えた」
- 次セッションが同じ袋小路に入り直さない・却下済みの道を巻き戻さないための情報。無ければ省略

## 次の一手
- 再開後に最初にやる具体的アクション（曖昧な残タスクではなく、実行可能な指示）
- 例: 「`src/auth/login.ts:55` の TODO を埋める。`bar()` の戻り値を null チェックする」
- その後に続く作業があれば順に列挙

## 判断待ち・要確認
- 進める前にユーザーに確認すべき分岐・未決定事項（決め打ちで走らせない）
- 例: 「エラー時はリトライか即failか仕様未確定。ユーザーに確認してから実装」
- 該当が無ければ省略
```

4. 出力形式の注意

• 読み手はLLM。人間向けの体裁より、具体性と即実行性を優先する。ファイルパス・行番号・関数名・コマンドは省略せず正確に書く
• 箇条書き・見出しを基本に、フラットな構造を保つ
• 推測で埋めない。未確認・不明な点は「未確認」と明記する（次セッションが誤った前提で走らないように）
• 出力後、ユーザーに「/copy でコピーして次セッションに貼ってね」と一言添える