handoff

引き継ぎ

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

ユーザーがこのスキルに引数を渡した場合は、それを次のセッションの作業対象として扱い、無関係な内容を省いてドキュメント全体をその対象に沿ってまとめてください。

内容

• 目標 — 作業の最終的な目的を、ユーザーの言葉で記載します。
• 現在の状況 — 完了した作業、進行中の作業、正確なブランチ／ワークツリー、作業ツリーに変更があるかどうかを記載します。
• 試したが採用しなかった方法 — 試した、または検討したものの採用しなかった方法を、その理由とともにすべて記載します。後任が行き止まりを再検討するのを防ぐためのもので、通常、最も価値のあるセクションです。
• 既知事項／未確認事項（該当する場合） — 最新の既知事項一覧へのパスと、確定している点、未確定の点、未解決の盲点をそれぞれ一文でまとめます。該当ファイルが存在する場合は、.skills/*-knowns.md または .skills/*-scan.md の Blindspot を参照してください。
• 差異（該当する場合） — .skills/implementation-notes.md へのパスと、記録されている各差異の概要を一文ずつ記載します。後任がチャットの記憶から再発見する必要がないようにしてください。
• 次のアクション — 次に実行するコマンドまたは編集から始めて、具体的な手順を順番に記載します。
• 推奨スキル — このセットから後任が使うべきスキルと、使う手順を記載します（例：「タスク4から execute-plan を再開する」「タスク3の完了を報告する前に verify を実行する」）。複数タスクからなるブランチで、マージ前に作成者自身による確認が必要な場合は、ユーザーに /comprehend-change を案内してください。大規模な変更やアーキテクチャに影響する変更で、レビュアー向けのチーム共有用の説明と全体図を docs/explainers/ に用意すると役立つ場合は、ユーザーに /explain-change を案内してください（いずれもユーザーが呼び出すものであり、自動実行しないでください）。
• チームの状況（該当する場合） — docs/agents/project.md に、空でない roster またはバンドの上書きを含む ## Team がある場合は、バンドとパッケージ化の適用方法を一行で記載します。Small／Multi の場合、roster または所有権に関する記述でこの作業の担当者が示されていれば、次のアクションの担当者を記載します。担当者が示されていない場合は、その行を省略してください。Team の記載がなければ、このセクション全体を省略してください（チームを推測して作らないでください）。

ルール

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

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

ユーザーから依頼があった場合に限り、引き継ぎドキュメントをプロンプトとして渡し、説明的な表示名を付けて、現在の作業ディレクトリでバックグラウンドエージェントを起動してください。起動を約束する前に、利用するハーネスがその機能を提供していることを確認してください。利用できない場合は、すでに案内したパスを引き継ぎ方法としてください。

完了条件

完成したドキュメントを批判的に読み直してください。このファイルと参照先の成果物だけを渡された新しいエージェントが、会話ですでに回答済みのことをユーザーに尋ねずに作業を再開できるでしょうか。疑問が一つでも残る場合は、その答えをドキュメントに追記してから完了してください。