subagent-prompt

サブエージェントオーケストレーションプロンプト

この会話で話し合った作業を実行するために、ユーザーが新しいエージェントセッション（サブエージェントに対応しているもの）に貼り付けられる、自己完結型のプロンプトを1つ作成してください。新しいセッションはオーケストレーターとして、タスクごとにサブエージェントを割り当て、結果の統合のみを行います。コードの実装は行いません。

目標

現在のセッションでの作業を、新しいコンテキストウィンドウに引き継ぐため、次の条件を満たす形式にします。

• 各ステップでユーザーが逐一確認しなくても、最後まで実行できる
• タスクごとに1つのサブエージェントを割り当て、それぞれが独自のコンテキストウィンドウを持つ
• 各サブエージェントが報告前に自分の作業を検証する
• 最後に全体が機能していることを確認できるだけの情報をオーケストレーターに残す

ゲート

順番に完了してください。合格条件を満たすまで次に進まないでください。

1. ソース資料の特定 — 合格条件： このプロンプトで引き継ぐ具体的な成果物（計画ファイル、チェックリスト、ユーザーが説明した変更のリストなど）を指し示せること。会話に曖昧な意図しかない場合は、プロンプトの対象範囲をユーザーに確認してから作成してください。
2. タスク分解の明確化 — 合格条件： 各タスクを1つのサブエージェントが最初から最後まで担当できるほど小さく分けた番号付きリストがあること（または、すでにディスク上にあるリストを指し示せること）。作業が一枚岩の場合は、プロンプトを作成する前に分解してください。
3. タスクごとの検証手順の指定 — 合格条件： 各タスクについて、成功を報告する前にサブエージェントが実行すべき具体的な確認手順（型チェックコマンド、テストコマンド、リンター、ファイルの確認など）を明記していること。「動作を確認する」では不十分です。
4. プロンプトの作成と自己完結性 — 合格条件： 作成したプロンプトが、会話の記憶をまったく持たない新しいエージェントセッションでも理解できること。パス、使用するツール、検証コマンド、成功条件を明記してください。

生成するプロンプトに含める内容

ユーザーがコピーできるよう、引き継ぎ用プロンプトを単一のフェンス付きブロックに記述してください。次の順序で含めてください。

1. 役割の行 — 「あなたはオーケストレーターです。タスクごとに1つのサブエージェントを割り当ててください。自分でコードを実装しないでください。」
2. コンテキスト — 作業内容、ソース資料の場所（計画ファイルのパス、仕様ファイルのパス、リポジトリのパス）、および明白でない制約を記述します。新しいセッションが迷わず読み込めるよう、ファイルは絶対パスで指定してください。
3. タスクリスト — 各タスクに、番号、タイトル、入力成果物（パス／セクション）、使用するサブエージェントの種類、報告前に実行して合格しなければならない具体的な検証手順を含めます。
4. 検証の取り決め — 検証に合格してからのみ各サブエージェントが報告するよう明示し、報告には変更内容、実行した検証コマンド、検証結果（出力の末尾数行、または短い場合は全出力）を含めるよう指示します。
5. 最後まで実行するための条項 — 「すべてのタスクが完了するまで、タスクの割り当てを続けてください。サブエージェントから検証失敗の報告を受けた場合は、次に進む前に、問題を診断して修正するフォローアップのサブエージェントを割り当ててください。最後の統合チェックに合格するまで停止しないでください。」
6. 最後の統合チェック — 全タスク完了後、プロジェクト全体が機能していることを確認するためにオーケストレーターが実行する単一のコマンド（または短い一連のコマンド）を記載します（プロジェクトの型チェック、全テストスイート、リンター、スモークテスト実行など）。具体的に指定してください。
7. 失敗時の対応方針 — サブエージェントが同じ手順で2回行き詰まった場合に何をすべきかを記載します（作業範囲を黙って縮小せず、ユーザーにエスカレーションする）。

ドラフト作成の規律

• 絶対パスのみを使用します。 新しいセッションでは、このセッションの作業ディレクトリを基準に相対パスを解決できません。
• 具体的なコマンドのみを記載します。 「テストを実行する」はコマンドではありません。cargo test --package osprey-core はコマンドです。
• サブエージェントの種類を明記します。 対象のハーネスで汎用サブエージェントが使える場合は、そのように記載します。専門エージェントが適している場合（例：検索専用のエクスプローラー）は、対象環境で使われている名称を明記します。オーケストレーターに推測させないでください。
• 「判断に任せる」という逃げ道を作りません。 タスクに判断が必要な場合は、基準をあらかじめ指定します。それができない場合、タスクはまだ引き継げる状態ではないため、ドラフトを作成する前にユーザーに伝えます。
• 信頼できる情報源は一つにします。 プランファイルがディスク上に存在する場合、プランを繰り返し記載するのではなく、そのファイルを参照するようオーケストレーターに指示します。書き直すと内容にずれが生じるため、ファイルを正式な情報源とします。

ワークフロー

1. ソース資料を特定します（ゲート 1）。.beagle/concepts/<slug>/plan.md または同等のファイルが存在する場合は、それを軸にします。存在しない場合は、プロンプトの作成に何を使うかユーザーに尋ねます。
2. タスクの分割を確認します（ゲート 2）。ソースですでにタスクが列挙されている場合は、その番号をそのまま使います。そうでない場合は分割案を提示し、ドラフトを作成する前にユーザーの確認を得ます。
3. 各タスクの検証方法を定義します（ゲート 3）。プロジェクトの実際のツールに合わせます。AGENTS.md や CLAUDE.md などのプロジェクト規約ファイル、および Makefile／package.json／Cargo.toml を確認し、適切なコマンドを見つけます。
4. プロンプトを単一のフェンス付きブロックとして作成します（ゲート 4）。「生成するプロンプトに必ず含める内容」のチェックリストにある項目をすべて含めます。
5. 作成したプロンプトをチャットに提示します。新しいセッションを開始し、そこにプロンプトを貼り付けるようユーザーに伝えます。
6. 必要に応じて、制約の抜け、パスの誤り、検証計画の不備にユーザーが気づいた場合は、修正を申し出ます。

このスキルが適さない場合

• 作業が1つのセッションと1つのコンテキストウィンドウで完了する場合は、そのまま実行します。
• 作業が探索的または実験的で、ユーザーが明示的に作業に関与し続けたい場合は、大がかりなオーケストレーションへの引き継ぎは過剰です。
• 引き継ぐ具体的な成果物がまだない場合は、まず brainstorm-beagle または write-plan スキルを案内し、このスキルで引き継ぐ仕様とプランを作成します。