session-handoff

セッション引き継ぎ

新しいセッション用に、簡潔で事実に基づいた引き継ぎ資料を1つ作成します。起きたことをすべて記録するのではなく、作業を正しく再開できることを優先してください。

証拠を最優先する

1. ユーザーが再開しようとしているプロジェクトを特定します。リポジトリの場合は、現在のブランチ、HEAD、git status --short --branch、関連する変更パスを確認します。作業ツリーがクリーンであることや、エージェントの説明だけから完了したと推測しないでください。
2. 正式なタスク資料と現在の会話コンテキストを読みます。次の内容を区別してください。
   • コマンドやファイルで確認できた状態
   • ユーザーが明示した決定と制約
   • 報告はされているものの、独立して検証されていない作業
   • 未解決の疑問、失敗、同じ根本原因に関係する残作業
3. 正確なコマンドと結果が確認できる場合に限り、テストの証拠を記録します。特定範囲のテストが成功しても、全テストの成功を意味するわけではありません。予定、開始済み、または完了したとの主張だけでは、作業は完了していません。
4. リポジトリのファイルや履歴から容易に確認できない場合に限り、会話だけで得られた事実を含めます。完了した寄り道、経緯の説明、次の作業に影響しない背景情報は省きます。

Git の変更状態はコード作業段階の証拠になり得ますが、クリーンな作業ツリーは設計作業段階の証拠にはなりません。タスクのコンテキストと現在の成果物の両方から、設計、コード、または混合の状態を判断してください。

実行可能な状態の判定

進行中の目標、決定、ブロッカー、保留中の作業、または失われると再取得できないコンテキストがない場合は、.handoff/ や引き継ぎファイルを作成しないでください。引き継ぐべき実行可能な状態はないと伝え、コンテキストが失われた場合は元のセッションでスキルを実行するようユーザーに依頼してください。

引き継ぎ資料を作成する

実行可能な状態がある場合は、対象プロジェクト内の .handoff/YYYY-MM-DD-HHMM-session.md にファイルを1つだけ作成します。次のセクションのうち、再開に実質的な価値があるものだけを使用してください。

# Resume

## Current state
- Goal: ...
- Working directory: ...
- Branch / HEAD: ...
- Worktree: ...

## Verified completed
- ...

## In progress and residuals
- ...

## Next action
- ...

## Decisions and constraints
- Selected: ... / Rejected: ... / Because: ...

## Verification
- `<exact command>` — PASS | FAIL | NOT RUN; scope: ...

## Relevant files
- `path` — why it matters

ルール：

• 空のセクションは省略します。None や N/A は書きません。
• 設計のみの引き継ぎでは、リポジトリの状態を確認しますが、作業ディレクトリ、ブランチ、HEAD、ワークツリー、変更ファイルの一覧、関連ファイルの一覧、リポジトリが存在することや実装が始まっていないことだけを示す情報は省きます。次の設計上の決定を直接制約する場合に限り、コード成果物や Git の情報を含めてください。
• 進め方が決まっている場合は、次の具体的な作業を1つだけ記載します。実際に未解決の決定によって複数の有効な進め方が生じる場合に限り、選択肢を列挙します。一般的な選択肢の一覧を追加したり、ユーザーに再度選択を求めたりしないでください。
• 明示された判断理由を保持します。理由が分からない場合は、rationale not captured — verify before relying on it と記載し、決して推測で補わないでください。
• 未検証の主張と不完全な証拠には、その旨を明記します。
• ファイル一覧には再開に影響するパスだけを含めます。差分全体を貼り付けないでください。
• 資料を作成する際に、コミット、プッシュ、製品コードの変更、タスク状態の変更を行わないでください。

作成後、引き継ぎファイルの絶対パスと、記録した次の作業を述べる一文を報告します。