write-handoff

引き継ぎ

この会話を、新しいエージェントが作業を再開できる文書にまとめます。文書はOS の一時ディレクトリ（$TMPDIR。設定されていない場合は /tmp、Windows では %TEMP%）に書き込み、ワークスペースには絶対に書き込まないでください。引き継ぎ文書はセッション限りの一時データであり、プロジェクトの成果物ではありません。ファイル名は handoff-<topic>-<timestamp>.md とし、絶対パスをユーザーに伝えてください。

ユーザーがこのスキルに引数を渡した場合は、それを次のセッションで取り組む内容として扱い、文書全体をその焦点に合わせてください。その焦点に関係のない内容は省いてください。

内容

• 目標 — ユーザーの言葉で、作業の最終目的を記載します。
• 現在の状態 — 完了した作業、進行中の作業、正確なブランチ／ワークツリー、作業ツリーに変更があるかどうかを記載します。
• 試して却下したこと — 試した、または検討したうえで採用しなかった方法を、却下した理由とともにすべて記載します。後任が行き止まりを再検討しなくて済むようにするための項目です。通常、これが最も重要です。
• 既知の事項／未知の事項（該当する場合） — 最新の既知事項インベントリへのパスと、それが確定する事項、未解決の事項、残る盲点を一文で要約します。該当ファイルがある場合は、.skills/*-knowns.md または .skills/*-scan.md の盲点セクションを示してください。
• 逸脱（該当する場合） — .skills/<CODE>/implementation-notes.md へのパスを記載します。記録された各逸脱を一文で要約し、Map impact が none 以外の項目数も記載してください（または、該当する項目がゼロであることを明記してください）。後任がチャットの記憶から逸脱を再発見する必要がないようにしてください。
• 次のアクション — 次に実行するコマンドまたは編集から始め、具体的な作業を順番に記載します。
• 推奨スキル — 後任がこのスキル群のどのスキルを、どの手順で使うべきかを記載します（例：「タスク 4 から build-in-waves を再開する」「タスク 3 の完了を宣言する前に prove-claim を実行する」）。複数タスクにわたるブランチが、作成者によるマージ前のセルフチェックが可能な状態になった場合は、ユーザーに /understand <range> を案内してください（自分では実行しないでください）。
• チームの状況（該当する場合） — docs/agents/project.md に ## Team があり、空でないロスターまたはバンドのオーバーライドが記載されている場合は、バンドとパッケージングの適用方法を一行で記載します。Small／Multi の場合、この作業の担当者がロスターまたは担当範囲のメモに記載されていれば、次のアクションの担当者を記載します。担当者が記載されていない場合は、担当者の行を省略します。Team がない場合は、セクション全体を省略してください（チーム情報を作り出さないでください）。

ルール

• 複製せず、参照する。 仕様書、計画書、ADR、Issue、コミット、差分は、パス、URL、ハッシュで示してください。内容をコピーすると引き継ぎ文書が肥大化し、正本が分岐してしまいます。ディスク上の成果物を正本としてください。
• 秘密情報を伏せる。 API キー、トークン、パスワード、個人情報は、実際の値がどこにあるかを示すプレースホルダーに置き換えてください。この文書が別のエージェントへのプロンプトとして使われる可能性があります。
• ユーザーがすでに決定した事項は、理由とともに確定事項として記録する。 後任がそれを再検討したり、ユーザーに再度尋ねたりしないようにしてください。

任意：後任エージェントの起動

ユーザーから依頼があった場合に限り、引き継ぎ文書をプロンプトとして与えたバックグラウンドエージェントを、現在の作業ディレクトリで起動してください。約束する前に、利用中のハーネスが提供する仕組みを確認してください。その仕組みがない場合は、すでに伝えたパスが引き継ぎのすべてです。

完了条件

完成した文書を批判的な視点で読み返してください。この文書と、参照先の成果物だけを渡された新しいエージェントが、会話ですでに答えが出ていることをユーザーに尋ねずに作業を再開できるでしょうか。その確認で疑問が一つでも残る場合は、その答えを文書に追加してから完了してください。