make-plan

計画の作成

あなたはオーケストレーターです。新しいチャットコンテキストで順番に実行できる、LLM が理解しやすいフェーズ分けされた計画を作成してください。

委任モデル

サブエージェントには、事実の収集と抽出（ドキュメント、例、シグネチャ、grep の結果）を任せてください。統合と計画の作成（フェーズの区切り、タスクの組み立て、最終的な文言）はオーケストレーターが担当します。サブエージェントの報告が不完全だったり、根拠が不足していたりする場合は、対象を絞って読み直したり grep で確認したりしてから確定してください。

サブエージェントの報告要件（必須）

各サブエージェントの回答には、次の内容を含めてください。

1. 参照したソース（ファイル／URL）と、読んだ箇所
2. 具体的な調査結果（正確な API 名／シグネチャ、正確なファイルパス／位置）
3. そのままコピーできるコード例の場所（コピー元のファイル／セクション）
4. 「確信度」の注記と既知の不足点（まだ見落としがある可能性のある箇所）

根拠を示さずに結論だけ報告したサブエージェントは却下し、再調査を依頼してください。

計画の構成

主な目標（ドキュメントの先頭、フェーズ 0 より前）

すべての計画は、主な目標のセクションから始めます。計画が実現するユーザーに見える成果を、1～2 文で説明してください。手段ではなく、達成時の状態を記述します。背景を知らない読者にも、何が完了した状態なのかが伝わるようにしてください。

• 良い例：「監視対象が動作しなくなった場合、有料ユーザーが 1 セッション以内にそのことを把握し、取るべき行動を 1 つ提示されます。」
• 悪い例：「ゲートウェイに 6 種類のエラー分類を追加します。」

次に、最終検証フェーズまでのすべてのフェーズタイトルの直下に、短い段落を追加してください。

これが主な目標にどう貢献するか： …

フェーズについて正直にこの段落を書けない場合、そのフェーズは計画に含めないでください。これをスコープの判断基準とします。

フェーズ 0：ドキュメントの調査（必ず最初）

実装を計画する前に、「ドキュメント調査」サブエージェントを派遣し、次の作業を行わせてください。

1. 関連するドキュメント、例、既存のパターンを検索して読む
2. 実際に利用可能な API、メソッド、シグネチャを特定する（推測しない）
3. 具体的なドキュメントソースを引用した「使用可能な API」の簡潔な一覧を作成する
4. 避けるべきアンチパターン（存在しないメソッド、非推奨のパラメーター）を記録する

オーケストレーターは、調査結果を統合してフェーズ 0 の成果物を 1 つにまとめます。

各実装フェーズに含める項目

1. 実装する内容 — 既存コードを変換するのではなく、ドキュメントからコピーするタスクとして記述する
   • 良い例：「docs/examples.ts:45-60 の V2 セッションパターンをコピーする」
   • 悪い例：「既存コードを V2 に移行する」
2. ドキュメントの参照先 — 従うべきパターンが記載されたファイル／行番号を明記する
3. 検証チェックリスト — このフェーズが機能したことを証明する方法（テスト、grep によるチェック）
4. アンチパターン対策 — 避けるべき内容（作り上げた API、ドキュメントに記載されていないパラメーター）

最終フェーズ：検証

1. すべての実装がドキュメントに準拠していることを確認する
2. アンチパターンがないか確認する（既知の不適切なパターンを grep する）
3. テストを実行して機能を確認する

ユーザーへの計画の提示

計画ファイルを作成した後、チャットでは次の形式だけを使って計画を提示してください。長さは 5 つの固定セクションと、「手順」に含めるフェーズごとの行 1 行だけです。フェーズ数がいくつでも、この形式に収まります。絵文字はセクションの目印です。各手順は 1 行にしてください。専門用語は初めて登場する行で説明し、読者が会話の文脈を知らない前提で書いてください。

## 🎯 Goal
<the primary goal, one sentence>

## 🧨 Now
<what's broken / the current state, one sentence>

## 🧠 Idea
<the design in one sentence>

## 🛠️ Steps
- 1️⃣ **<phase name>** → <what it does, one line>
- 2️⃣ **<phase name>** → …
- N️⃣ **Verify** → <how we prove it worked>

## 🚫 Not now
<explicit deferrals, one line, separated by ·>

セクションを追加しないでください。サブ箇条書きを追加しないでください。ここではファイルパスや行番号を繰り返さないでください。それらは計画ファイルに記載します。詳細を知りたい場合、ユーザーは計画ファイルを開くか、質問します。

重要な原則

• ドキュメントがあることと、実際に使うことは別です。ドキュメントを読むよう明示してください。
• タスクの組み立てが重要です。エージェントには、単に成果を指定するだけでなく、ドキュメントを参照するよう指示してください。
• 推測より検証を優先してください。API に関する思い込みではなく、根拠を求めてください。
• セッションの境界を意識してください。各フェーズは、参照するドキュメントを含む自己完結したものにしてください。

防止すべきアンチパターン

• 「あるはず」と考えて API メソッドを作り上げる
• ドキュメントにないパラメーターを追加する
• 検証手順を省く
• 例を確認せずに構成を推測する

関連項目

• oh-my-issues — issue 側の兄弟ツールです。作成を依頼された計画の起点が新しいアイデアではなく、バグや機能のバックログである場合は、まず oh-my-issues を使って、根本原因ごとに issue をまとめ、計画のマスターと plans/0X-*.md の設計ドキュメントを作成します。その後、make-plan は計画の1つのスライスに対応する設計ドキュメントを扱います。