agent-handoff-plan

name	agent-handoff-plan
description	設計済みの作業を別エージェントへ渡すため、実装計画書や handoff プロンプトの作成を求められたときに使う。未確定要件の壁打ちや自分で実装する依頼では使わない。

Agent Handoff Plan

生成したハンドオフプロンプトを別のtmux paneのエージェントへ送信する場合、輸送手順は tmux-agent-bridge スキルに従う。

Overview

設計と方針が固まった作業を、別の実装エージェントが単独で完遂できる形に落とし込むワークフロー。 成果物は依頼種別で分岐する。

• プロンプトだけを求められた場合は、その場にハンドオフプロンプトだけを出力し、計画書ファイルは作成しない。
• 計画書、仕様書、設計書などの文書作成を明示された場合だけ、Markdown ファイルを作成する。
• 文書ファイルを作成した場合は、必要に応じてその文書を読む前提のハンドオフプロンプトも出力する。

このスキルの品質基準は「実装エージェントが渡された成果物だけを読んで、途中でユーザーに質問せずに完了できるか」。 判断の余地が残っている箇所は、成果物を書く前にユーザーに確認して確定させる。

実装完了後の検証と差し戻しは agent-review-request スキルの領域なので、 ハンドオフ用の成果物を渡した時点でこのスキルの仕事は終わり。

Workflow

1. 出力モード判定

依頼文から出力モードを決める。

プロンプト単体モード:

• 「プロンプトを書いて」
• 「別エージェントに渡す文面を作って」
• 「handoff プロンプトだけ」
• 文書ファイル作成を明示せず、実装エージェントへ渡す入力文だけを求めている依頼

このモードではファイルを作成しない。 計画書の作成と計画書パスを前提にしたプロンプト生成は行わない。

文書作成モード:

• 「計画書を書いて」
• 「仕様書を書いて」
• 「設計書を書いて」
• 「docs に残して」
• 「ファイルを作って」
• 「計画書とプロンプトの両方」

このモードでは Markdown ファイルを作成する。 DoD のない計画書、仕様書、設計書は未完成として扱う。

モードが判断できない場合は、ファイル作成を伴わないプロンプト単体モードとして扱う。 ただし、ユーザーの依頼から文書化の必要性が読み取れる場合は、作成前に確認する。

2. 前提確認

• 設計と採用案が確定しているかを確認する。UI 案の選択が済んでいない、方式の比較検討が 終わっていない、といった状態なら、先にそちらを完了させる（必要なら ui-mock-proposals や 通常の設計議論に戻る）。
• 現状のコードを実際に読み、成果物に書く内容が現実と一致していることを確認する。 推測で書いた成果物は実装エージェント側で矛盾として顕在化し、差し戻しコストが倍になる。
• 曖昧な点や設計判断が必要な点が残っていたら、成果物を書き始める前にユーザーに確認する。 「実装エージェントに判断させる」選択肢は原則取らない（判断が割れると検証で手戻りになるため）。

3. 文書ファイルの作成

文書作成モードの場合だけ実行する。 プロンプト単体モードではこのステップをスキップする。

置き場所と命名: プロジェクトに文書ファイルの置き場所の規約があればそれに従う （例: docs/plans/、docs/superpowers/plans/）。なければそのリポジトリの docs 以下に置く。 同日に複数作る場合は -plan-02 のように連番を付ける。

構成: 計画書、仕様書、設計書には次のセクションを必ず含める。

# <タイトル>

## 背景と目的
（なぜこの変更をするか。現状の問題点）

## 確定済みの設計判断
（採用案とその理由。検討して不採用にした案があれば理由付きで明記。
 実装エージェントが「こっちの方が良いのでは」と迷わないようにする）

## 実装フェーズ
（Phase 1, 2, ... に分解。各フェーズに:
 - 対象ファイルと変更内容（ファイルパスは実在確認済みのものを書く）
 - そのフェーズの完了条件）

## 参照物
（HTML モック、スクリーンショット、関連ドキュメントのローカルパス。
 モックが仕様源になる場合は「このモックが唯一の仕様源」と明記し、
 モック内のどの要素がどのコードやトークンに対応するかを書く）

## DoD（Definition of Done）
- [ ] 機能完了条件（測定可能な形で列挙）
- [ ] テスト完了条件（実行するコマンドと期待結果）
- [ ] 運用反映条件（lint / typecheck / build の通過、必要ならドキュメント更新）

## やらないこと
（スコープ外を明示。実装エージェントの善意の拡大解釈を防ぐ）

• DoD のない計画書、仕様書、設計書は未完成として扱う。3 分類（機能・テスト・運用反映）を必ずチェックリストで書く。
• HTML モックなどの参照物は必ずローカルに保存してからパスを文書ファイルに書く。 会話内にしか存在しない成果物は実装エージェントから見えない。

4. 文書ファイルのセルフレビュー

文書作成モードの場合だけ実行する。 プロンプト単体モードではこのステップをスキップする。

書き終えたら渡す前に一度見直す。前半で挙げた基準（質問なしで完了できるか・現実のコードと一致しているか）に加えて、次を確認する。

• フェーズ間の依存関係が明示されているか（並行可能なら並行可能と書く）

5. ハンドオフプロンプトの生成

実装エージェントの入力欄にそのまま貼れるプロンプトをコードブロックで出力する。

プロンプト単体モードでは、文書ファイルを参照させず、必要な情報をプロンプト本文に直接含める。 テンプレート:

対象リポジトリ: <絶対パス>

以下の内容に従って実装してください。
AGENTS.md / CLAUDE.md のルールに従ってください。

## 背景と目的
<なぜこの変更をするか。現状の問題点>

## 確定済みの設計判断
<採用案、理由、変更してはいけない判断>

## 対象範囲
<変更対象のファイル、モジュール、画面、機能>

## 実装手順
<実装フェーズまたは具体的な作業順>

## 完了条件
<機能として満たすべき測定可能な条件>

## 検証
<実行するコマンドと期待結果>

## 停止条件
<矛盾、不明点、想定外の差分など、自己判断せず停止する条件>

## やらないこと
<スコープ外>

文書作成モードでは、作成した文書を読む前提のプロンプトにする。 テンプレート:

対象リポジトリ: <絶対パス>

<文書ファイルの絶対パス> を読んで、この文書に従って実装してください。
AGENTS.md / CLAUDE.md のルールに従ってください。

- 文書ファイルの「確定済みの設計判断」は変更しない。実装中に矛盾や不明点を見つけた場合は、
  自分で判断せず、その箇所を報告して停止する
- 「やらないこと」に書かれた範囲には手を出さない
- 完了したら DoD チェックリストの各項目について、実行したコマンドと結果を添えて報告する

• 実装エージェント側に effort / reasoning レベルの指定がある場合（ユーザーが high / xhigh などを指定したとき）はプロンプト冒頭に添える。指定がなければ勝手に付けない。
• 対象が worktree の場合はそのパスを使う（メインの checkout と取り違えない）。

6. 引き継ぎ後

• プロンプト単体モードでは、ハンドオフプロンプトだけを提示して完了する。
• 文書作成モードでは、文書ファイルのパスとハンドオフプロンプトを提示して完了する。
• 実装の進捗監視はしない。
• ユーザーが「実装が終わったから確認して」と戻ってきたら agent-review-request スキルで 受け入れ検証を行う（文書ファイルがある場合は、そのパスを検証の入力として渡す）。