| name | session-handoff |
| description | 作業セッションの終わりに、次の作業セッションが前提知識ゼロで再開できる「引き継ぎ doc（markdown 1本）＋ そのまま貼れるキックオフメッセージ」を生成する。狙いは、 会話の自動要約（compaction）では失われがちな情報——下した判断とその理由、採用／ 却下した規約・選択肢、実際に使った検証コマンドやツールチェーンのハマり所、コードや git から再導出できないプロジェクト固有の方針、残作業と保留理由——を正確に残すこと。 次のような場面では、明示的に "doc" や "引き継ぎ" という語が無くても積極的に発火する: 「引き継ぎ／handoff を作って」「別のセッション・別チャットに渡したい／そっちで続きを やる」「次のセッション用にまとめて」「(会話の)context・コンテキストがいっぱい／そろそろ 限界」「このまま /clear・compact する前に今の状態を残したい」「compact すべきか doc に 残すべきか迷う」「今日はここまで／作業を中断する／一区切りつけるので、明日や後で再開 する自分が迷わず続けられるよう状態を残して」。 一方、次は対象外なので発火しない: 関数の切り出し・リネーム・1ファイル内のリファクタ などコード整理そのもの；PR 説明文・コミットメッセージ・README・設計ドキュメント (design doc) など一般の文書作成；Slack などへの作業報告・分報のまとめ；退職や担当交代 に伴う人・チームへの業務引き継ぎ資料；「もっとファイルを読んで文脈(context)を把握して 直して」のような、会話の context 枯渇ではなくコード理解を指す依頼。 |
Session Handoff
なぜこのスキルがあるのか
セッションを閉じる方法は2つある。compaction は今のセッションを続けるために履歴を自動要約するもので、要約は機械任せ・取捨選択できず、判断の「なぜ」や捨てた選択肢から先に落ちる。引き継ぎ doc はセッションの境界をまたぐためのもので、何を残すかをこちらが選べる。
だから doc の価値は「正確さ」ではなく「再導出できないものだけを選んで残す」ことにある。コードや git log を読めば分かることを書き写しても、次セッションはどうせ読み直すので価値はゼロで、むしろ本当に大事な情報を埋もれさせる。残すべきは、要約や再読では戻ってこないもの——下した判断とその理由、採用／却下した規約や選択肢、実際に通った検証コマンドとハマり所、コードに書いていないプロジェクト方針、残作業と「なぜ今やらないか」。この原則が全工程を貫く。
最初の確認: compaction か doc か（軽く、毎回はやらない）
状況を見て、次のどちらかに振り分ける。長い講釈はしない。
- 危ういコミット前の in-flight 状態がある（やりかけの編集が未コミットで散らばっている／中断状態が複雑でコードだけ見ても再構成しづらい）、またはユーザー自身が「compact すべきか doc か迷う」と言っている場合のみ、一言トレードオフを述べて勧めを出す。要点は「未コミットの作業中編集は doc では正確に再現できない。境界をまたぐ（/clear・別セッション）なら先に commit か stash、あるいはこのまま続けるなら compaction が安全。どうしても今 doc に渡すなら、未コミット分は §0 で明示的に保全する」。勧めを述べたら、止まらずそのまま doc 生成に進む（迷っているユーザーには判断材料を渡しつつ手は動かす）。
- 状態がコミット済みで意図も明確なら、ゲートには触れず黙って生成に進む。
生成の手順
1. 現在地を git で裏取りする
§0 のハッシュや status を捏造しない。同梱スクリプトで実際の git 出力をまとめて取る:
bash <skill-dir>/scripts/collect_git_state.sh 10
得られるのは branch / 直近ログ / 作業ツリー（status --short）/ 未コミット差分の stat。これは生データ。doc にそのまま貼るのではなく、§0 で「未コミットの各変更が何で、なぜまだコミットされていないか」へと解釈する（git に出ない「なぜ」がこちらの仕事）。リポジトリ外なら git パートは省く。
2. doc の置き場所を決める
置き場所をグローバルに決め打ちしない。リポジトリによって流儀が違う（特定トピックの doc だけ専用ディレクトリに集約されている、等）。今回の作業に関連する既存 doc がどこにあるかを見て寄せる:
find . -type f -name '*.md' \( -iname '*handoff*' -o -iname '*summary*' -o -iname '*引き継ぎ*' \) -not -path '*/node_modules/*' 2>/dev/null
find . -type d \( -name docs -o -name summary -o -name handoff \) -not -path '*/node_modules/*' 2>/dev/null
- 関連トピックの doc が集まっているディレクトリがあれば、そこに合わせる（ファイル名の付け方・形式も既存に倣う）。
- 候補が複数あって決め手がない、または既存 doc が見当たらず迷うときは、ユーザーに置き場所を訊く。勝手に新ディレクトリを作って散らかさない。
- ファイル名は内容が分かる形＋絶対日付（例
<topic>_handoff_2026-06-22.md）。「今日」「先週」等の相対表現は doc 本文でも使わず絶対日付に直す。
3. doc を書く（§0–§5）
下の「doc テンプレート」に沿って書く。各節で「書くこと／書かないこと」の原則を効かせる。短くてよい——薄い節は1〜2行、無ければ「特になし」で省略せず明示。
4. キックオフメッセージをチャットに出す
doc とは別に、次セッションの冒頭にそのまま貼れる自己完結プロンプトをチャット本文に出す（doc の §5 にも同じものを載せる）。「さっきの続き」的な、文脈を前提にした書き方は禁止——貼った人＝前提知識ゼロの前提で書く。詳細は下の「キックオフメッセージ」。
doc テンプレート
# <トピック> 引き継ぎ (YYYY-MM-DD)
> このドキュメントの役割: <何の作業を、なぜ次セッションに引き継ぐのか1〜2行>。
> 関連する正本 doc があれば先に挙げる: `path/to/related.md`（何が書いてあるか）
## 0. 現在地
- ブランチ: `<branch>`（git 裏取り済み）
- 直近の到達点: <log から向き付けに必要な数行。コミット列の貼り付けではなく「どこまで進んだか」>
- 作業ツリー: <未コミットの各変更が何で、なぜまだコミットしていないか。クリーンならそう書く>
## 1. 確立した決定・規約（蒸し返さない）
<下した判断／採用した規約・命名・パターンを、根拠とセットで。表が読みやすい>
| 決定 | 内容 | 根拠（なぜ・却下した案） |
|---|---|---|
## 2. 検証・作業フロー（実際に動かしたもの）
<コピペで動く実コマンド＋パス。通っただけでなくハマり所も。例: コンテナのマウント範囲、
必要な事前手順、落とし穴。コマンドが無いなら省略してよい>
## 3. 作業方針（やること・やらないこと）
<コードに書いていない進め方の方針。「あえてやらない」と決めたこと、その理由も>
## 4. 残作業・保留候補
- [ ] <次にやること。なぜ未了か・ブロッカーがあれば添える>
- 保留: <今あえてやらないこと＋その理由（後で蒸し返さないため）>
## 5. 次セッション開始メッセージ
<セクション「キックオフメッセージ」の自己完結プロンプトをそのまま転記>
節の番号・見出しは目安。既存 doc に強い様式があればそちらに寄せてよい。空に近い節を埋めるために水増ししない。
書くこと／書かないこと（核の原則）
書かない（コード・git から再導出できる＝次セッションが読み直せる）
- ディレクトリ構造、関数シグネチャ、実装の逐語的説明
git log / git diff の生貼り付け- 「あとは普通にやるだけ」の一般論
書く（要約・再読では戻ってこない）
- 下した判断と理由、検討して却下した代替案（なぜ却下したか）
- 採用した規約・命名・パターンと、その出どころ／前例
- 実際に通った検証コマンド（コピペできる形）とハマり所
- コードに現れないプロジェクト固有の方針・制約
- 残作業と「なぜ今やらない／保留か」
判定の物差し: 「これは次セッションがコードか git を見れば5分で分かるか？」分かるなら書かない。ファイル一覧でも、各行に『なぜ要るか・何の役割か』の注釈が付くなら価値がある（注釈のない羅列は不要）。
キックオフメッセージ
次セッションの最初の一手として単体で成立するプロンプト。満たすべき条件:
- 冒頭でリポジトリ・作業対象・doc のパスを名指しする（文脈ゼロの前提）
- doc のどの節を見ればよいか案内する
- §4 から導いた「最初にやる具体的な一手」を書く
- 作業ブランチ名を含める
例（良い—単体で貼れば再開できる）:
green-api で「ターゲットリスト抽出」バッチの Go 本実装を引き継ぎます。まず curation_research/docs/summary/<topic>_handoff_2026-06-22.md を読んでください——前セッションの引き継ぎ doc で、§0=現在地、§1=確定済みの決定（蒸し返さない）、§4=残作業です。作業ブランチは GR-20488-...。読んだら §4 の先頭タスク「週次更新版の反映ロジック追加」に着手してください。設計の正本は同 doc が指す judgment_axis_aggregation_spec.md です。
避ける（悪い—文脈依存で単体では動かない）:
さっきの続きをやってください。残りのタスクをお願いします。
