multi

Multi

並列サブエージェントのオーケストレーションにおける信頼できる情報源です。

ホストの Task ツール（Cursor の場合は Subagent）を使って、独立したサブエージェントを並列実行します。オーケストレーションカーネルのみを提供します。ジョブの手順とドメイン固有の統合は、エントリースキルが担います。

クイックリファレンス

必要な情報	場所
必ず実行する不変条件	必須事項
モデルのルーティング（コストと適合性）	references/model-routing.md
敵対的／段階的な討論	references/adversarial.md
汎用タスクプロンプト	references/task-prompt.md
メンバーごとの出力形式	references/member-schema.md
汎用の統合レポート	references/output-format.md
エージェントの検出（機械的）	references/agent-discovery.md
調査の根拠（調整用）	references/research-basis.md

判断の調整や調査上の主張を行うときは、調査の根拠を確認してください。習慣的に読み込まないでください。

必須事項

このスキルが適用される場合（ユーザーが multi を指定した場合、エントリースキルが並列ディスパッチを実行する場合、または計画でメンバー数を N ≥ 2 とした場合）：

1. 実際のメンバーを起動する — モデルの割り当てに従って選んだ subagent_type とモデルを指定し、計画したメンバーごとにホストの Task ツールを1回実行します。並列の read_file／grep／その他のツールは、メンバーの実行の代わりにはなりません。
2. メンバーの実行後に統合する — 統合ゲートでメンバーの出力を統合します。先に Task を実行せずに統合レポートを作成するのは、最適化ではなく違反です。
3. 不当な理由付けは禁止 — リポジトリをすでに読んだ、調査結果が重複しそう、レイテンシを下げたい、トークンを節約したい、差分が「ドキュメントのみ」「skills/agent-infra」「単一テーマ」である、といった理由で起動を省略しないでください。
4. 省略が有効な場合 — 次の場合に限り、並列起動を省略できます。ユーザーが断るか、単一パスを求めた場合、ジョブが適合性チェックに該当し、かつエントリースキルがすでに並列ディスパッチを実行していない場合、ホストが Task を実行できない場合、または計画したメンバーが1人だけの場合です。

モデルのルーティング： メンバーごとにモデルの割り当て／model-routing.mdを適用します。使用上限に達した場合やクレジットが枯渇した場合は、使用上限に達した場合の再試行に従います。

適合性チェック

N ≥ 2 の計画を立てる前に、単一パスの対抗案を挙げます。同じジョブを、1つの連続したコンテキストで、1人のエージェントがより深い主調査とより多くのツール使用によって行う案です。分担が独立しており、かつ対抗案ではその独立性（異なる信頼できる情報源、見落としの許容度の非対称性、または真に広範な調査）をカバーできない場合にのみ、メンバーを並列起動します。

multi を使う場合：メンバーが独立しており、並列作業によって網羅性、速度、または確信度が向上する場合です。たとえば、複数の情報源からの情報収集、幅広い探索、直交する調査テーマ、または複数種類の情報収集パスなどです。

multi を省略する場合：単一パスの対抗案で十分な場合、作業が逐次的な場合、確信度を高めることなくメンバー間で作業が重複する場合、またはユーザーが権威ある単一の調査を求めている場合です。

エントリースキルの例外： code-review（または別のエントリースキル）が並列ディスパッチ／評議会にエスカレーションした場合、または second-opinion が段階的な討論を必須としている場合、適合性チェックは適用されません。「1人のエージェントで十分か」を再検討しないでください。そのスキルのメンバー数の上限と必須事項に従ってください。

ディスパッチモード

• 網羅性 — ソース、サブシステム、ドメイン、または成果物ごとに分担します。例：あるメンバーはデータフローをマッピングし、別のメンバーは呼び出し箇所を調べます。
• 視点 — 同じ資料を、異なる立場から検討します。プロンプトが同一なら、モデルの多様性だけでは不十分です。
• 敵対的 — 視点の特殊形です。キル指示、コンテキストの非対称性、収束・発散型の統合を用います。詳しい手順 → adversarial.md。
  • 並列 — 1つのウェーブで、メンバーは独立して作業します（エスカレーション時は code-review、意見が分かれる場合は investigate）。
  • 段階的な議論（Goal: adversarial-staged）— 第1ウェーブは攻撃側、第2ウェーブは擁護側で、コーディネーターが作成した第1ウェーブの概要を受け取る場合があります。同一ウェーブ内の隔離原則に対する、許可された逐次実行の例外です。メンバー間のリアルタイムチャットではありません。

厳守ルール： 同一のモデルと同一のプロンプトを使うメンバーを並列実行してはいけません。全メンバーが Auto を引き継ぐ場合は、異なるプロンプトや視点で多様化します。Auto を共有するのは想定どおりです。敵対的なクロスモデルの多様化 → adversarial.md § モデルルーティングのオーバーレイ（名前付きの親またはユーザーからのリクエストがある場合のみ。多様化だけを目的にティアを上げてはいけません）。

ワークフロー

1. 分類する

該当するエントリースキルのレシピがある場合は読み込み、ない場合は手動で計画します。

• 作業タイプ：research | explore | gather | mixed
• 正とする情報源：web | repo | plan
• 目標：網羅性 | 複数の視点 | 敵対的 | 段階的な敵対的議論 | 両方
• 独立性：同じウェーブのメンバーが互いの出力を必要とする場合は逐次実行です。そのメンバーを並列で起動してはいけません。例外： 段階的な議論（adversarial.md § B）では、コーディネーターが作成した概要を使い、第1ウェーブの後に第2ウェーブを実行します。

2. 計画して起動する

1. 検出 — 評議会エージェントが該当する可能性がある場合は agent-discovery.md を参照し、それ以外の場合はホスト組み込みの subagent_type 値を直接選びます。
2. ディスパッチ計画 — 起動前に作成します。エントリースキルの例外が適用されない限り、単一パスの競合案（エージェント1つと、より詳細なパスでは不十分な理由）を含めます。

Task: [What the user asked]
Classification: [research / explore / gather / mixed]
Source of truth: [web / repo / plan]
Goal: [coverage / perspectives / adversarial / adversarial-staged / both]
Single-pass rival: [one agent + deeper pass — why insufficient, or "entry-skill carve-out"]

Parent model: [Auto | <named model>]
User model overrides: [none | member=slug, …]
Auto reachable: [inherit-auto | model=auto | no]
Host supports: [Task model enum values checked]
Billing pool: [first-party | API | mixed]
Explicit model slugs used: [none | slug + slice-fit reason + cost note]
Fast variants used: [none | slug + explicit latency reason]

Selected members:

- [subagent_type] · tier=[Fast|Standard|Premium] · model=[inherit-auto | slug] · stance=[id or n/a]: [sub-task and expected output]
- [subagent_type] · tier=[Fast|Standard|Premium] · model=[inherit-auto | slug] · stance=[id or n/a]: [sub-task and expected output]

Why these members: [brief justification]
Synthesis plan: [how outputs will be merged or adjudicated]

inherit-auto はディスパッチ計画専用のセンチネルです。Task/Subagent の model 引数を省略するという意味です。モデルスラッグではありません。inherit-auto を任意の明示的なスラッグに変換してはいけません。ホストの Task 列挙型に auto が明示的に含まれている場合に限り、model=auto を渡します。

3. 起動前ゲート — 起動前のモデルルーティングゲートを実行し、矛盾がある場合はフェイルクローズします。すべてのメンバーについて、計画と一致するモデルの処理が確定するまで、Task/Subagent 呼び出しを行ってはいけません。
4. 起動 — メンバーごとに Task を1つ、並列で実行します。task-prompt.mdに従ってプロンプトを作成します。計画とツールの構文： 計画の model=inherit-auto → ツール呼び出しでは model を省略します。計画の model=<slug> → そのスラッグがホストの列挙型に含まれている場合に限り、model="<slug>" を渡します。使用量やクレジットのエラーが発生した場合 → 使用制限時の再試行。

メンバー計画のデフォルト：

• 調査 → 独立したトピックごとに1人のメンバー
• 探索 → 領域、サブシステム、または成果物の種類ごとに1人のメンバー
• 情報収集 → 正とする情報源、または網羅性の観点ごとに1人のメンバー
• 混合 → 分担が独立したままの場合に限り、役割を組み合わせます

3. 統合する

統合ゲートを適用します。

統合ゲート

前提条件： 計画されたメンバーごとに、少なくとも1つの Task が完了していること（上記の有効なスキップが適用される場合を除きます）。メンバーが一人も実行されていない場合、複数メンバーによるレポートを捏造してはいけません。

メンバーから結果が返された後：

1. 一致する調査結果を統合し、最も高い共通の確信度で一度だけ述べます。
2. 意見の相違を残し、平板化してはいけません。
3. 重大な矛盾がある場合は、model-routing.md に従い、順次実行のタイブレーカーを1回だけ実施します（Auto を優先し、それ以外では最も適切な上位モデルを使用します）。またはユーザーにエスカレーションします。
4. output-format.md に従い、統合レポートを1つ作成します。

ドメイン固有の統合（レビュー提出、調査の判定、セカンドオピニオンのセクション）については、エントリースキルのレシピに従います。

フォールバックマトリックス

評議会エージェントを利用できない場合、またはホスト組み込み機能のみを使用するジョブの場合：

必要な作業	優先するもの	フォールバック
リポジトリマップ	explore	generalPurpose
Web 調査	docs-researcher	generalPurpose
計画構成の批評	generalPurpose + 立場	HOST 内で dispatch.contexts に plan が含まれる場合は評議会エージェント

スキップした評議会エージェントと選択したフォールバックを、利用可能性ログに記録します。

モデルの割り当て

現在のホストで許可されている Task ツールの model enum を使用します。スラッグを推測してはいけません。デフォルトで最も高性能なものではなく、十分な品質を満たす最も安価なものを優先します。

手順の全容は model-routing.md を参照してください：ルーティングの優先順位（標準の順序）、親を考慮したルーティング、計画とツールの構文、起動前のモデルルーティングゲート、フェイルクローズ（起動しない）、明示的なルーティング（名前付きの親のみ）、低速優先（並列）、Auto への到達、使用制限時の再試行。

不変条件： Parent model = Auto でユーザーによるモデルの上書きがない場合、すべての Task/Subagent 呼び出しで model プロパティを省略します。inherit-auto はディスパッチ計画専用のセンチネルであり、任意の明示的なスラッグに変換してはいけません。Auto を親とする場合、ティアラベルによってスラッグを選択することはありません。

エージェント数

範囲	数	条件
小規模	2–3	対象を絞った機能、調査 + 検証
中規模	4–6	複数の関連領域、または複数種類の情報収集
大規模	7–10	広範な調査、または包括的なリサーチ

メンバーが10人を超える場合は、複数の multi 実行に分割します。

制限事項

• メンバーは最大10人です
• 同じウェーブのメンバーは独立して作業し、メンバー間で連絡を取りません（段階的なディベートの第2ウェーブには、コーディネーターが作成した第1ウェーブのブリーフを渡せる場合があります。詳しくは adversarial.md を参照してください）
• 並列で独立した作業に適しており、順次実行するワークフローには適していません（段階的な敵対的検討を除く）
• 起動時のオーバーヘッドにより、小さなタスクでは非効率です

出力形式

output-schema.md に従います。統合実行では references/output-format.md を使用します。

コンシューマーのバインディング

プロジェクトのレシピインデックスと評議会エージェントのパスは、スキルの読み込み時にプロジェクト固有の注入コンテキストとして渡されます。同期されたコピーを直接編集しないでください。