orchestrator

オーケストレーション：サブエージェント、エージェントチーム、並列実行

以下のルールは、すべての並列化の判断に適用されます。すべてのタスクで遵守してください。

単一アクションのリクエスト、簡単なファイル編集、逐次実行のみのワークフローには適用しません。

ディスパッチ

$ARGUMENTS	アクション
(empty)	空のヘルプギャラリーを表示し、現在のリクエストに分類ゲートと分解ゲートを適用する
pattern <A-F>	references/patterns.md から指定されたパターンを表示する
tier	ティア選択テーブルとモデルのガイダンスを表示する
recovery	アカウンティングルールとリカバリラダーを表示する

標準用語

標準用語	意味
subagent	セッション内で並列実行される、Task ツールによって起動されたエージェント
wave	1 回のメッセージでディスパッチされる、並列サブエージェントの一群
team	リードが調整する、TeamCreate によって起動されたチームメイトのグループ
teammate	担当ファイルを割り当てられたエージェントチームのメンバー
lead	チーム内のオーケストレーションを担うエージェント。自ら実装することはありません
dispatch	1 人以上のサブエージェント／チームメイトに並列実行を指示すること
gate	次に進む前に必ず通過しなければならないチェックポイント
accounting rule	ディスパッチした数と解決した数を一致させるルール。エージェントを黙って放置しないこと

ゲートのロジック

オーケストレーションの完全な指針を読み込む前に、次のゲートを使用してください。

1. リクエストにアクションがちょうど 1 つだけある場合は、単一セッションで対応し、このスキルを呼び出さないでください。
2. 作業に複数のステップがあっても、すべて同じファイルを編集する場合、または厳密な順序に依存する場合は、並列化を無理に行わず、逐次実行の制約を明確にしてください。
3. 分解方法が明確でない場合は、まず調査を行ってからゲートに戻り、構成を推測しないでください。
4. 別の有効なスキルに、より厳格なフェーズ順序やディスパッチの前提条件がある場合は、そのスキルの制御フローを維持し、許可された範囲内でのみ並列化してください。
5. ユーザーが特定の実行方法を明示的に求めている場合は、厳格な安全上の制約と矛盾しない限り、その指示に従ってください。

オペレーターの契約

空／ヘルプ

1. 公開されているエントリーパス（空／ヘルプ、pattern <A-F>、tier、recovery）を提示します。
2. 分解ゲートを適用する前に、分類ゲートを実行します。
3. このスキルの適用対象とすべきでない、判断を誤りやすいケース（単一アクションの作業、同一ファイルの逐次作業、より厳格な順序があるフェーズ制のスキル）を説明します。
4. 指針全体を貼り付ける代わりに、パターン選択、進捗管理、実行時の制限、誤った振り分けの例に必要な参照先を示します。

pattern <A-F>

1. references/patterns.md を読み込みます。
2. 指定されたパターン、その用途、適用すべきでない場合、リカバリへの影響を提示します。
3. 指定されたパターンが実際のリクエストに明らかに適している場合を除き、パターン E をデフォルトにします。

tier

1. メカニズムの制限や環境固有のツール制約について説明する前に、references/runtime-capability-boundaries.md を読み込みます。
2. ティア選択テーブルを提示し、該当する最も高いティアが優先される理由を説明します。
3. アクションがちょうど 1 つの場合や、調整を必要としない単一領域のタスクなど、より低いティアが引き続き適切となる、判断を誤りやすいケースを挙げます。

recovery

1. references/progress-accounting.md を読み込みます。
2. アカウンティングルール、リカバリラダー、報告に関する契約を提示します。
3. 次のウェーブに進む前に、応答のないエージェント、再起動、明示的なスキップをどのように扱うかを説明します。

0.5 不確実性ゲート（事前および再開時）

分解ゲートの前、および再開時に、instructions/global.md の深度ルーティングを適用します。

1. 安全な分解、ディスパッチ、または影響を受けるサブタスクを妨げている前提条件を列挙します。
2. まず、コードベースで解決できる項目を調査します。
3. 事前にユーザーの判断が重要な不確実性が残る場合、サブエージェントやチームメイトをディスパッチする前に /grill-me を実行します。
4. 中間ウェーブの分岐が subtask-pivotal に該当する場合、影響を受ける作業ストリームを一時停止し、スコープを限定した /grill-me を実行します（global.md のスコープ指定付き grill コントラクトを参照）。確定済みの計画領域について再度 grill しないでください。
5. 未解決のユーザー判断に依存する作業ストリームを並列化しないでください。重要な分岐でサブエージェントに推測させないでください。

再開のトリガー：

• サブエージェントまたはチームメイトが blocked-user-pivotal を返す（references/uncertainty-handoff.md を参照）
• ウェーブの状況報告に、未解決で重要なブロッカーが記載されている
• 次のディスパッチ前に、親エージェントが中間ウェーブの分岐を発見する

再開時の対応： 影響を受けるレーンを一時停止 → スコープを限定した /grill-me → プロンプトを更新 → 再開または再ディスパッチ。

ファストパス： 依頼の根拠が十分にあり、ユーザー判断が重要なブロッカーがない場合 → §0 に進みます。

0. 分解ゲート（作業開始前に必須）

ツールを介した作業を含む依頼を実行する前に、次の手順を行います。

1. 分解：必要なアクション（ファイルの読み取り、編集、検索、コマンド、分析）を列挙します。
2. 分類：どのアクションが独立しているか（データ依存関係がないか）、どのアクションが依存しているかを分類します。
3. 最大化：アクションをさらに積極的に分割し、並列化の機会をすべて見つけます。独立したアクションごとに、専用のサブエージェントを割り当てます。検討事項：各アクションを2つに分割できないでしょうか。
4. 競合チェック：独立した2つのアクションが同じファイルを編集する場合は順次実行にします。それ以外はすべて並列のままにします。
5. ディスパッチ：デフォルトはパターン E — TeamCreate を使用し、チームメイトごとにサブエージェントのウェーブをネストします。起動前に権限を事前承認します。単一のドメインで調整が不要かつコンテキストに余裕がある場合に限り、単独のサブエージェントウェーブを使用します。アクションが文字どおり1つしかない場合に限り、単一セッションを使用します。
6. 追跡：オーケストレーションを行う作業では、ディスパッチ前に TaskCreate のエントリーを作成します（セクション 7 を参照）。

ファストパス：アクションが1つだけの依頼は、単一セッションに直接進みます。

先行調査パス：調査なしでは分解できない場合、まず並列調査チームを起動します（パターン F ウェーブ 1）。その後、このゲートに戻ります。

移行の目安：サブエージェントのウェーブがコンテキスト制限に達した場合、またはエージェント間で調査結果の共有が必要になった場合は、パターン E（チーム＋ネストされたウェーブ）に切り替えます。

ユーザーによる上書き：特定の実行方法をユーザーが明示的に指定した場合は、それを優先します。

よくある正当化（すべて不適切）

• 「自分でやるほうが速い」— 並列のサブエージェントなら、N 個のタスクを最も遅い1つのタスクと同じ時間で完了できます。
• 「タスクが単純すぎる」— 独立したアクションが2つ以上ある場合は、並列化します。
• 「まずこれだけやろう」— 何かを始める前に分解します。

モードの制約

• 計画モード：サブエージェントは読み取り専用のみです。チームや書き込み可能なエージェントは使用できません。
• 実装モード：すべてのティアを利用できます。該当する中で最も高いティアをデフォルトにします。
• 委任モード：リードはオーケストレーションのみを行います。実装はすべてチームメイトまたはサブエージェントが行います。

スキルとの統合

superpowers スキルが有効な場合、ゲートはスキルの実行構造の範囲内で動作します。

• フェーズゲート付きスキル：各フェーズ内で並列化します。フェーズの境界をまたいで並列化しないでください。
• タスクごとのレビューループを持つスキル：スキルの順次実行構造を優先します。タスク間ではなく、各タスク内の調査を並列化します。
• ディスパッチ前提条件を持つスキル：スキルの「次の場合は使用しないでください」という条件は引き続き有効です。このゲートがスキルレベルの安全ガードを上書きすることはありません。

同じファイルへの順次編集、フェーズゲート付きレビューループ、アクションが1つだけの依頼など、ニアミスの具体例については references/misroute-examples.md を参照してください。

---

1. ティアの選択（必須 — 該当する最上位のティアを選択）

ティア	仕組み	使用する条件	モデル
チーム + ネストされたウェーブ（パターン E）	TeamCreate + チームメイトごとのサブエージェントウェーブ — 合計最大約 50 エージェント	独立した作業ストリームが 2 つ以上ある場合 — これがデフォルト	opus（デフォルト）/ Copilot：Opus 4.6 の最大思考。Sonnet 4.6 の最大思考は、非常に単純な /fleet 作業に限る
サブエージェントウェーブ	Task ツール、並列呼び出し	1 つのドメイン内に独立したアクションが 2 つ以上あり、調整の負荷がなく、同一ファイルに対する逐次的な連鎖もない場合	opus（デフォルト）/ Copilot：Opus 4.6 の最大思考。Sonnet 4.6 の最大思考は、非常に単純な /fleet 作業に限る
単一セッション	直接実行	アクションが 1 つだけの場合、または同一ファイルに対する逐次的な連鎖を直線的に維持する必要がある場合	該当なし

条件を満たす最上位のティアを選択してください。コストを抑えるために、より低いティアを選択してはいけません。アクションが 2 つあるだけでは不十分です。アクションは独立している必要があります。

スケーリング戦略

状況	推奨される形態
1 つのドメイン内の小規模な複数アクションタスク	独立性が真に高いアクションが 2 つ以上あり、調整の負荷がない場合に限り、サブエージェントウェーブを使用します。
複数ドメインにまたがる実装	明確に分けた担当範囲を設けてパターン E を使用し、詳しい作業の委任が有効な場合に限り、ネストされたウェーブを使用します。
調査 → 実装 → 検証の作業	複数ウェーブのパイプラインを使用し、次に進む前にウェーブ間の記録を完了させます。
同一ファイル、または順序が厳密に定められた作業	並列性を無理に作り出さず、逐次処理の境界を明確にします。

---

2. サブエージェントのベストプラクティス

起動

• 1 回の応答で複数の Task 呼び出しを行います。 独立したサブエージェントはすべて、同じメッセージ内で起動する必要があります。
• 結果がすぐに必要でないサブエージェントには、run_in_background: true を使用します。
• 独立したアクションが N 個ある場合は、並列サブエージェントを N 個起動します。ファイルやディレクトリの担当範囲が重なる場合に限り、統合します。

プロンプトの調整

• 各サブエージェントに、正確なファイルパス、期待する出力形式、ドメインの背景情報を含む、詳細で自己完結したプロンプトを与えます。
• サブエージェントが会話履歴を引き継ぐことを前提にしてはいけません。引き継ぎません。
• サブタスクで、親が事前に解決していない、ユーザーの判断が不可欠な不確実性に直面した場合は、推測せずに references/uncertainty-handoff.md に従って blocked-user-pivotal を返します。

モデルの選択

• デフォルトポリシー：すべてのサブエージェント、チームメイト、ウェーブに opus を使用します。
• GitHub Copilot CLI のオーバーライド：すべての計画は、/orchestrator に従って /fleet に最適化する必要があります。/fleet では、重要度の高いサブエージェント、チームメイト、ウェーブ、/fleet メンバーすべてに 最大思考の Claude Opus 4.6 を使用します。
• 最大思考の Claude Sonnet 4.6 を使用できるのは、非常に単純な /fleet サブエージェントに限ります。曖昧な点が少しでもあれば、Opus に切り替えてください。
• 両方のポリシーが適用される場合は、実行中の環境固有のオーバーライドを適用します。

コンテキスト管理

• テストスイートの実行、ログ解析、ドキュメント取得など、時間のかかる処理はサブエージェントに委任します。
• 複数フェーズにわたる作業では、新たに起動するのではなく、エージェント ID を使ってサブエージェントを再開します。
• ウェーブの完了後、内容をまとめたり次のウェーブを起動したりする前に、第 4 節の会計ルールを適用します。

3. エージェントチームのベストプラクティス

• 作業に合わせてチームメイトの数を調整します。人為的な上限はありません。並列性を最大限に高めるため、必要な数だけ使用してください（ネストされたサブエージェントを含め、合計で最大約50エージェント）。トークン予算は制約になりません。
• チームメイトを起動する前に、よく使う権限を事前承認して、手間を減らします。
• 各チームメイトに、他と重複しない担当領域とファイルの所有権を割り当てます。
• 担当領域に必要な数だけ、各チームメイトにタスクを割り当てます。人為的な上限はありません。
• 起動時のプロンプトには、ファイルパス、アーキテクチャ上の決定事項、受け入れ基準など、タスク固有のコンテキストをすべて含めます。チームメイトは会話履歴を引き継ぎません。
• リード自身が作業を実装しないよう、委任モードを使用します。
• タスクの取得にはファイルロックが使用されるため、複数のチームメイトが同時にタスクを取得しても競合状態は発生しません。
• 重複するファイルの所有権を複数のチームメイトに割り当ててはいけません。
• リードは、すべてのチームメイトのタスクを把握するまで、統合に進んではいけません（セクション4）。

---

4. 品質ゲートと障害からの復旧

追跡ルール（並列ディスパッチのたびに必須）

N個のエージェントをディスパッチした場合、先に進む前に、N個すべての状況を把握する必要があります。

1. 収集：N個すべてのエージェントから応答があるまで待ちます。タイムアウトを検出するには、TaskOutputをblock=falseでポーリングします。
2. 集計：受信した結果とディスパッチしたエージェントを照合します。不足分は未解決です。
3. 解決：成功しなかったものを、復旧手順（references/patterns.mdを参照）ですべて解決します。
4. ゲート：すべてのエージェントがSUCCESSまたは明示的なSKIPになるまで、先に進んではいけません。
5. 報告：先に進む前に、TaskUpdateを使用して、すべてのエージェントの結果を要約します。

自動適用のためのフック

• TeammateIdleフック：作業が検証される前にチームメイトがアイドル状態になるのを防ぎます。
• TaskCompletedフック：テストに合格する前にタスクが完了するのを防ぎます。
• どちらも終了コード2を使用してフィードバックを送り、チームメイトまたはタスクをアクティブ状態に保ちます。

計画承認のワークフロー

• リスクの高い変更では、起動時のプロンプトに「変更を加える前に計画の承認を必須とする」と含めます。
• チームメイトは読み取り専用の計画モードに入り、準備ができたらplan_approval_requestをリードに送信します。
• リードはフィードバックを添えて承認または却下します。却下された場合、チームメイトは計画を修正します。
• 起動時のプロンプトで承認基準を指定します。「テスト範囲を含む計画のみ承認してください。」

---

5. オーケストレーションパターン

パターン	名前	使用する場面	詳細
A	並列サブエージェントの一斉起動	1つのセッションで、独立したサブタスクが2つ以上ある場合	references/patterns.mdを参照
B	ファイル所有権を持つエージェントチーム	複数の領域にまたがる機能、大規模なリファクタリング	references/patterns.mdを参照
C	仮説の競合	デバッグ、アーキテクチャ上の決定	references/patterns.mdを参照
D	計画してから一斉に実行	人間の承認が必要な大規模なタスク	references/patterns.mdを参照
E	サブエージェントを使用するチームメイトのチーム（デフォルト）	独立した作業の流れが2つ以上ある場合。デフォルトで使用	references/patterns.mdを参照
F	複数ウェーブのパイプライン	調査 → 実装 → 検証の各フェーズ	references/patterns.mdを参照

---

6. 制限事項

• チームメイトのセッションは再開できません（/resumeや/rewindを使用しても復元されません）。
• ネストされたチームは作成できません（チームメイトはサブエージェントを使用できますが、チームを起動することはできません）。
• 1つのセッションにつきチームは1つです。新しいチームを開始する前に、現在のチームを片付けてください。
• リードは固定されており、リーダーシップを引き継ぐことはできません。
• すべてのチームメイトは、起動時にリードの権限モードを引き継ぎます。
• サブエージェントの再開では、すべての障害から復旧できるとは限りません（代わりに再起動してください）。
• タイムアウトの検出機能は組み込まれていません。オーケストレーターが手動でTaskOutputをポーリングする必要があります。
• 復旧のための再起動も、セッションのエージェント予算に含まれます。
• 表示モード：インプロセスモード（Shift+Downで切り替え）がデフォルトです。分割ペインにはtmuxまたはiTerm2が必要です。
• チームメイトとのやり取り：Enterでセッションを表示、Escapeで中断、Ctrl+Tでタスクリストを表示します。

段階的な開示

• オーケストレーションの詳細をすべてデフォルトで読み込まないでください。
• このスキルがそもそもタスクを担当すべきかどうかを判断するときは、references/classification-gate.md を読んでください。
• ユーザーが特定のパターンを求めている場合、またはトポロジーの選択が主な論点である場合にのみ、references/patterns.md を読んでください。
• レポート、進捗管理、または復旧動作について説明する場合は、references/progress-accounting.md を読んでください。
• サブエージェントがユーザーの判断を左右する不確実性に直面した場合、または blocked-user-pivotal を返した場合は、references/uncertainty-handoff.md を読んでください。
• ツールやランタイムの制限、または環境固有の制約がトポロジーに影響する場合は、references/runtime-capability-boundaries.md を読んでください。
• リクエストがトリガーの境界に近い場合は、references/misroute-examples.md を読んでください。

---

重要なルール

1. 独立したアクションを順番にディスパッチしてはいけません。独立した Task 呼び出しは、すべて同じ応答内に含める必要があります。
2. ツールを介した作業の前には、必ず分解ゲートを実行してください。これを省略することは認められません。
3. より高いティアの基準を満たしている場合、並列度やティアを下げてはいけません。文書化された環境固有のモデルポリシーに従ってください。
4. 失敗したサブエージェントを黙って除外してはいけません。ディスパッチ数 N に対して、N 件すべてを計上する必要があります。各ウェーブの後に計上ルールを適用してください。
5. Wave N のエージェントが未解決のまま Wave N+1 に進んではいけません。まず Wave N のすべてのエージェントを解決してください。
6. サブエージェントのウェーブやエージェントチームをディスパッチする前に、必ず TaskCreate のエントリーを作成してください。オーケストレーションを記録せずに行うことは禁止されています。
7. 2 人のチームメイトに、重複するファイルの担当を割り当ててはいけません。編集が重複すると、作業が失われる原因になります。
8. サブエージェントとチームメイトへのプロンプトには、必ず完全なコンテキストを含めてください。彼らは会話履歴を引き継ぎません。

---

参照ファイル一覧

ファイル	内容	読むタイミング
references/classification-gate.md	オーケストレーション開始前の呼び出しゲート、ニアミスのルール、先に確認するロジック	スキルを呼び出すかどうかを判断するとき
references/patterns.md	ASCII 図、主要ルール、復旧手順を含むパターン A～F の詳細	並列実行を設計する、またはパターンを選択するとき
references/progress-accounting.md	進捗追跡の契約、計上ルールの詳細、復旧・報告に関する要件	復旧、計上、または報告を説明するとき
references/uncertainty-handoff.md	サブエージェントの blocked-user-pivotal 返却契約と、親エージェントが行う範囲を限定した質問の義務	ウェーブ中に重要な障害が発生した場合、または再開するとき
references/runtime-capability-boundaries.md	ツールや環境の制限がトポロジーを制約する場合を含む、ティアとランタイムの境界に関する指針	ティアを選択するとき、または環境の制限について説明するとき
references/misroute-examples.md	誤検出とニアミスの具体例	境界線上のリクエストを確認するとき

---

7. 進捗の可視化（オーケストレーション作業では必須）

オーケストレーションを伴うすべての作業では、TaskCreate/TaskUpdate を通じて構造化された進捗指標を提示する必要があります。

ティア	要件	粒度
サブエージェントのウェーブ	必須	サブエージェントごとに 1 つのタスクを作成し、ディスパッチ前に登録する
エージェントチーム	必須	セットアップ時に、チームメイトの割り当てごとに 1 つのタスクを作成する
単一セッション（3 ステップ以上）	推奨	論理ステップごとに 1 つのタスクを作成する

ルール

• タスクは実行開始前に作成してください。事後に作成してはいけません。
• 各タスクには、対象となる具体的なアクションを示す、現在進行形の説明的な activeForm を必ず設定してください。
• 開始前にタスクを in_progress に更新し、完了直後に completed に更新してください。
• ウェーブの完了と計上の後、次のウェーブをディスパッチする前に、すべてのエージェントの結果を要約してください。

外部ハーネスへの委任（Grok Build）

マクログラフがノードを Grok Build に割り当てた場合も、親はウェーブ、ゲート、統合の責任を持ちます。/grok-delegate を介して実行を委任します。使用するのはネイティブの grok -p、-r、ワークツリー、リーダーのみです（カスタムラッパーは使用しません）。事前確認として、フリートへのディスパッチ前に /grok-delegate の事前確認を実行してください（grok-delegate スキルを参照）。親は、並列の Grok ノードを独立した bash サブプロセスとしてディスパッチします（パターン A/E）。親のゲートに失敗した後は、-r <sessionId> を使って進行中のブランチを調整します。

Tier-T の簡易オフロード： 分解時に、各リーフが Tier-T の対象かどうかを分類します。高速な事前確認が ok で、grok-auth-expiry: ok の場合、対象となる範囲限定のリーフ（読み取り 3 回以下、または 80 LOC 以下のファイル 1 つ以下）は、既定で /grok-delegate trivial による単一ノードの grok -p に割り当てます。統合は親が行います。複数ノードのグラフ、書き込みの競合、広範な作業、破壊的なタスクや本番環境／git-push のタスク、シークレットを読み取るタスク、または未解決のユーザーにとって重要な不確実性／サブタスクにとって重要な不確実性には適用できません（まず範囲を限定した /grill-me で解決してください）。最初のネイティブな Tier-T のディスパッチに失敗した場合は、現在の親作業項目について Tier-T を中止し、ローカルで続行します。

範囲の境界

対象： 分解、オーケストレーションのトポロジー、パターンの選択、進捗の記録、復旧／報告、およびマルチエージェント実行のルール。

対象外： 単一アクションのリクエスト、直列のまま進めるべき同一ファイル内の逐次作業、またはより厳格なフェーズゲート型スキルの契約に優先すること。