subagent-orchestrator

サブエージェントオーケストレーター

ユーザーが依頼したタスクのために、一時的なサブエージェントチームを編成します。メインスレッドではスコープ、意思決定、統合に集中し、委任されたエージェントには範囲を限定した作業を担当させます。

運用モード

• ユーザーがサブエージェント、作業の委任、並列作業、一時的なチームを明示的に依頼した場合は、このスキルを使用します。
• $subagent-orchestrator の明示的な呼び出しは、サブエージェントを使用する許可として扱います。
• チームの編成では、実行よりも計画を先に行います。
• その場しのぎでエージェントを追加するのではなく、明確な担当範囲を定めた役割ベースの委任を優先します。
• 中間作業の雑多な内容はメインスレッドに持ち込まず、生のエージェントのやり取りではなく要約を返します。

リソースマップ

まず references/roles-index.md を読みます。その後、タスクに合った役割とパターンのファイルのみを読み込みます。

• 役割の契約と拡張ルール：references/role-contract.md
• 役割レジストリ：references/roles-index.md
• チームパターン：references/team-patterns.md
• コアロール：
  • references/role-lead.md
  • references/role-planner.md
  • references/role-explorer.md
  • references/role-implementer.md
  • references/role-reviewer.md
  • references/role-tester.md
  • references/role-integrator.md

チームモード

チームを編成する前に、次のいずれかのモードを選びます。

• assemble-only：作業を開始せず、メンバー構成、担当範囲、実行順序を作成します。
• assemble-and-run：チームを編成して、すぐに作業を実行します。ユーザーが今すぐタスクを実行するよう依頼した場合は、これを既定で使用します。
• reuse-team：関連するコンテキストを引き続き担当している稼働中のサブエージェントを継続して使用します。適切な稼働中のチームがない場合は、assemble-and-run に切り替えます。

オーケストレーションのワークフロー

ユーザーがより限定的な成果物を求めていない限り、次の手順に従います。

1. タスクを明確にする

次の項目を抽出して言い直します。

• ユーザーの目的
• 必要な成果物
• 制約、承認、安全上の境界
• 関連するコードベース、ファイル、成果物
• 時間的な緊急性
• 希望するチームモード

依頼でサブエージェントの使用が明確に求められておらず、このスキルも明示的に呼び出されていない場合は、サブエージェントを起動しません。確認するか、単一エージェントで対応します。

2. 実行形態を分類する

タスク全体に1つ、またはスライスごとに1つ、次のラベルを使用します。

• read-only：調査、レビュー、要約、ログ分析、テストのトリアージ、アーキテクチャの把握
• disjoint-write：別々のモジュールやテストファイルなど、重複が少ない明確な担当範囲に分けた作業
• overlap-write：共有インターフェース、変更が集中するファイル、スキーマ変更、ルーティング層、中心的な型、複数のエージェントが変更する可能性のある設定

判断に迷う場合は、より厳格なラベルを選びます。

3. チームを編成する

必要に応じて references/roles-index.md と references/team-patterns.md を読みます。

次のルールを適用します。

• lead は必ず1人選びます。
• 依頼が曖昧な場合、スコープが不十分な場合、または実装前に契約の確定が必要になりそうな場合は、planner を追加します。
• 調査量の多い作業では、1人以上の explorer を追加します。
• 各担当者に明確な作業範囲を割り当てられる場合に限り、implementer を追加します。
• 挙動が変わる可能性がある場合は、検証のために reviewer と tester を追加します。
• 複数の担当者が共有領域を変更する場合、または重複のリスクが無視できない場合は、integrator を追加します。

レジストリにある既定の役割を優先します。適切な既定の役割がない場合は、references/role-contract.md に従って一時的な役割の概要を作成します。一時的な役割はタスク内にとどめ、ユーザーから明示的に依頼されない限り、永続化しません。

4. 所有権と引き継ぎを明確にする

各サブエージェントについて、次の項目を定義します。

• ミッション
• 担当範囲
• 担当するファイル、モジュール、または分析領域
• 禁止される領域
• 必要なツールまたは成果物
• 期待される成果物
• 専門家としての基準：担当領域において最も経験豊富な専門家として行動し、勤勉かつ厳密で、信念に基づいた姿勢を保ち、雑な作業や担当範囲を逸脱する作業を拒否すること
• 停止条件
• 待機方針

書き込みを伴う作業では、次の点に従います。

• ホットスポットや共有コントラクトごとに、指定ライターを必ず1人だけ割り当てます。
• 可能な場合は、並列実装の前に共有インターフェースを固定します。
• 競合リスクのある重複作業は、まず並列で提案を作成し、その後に実装する2段階の流れにします。

5. 実行パターンを選択する

ステップ2の分類を使用します。

• read-only：調査、レビュー、要約を並列化し、その後に統合します。
• disjoint-write：担当範囲ごとに並列化し、その後に統合して検証します。
• overlap-write：まず提案を作成し、その後、共有実装を指定ライターまたはintegratorに割り当てます。

実装後、安全であれば検証のために並列作業を再開します。

• reviewer：バグやリグレッションを確認します
• tester：コマンドとエッジケースの網羅性を確認します
• explorer：見落とされた呼び出し箇所や依存関係への影響を調査します

6. 範囲を限定したプロンプトで実行する

各サブエージェントには、タスクの成功に必要な最小限のコンテキストを渡します。

次の項目を含めます。

• タスクの範囲
• 担当範囲
• 期待される出力
• 制約と禁止される領域
• 専門家としての基準：その範囲において最も経験豊富な専門家として振る舞い、役割の境界内で勤勉かつ厳密で、信念に基づいた姿勢を保つこと
• 待機するか、独立して作業を続けるか

タスクで明示的に必要とされない限り、意図する回答や隠れた診断を漏らさないでください。

7. メインスレッドで統合する

メインスレッドは簡潔に保ちます。

次の内容を返します。

• 最終的な担当者一覧
• 実行クラスと選択したパターン
• 担当範囲の対応表
• 主な調査結果または実装結果
• 未解決のリスクと次のステップ

メインスレッドに生のログをそのままコピーするのではなく、サブエージェントの要約を使用します。

書き込み時の安全ルール

コードの変更を伴う場合は、常に次のルールを適用します。

• 複数のライターに同じホットスポットファイルを同時に編集させないでください。
• 競合リスクが現実にある場合は、提案作業と書き込み作業を分けてください。
• スキーマ変更、共有型、パブリックAPIコントラクト、マイグレーション、中央設定、ルーティングは、指定ライター1人に割り当ててください。
• 複数のパッチを一貫性のある形で反映する必要がある場合は、integratorを使用してください。
• 共有ファイルへの書き込みに関するリスクが低減した後にのみ、並列作業を再開してください。
• 競合する編集を急いで行うよりも、時間がかかっても管理されたマージ手順を優先してください。

出力形式

ユーザーがチーム計画を求めた場合、またはオーケストレーションを要約する必要がある場合は、次の形式を使用します。

# Team Plan

## Objective
- <goal>

## Team Mode
- <assemble-only | assemble-and-run | reuse-team>

## Execution Class
- <read-only | disjoint-write | overlap-write>

## Roster
- <role>: <mission and owned scope>

## Handoffs
- <who waits on whom and why>

## Risks
- <conflict, ambiguity, or approval risks>

作業完了を報告する場合は、HandoffsをResultsに置き換えます。

ロールライブラリの拡張

ロールレジストリをプラグインシステムとして使用します。

新しい恒久的なロールを追加するには、次の手順に従います。

1. references/role-contract.mdに従って、新しいreferences/role-<name>.mdファイルを作成します。
2. references/roles-index.mdにロールを登録します。
3. 新しいロールによって再利用可能なチーム枠または新しい共通パターンが導入される場合に限り、references/team-patterns.mdを更新します。
4. 以前の選択ロジックが引き続き機能するよう、能力タグを安定させます。

メインワークフローに正確なロール名をハードコーディングするのではなく、能力タグと書き込みポリシーに基づいてロールを選択してください。