こんにちは、takuです。
この記事は、GitHub Copilot の Plan モードをすでに使っている人向けです。
Plan の「使い方」ではなく、Plan.agent.md（プロンプト定義）に書かれている文言から、出力や振る舞いの傾向を読み解きます。
読み終わったあとに得られるものは、次の2つです。
- Plan が期待と違う動きをしたときに、根拠となる箇所を特定できる
- 運用やカスタムで「どこを変えると何が変わるか」を整理できる
前提：プロンプトが「Planの役割」を固定している
Plan.agent.md には、役割と禁止事項が明示されています。
例えば以下のような文言があり、Plan は最初から「計画専任」であることが前提です。
- "Your job: research the codebase → clarify with the user → produce a comprehensive plan."
- "Your SOLE responsibility is planning. NEVER start implementation."
この種類の文言が入っていると、Plan が実装に踏み込まない方向に寄ります。
原文（全文は各自の環境で参照）
ここでは全文は載せず、手元のファイルを参照できる前提にします。
- 例：~/Library/Application Support/Code/User/globalStorage/github.copilot-chat/plan-agent/Plan.agent.md
以降は、Plan.agent.md の文言から読み取れる「Planモードの挙動」を整理します。
1. 先頭のメタ情報（frontmatter）：許可・導線・期待入力
Plan.agent.md の先頭には、YAML っぽいメタ情報が入っています。
ここは「Plan が何をできて、何ができないか」を決める層です。
ここにあるキーは、主に「許可された能力」と「UI導線」を規定します。
- tools: 利用可能なツールが列挙される
- 読み取り系が中心なら、Plan は調査・整理・質問に寄りやすい
- vscode/askQuestions が含まれていれば、要件確定のための質問を挟みやすい
- handoffs: 次工程への引き渡しが定義される
- 計画作成後に「実装へ渡す」導線が UI として固定される
- argument-hint: 期待する入力が短く提示される
- 依頼文を短くまとめる圧がかかりやすい（入力の粒度が揃いやすい）
2. rules：Plan が実装しない理由が書いてある
Plan.agent.md の <rules> は、Plan を Plan たらしめているコアです。
このブロックに「編集を止める」「実装しない」「質問で埋める」が書かれていると、出力が次の傾向になります。
- 編集・実装の手順ではなく、確認事項や設計観点が先に出る
- 大きい仮定を置かずに、質問で要求を固めようとする
例として、次のような禁止が明示されています。
- "STOP if you consider running file editing tools"
- "NEVER start implementation"
3. workflow：なぜこの順番で進むのか
<workflow> には、Plan がどういう順番で考えるべきかが書いてあります。
ここは、Plan が「なぜあの順番で質問してくるのか」を理解するのに効きます。
ワークフローは4フェーズとして定義されています。
- Discovery：まず調査する
- Alignment：曖昧さを質問で揃える
- Design：計画（DRAFT）を作る
- Refinement：ユーザーの反応で更新する
Discovery：調査を分離する
Discovery では、調査を別エージェントに委譲する前提が書かれています。
- "Run #tool:agent/runSubagent to gather context"
- "Research ... using read-only tools"
この条件があると、Plan の出力は「調査結果を前提にした設計」になりやすいです。
Alignment：質問で仕様を確定する
Alignment では、曖昧さが大きい場合に質問ツールを使う方針が明示されています。
- "Use #tool:vscode/askQuestions freely to clarify requirements"
この記述があると、Plan は「決め打ち」より「質問→確定」に寄ります。
Design：DRAFT を前提にする
Design のフェーズには「DRAFT」という言葉が入っています。
ここは「計画はレビューされる前提」という態度が入っている。
この前提があると、Plan は確定版ではなくレビュー可能な叩き台を出しやすいです。
Refinement：反復で詰める
Refinement は「直して終わり」じゃなく、状況によって Discovery に戻る判断も含みます。
つまり Plan は、一本道のチェックリストではなく、反復で詰める設計です。
4. plan_style_guide：出力の型が固定される
Plan.agent.md の後半には、Plan がどう書くべきかの型が入っています。
このブロックから読み取れる「出力の傾向」は次のとおりです。
- Steps：具体的な手順
- Verification：検証の方法
- Decisions：意思決定の記録
Verification と Decisions が必須要素として入ると、計画が「実装手順だけ」になりにくいです。
また、意思決定の記録が残る設計になります。
また、書式に関する制約も明示されています。
- "NO code blocks"
- "NO questions at the end"
この制約があると、Plan は「まず質問で固めてから、最後は計画だけを提示する」形に寄ります。
5. handoffs：次の工程へ誘導する
Plan.agent.md には handoffs が定義されています。
これは Plan の仕事が終わった後に、次に何をすべきかを UI のボタンに落とす仕組みです。
handoffs が定義されていると、計画後に実装へ移る導線が固定されます。
まとめ：Planモードの挙動はどこで決まるか
Plan.agent.md に書かれた文言から、Planモードの挙動は次の要素で規定されます。
- tools：利用可能なツール（調査・質問のやり方）
- <rules>：禁止事項（実装に踏み込まない、編集しない）
- <workflow>：進め方（調査→質問→設計→反復）
- <plan_style_guide>：出力形式（Steps/Verification/Decisions、コードを出さない等）
- handoffs：次工程への導線（計画→実装の切り替え）
Plan.agent.md を読むと、Plan の挙動を「文言→傾向」の形で説明できます。
特に、tools / <rules> / <workflow> / <plan_style_guide> / handoffs を押さえると、質問の出方や、計画の粒度、実装へ踏み込まない理由が追いやすくなります。
