write-handoff

引き継ぎを作成する

次の作業者が、所有する Plan やドキュメントを作り直さずに、範囲の明確な 1 つの作業を完了できるだけの、安定したコンテキストを伝えます。

workflow-language.md を使用します。レビュー作業では review-language.md を使用し、handoff-template.md に従います。

意図とライフサイクルを選ぶ

一般的なタイプは、実装／継続、調査、リファクタリング／バグ修正、レビュー、レビューの継続、レビュー対応です。次の作業を表す最小限のタイプを選びます。

想定される用途に応じてライフサイクルを選びます。

• Immediate：次の作業者が決まっている場合、または近日中に継続する場合です。現在のパスや変動しやすい状況が役立つことがあります。
• Durable：後日または未定の作業者が担当する場合、あるいは複数のツールで再利用する作業の場合です。安定した動作、受け入れ基準、範囲の境界を重視します。

想定されるライフサイクルで Durable が明らかに必要な場合を除き、Immediate を既定とします。チャットでもファイルでも引き継ぎを行えます。ファイルに保存するからといって、耐久性が必要になるわけではありません。

引き継ぎを作成する

1. この作業に必要な場合に限り、所有する Plan、ドキュメント、Review Ledger、現在の差分、またはソースを読みます。
2. 正確な作業内容、現在の状態、範囲、制約、完了条件、検証方法を記載します。
3. 次の作業者が実際に必要とする、信頼できるファイルだけにリンクします。Plan やドキュメント全体をコピーしたり、代わりの Plan を作成したりしないでください。
4. 再調査を大幅に減らせる、まだ把握できない実装上の注意点に限り記載します。
5. 隣接するアイデアは対象範囲に含めず、または所有する Plan のフォローアップに記載します。

ユーザーがファイルを求めている場合、または承認されたワークフローで保存された成果物が明確に必要な場合に限り、ファイルを作成します。リポジトリに既定の引き継ぎ先がある場合はそこを使用し、ない場合は確認するか、コピー可能なテキストを返します。

レビューの引き継ぎ

• 継続／差分のレビューラウンドでは、承認済みの指摘、パッチのメモ、変更箇所、解決済みの項目、Review Signal、未解決のリスク、次に予定する範囲を引き継ぎます。
• 明示的に独立した相互検証を行う場合は、重複があり得ることを伝え、レビュー担当者を望ましい指摘へ誘導しないようにします。
• fresh review が継続か独立した相互検証かによって意味が大きく変わり得る場合は、他の所有者への質問とあわせて選択を確認し、黙って決めないでください。
• 以前の Review Signal が Low だった場合、明示的に依頼されたレビューラウンドを拒否せず、期待できる効果が低い可能性を記載します。

所有する成果物の更新

引き継ぎがあるという理由だけで、管理用の情報を追加しないでください。検証済みの Task の状態、必要な作業、またはフォローアップに変更があった場合に限り、Plan を更新します。成果物が見失われるのを防げる場合に限り、引き継ぎファイルへの簡潔な参照を追加します。

handoff-template.md を使用し、使用しないセクションは省略して、簡潔かつ単独で理解できる内容にします。