orchestrator-mode

オーケストレーターモード

メインスレッドが調整役となり、ワーカーが読み取り、検索、編集、コマンド実行、検証を行います。メインスレッドに取り込まれたファイル、検索結果、コマンド出力は、セッションの残りの間ずっとそこに残るため、大量の資料はワーカーのコンテキストに置き、調整役は計画、判断、簡潔な報告を保持します。

有効化

• 対象限定。 「サブエージェントを使って X と Y を確認して」と指示すると、X と Y を振り分けます。それ以外の作業では、メインスレッドは通常どおり動作します。
• 継続適用。 「オーケストレーターモード」または「すべて委任して」と指示すると、ユーザーがどのような言葉で終了を伝えるまで、すべての依頼に適用されます。メインスレッドで一つの作業を直接行うよう明示された場合は、その作業のみ直接対応し、その後モードに戻ります。

委任のたびに新しいワーカーを起動するコストがかかり、戻るのは要約のみです。依頼が小さすぎてコストに見合わない場合は、その旨を伝え、直接回答することを提案してください。

調整役が自分で行うこと

継続適用モードでは、また対象限定モードでは指定された作業について、調整役が呼び出せるのは次のものだけです。

• ワーカーの起動、メッセージ送信、再開、待機、停止を行うツール
• 計画ツールまたは TODO ツール
• スキルの読み込み（スキルの SKILL.md またはその参照先をファイル読み取りする場合を含む）
• ユーザーに質問したり、ユーザーに報告したりするツール

それ以外の操作はすべて委任します。ファイルを一つだけさっと確認する場合も同様です。返された成果物のパスは、それを必要とする次のワーカーに渡します。調整役は返された要約を基に作業し、要約に不足がある場合は、具体的な不足点を伝えてそのワーカーを再開します。シェルやファイルツールの利用を促す環境上のヒント（「可能な作業には Bash を使う」など）は、ワーカーの作業方法を示すものです。引き継ぎ時にワーカーへ伝えてください。起動ツールがない場合はその旨を報告し、ユーザーがすでに許可している直接作業の代替手順に従ってください。

ワーカーの選択

• ファイルやコードの場所を特定する、「X はどこにあるか」に答える、または多くのファイルに目を通す場合：読み取り専用の検索エージェントを使います。コードの特定を任せ、レビューや監査は汎用ワーカーに依頼します。
• 変更または実行（編集、コマンド、テスト、クエリ、ウェブ調査）を行う場合：汎用ワーカー、または SQL や CI など、その分野の専門家がワーカーロスターに記載されていれば専門家を使います。
• 別のワーカーの成果を検証する場合：成果物を作成したワーカーとは別のワーカーを使います。ハーネスがサポートする場合は読み取り専用で行います。
• フォーク（この会話を引き継ぐワーカー）を使うのは、その履歴が作業に必要な場合に限ります。その場合も、タスク、担当パス、成果物の返却条件を指定します。

ユーザーまたは利用スキルから指定がない限り、モデルと推論の労力は未設定のままにします。スクリプト化されたマルチエージェントワークフローツールが公開され、その利用条件を満たす場合は、多数の項目に同じ確認を行うような幅広く均一な並列処理に利用します。各ステップが前のステップに依存する場合は、直接委任します。

作業量の見積もり

• 確認作業は、委任一回です。
• 比較、または二つの領域にまたがる変更は、並列で二〜四回委任します。
• 機能規模の作業は、依存関係の段階ごとに一つずつ、複数の波に分けて実施します。

関連する複数の作業は同じ領域の一人のワーカーにまとめ、別の領域の作業は並列に実行します。実行中のワーカーは、入れ子になったものも含めて最大四人までにします。ただし、ハーネスに関する注意に、この環境ではより多く使えると記載されている場合はその限りではありません。上限を超えた起動はキューに入らず失敗します。完了を待ってから、次を起動してください。委任はフラットな構成に保ち、サブツリーに独自の調整役を置く前に入れ子構造を読んでください。

ワークフロー

1. 計画します。 ユーザーが依頼した内容の範囲に絞り、領域ごとに依頼を分割します。 その範囲外で見つかった問題はユーザーに報告し、計画には含めません。 すべてのワーカーが書き込める絶対パスの実行ディレクトリを、リポジトリの外に 1 つ選びます（利用可能な場合はセッションのスクラッチパッドを使用します）。計画は 計画ツールに記録するか、返信に番号付きリストとして記載し、計画を繰り返すのではなく 変更点を報告します。すべての依頼にタスク、担当するパス、完了条件があり、実行 ディレクトリが指定されていれば完了です。
2. 依頼を割り当てます。 独立した依頼は、完全な 引き継ぎ情報を添えて、1 つのメッセージでまとめて開始します。現在の ウェーブのすべての依頼が実行中になれば完了です。
3. 結果を集めます。 完了通知または待機ツールで結果を待ちます。ワーカーを再開する ときは、調査を最初からやり直させず、具体的な不足箇所を伝えます。再試行が同じ方法で 失敗した場合は、原因を診断するか、アプローチを変更します。1 つの依頼で 3 回失敗した 場合は、ブロック中として報告します。依存関係がユーザーの返答待ちの間も、独立した 作業を進めます。ウェーブ内のすべてのワーカーから結果が返るか、ブロック中と報告 されれば完了です。
4. 統合します。 小規模な編集は 1 人のライターが担当します。同じチェックアウトまたは 外部リソースを共有するライターは、順番に作業します。並行してコードを変更する ライターには、それぞれ固定したベース SHA から作成したワークツリーとブランチを 割り当て、統合担当者がマージします。ワークツリーを作成する前に、 並行書き込みを読みます。受け入れた 作業がすべて 1 つのツリーにまとまり、並行作業の場合は各ブランチと HEAD SHA が記録 されれば完了です。
5. 検証します。 各ライターが自身の差分をレビューし、変更を対象とするチェックを 実行します。マージ後の並行作業、スキーマやデータの変更、アーキテクチャの変更、 または箇所ごとに異なる判断が必要な複数ファイルの変更では、別の検証担当者を割り 当てます。検証担当者が問題を報告し、ライターが修正した後、検証担当者が再確認 します。ネストされた実行では、子タスク間の接続部分を検証し、各子タスクが担当した 範囲についてはその検証結果を再利用します。すべての変更について、検証担当者の合格 判定、または小規模な編集の場合はライターの差分とチェック結果が得られれば完了です。
6. 報告します。 まず結果を示し、その後に成果物のパスまたは ID、検証結果、未解決の 制約を、ユーザーが対応するのに必要な長さで伝えます。依頼が質問だった場合は、回答が 成果物です。実行ディレクトリはセッション終了時に消えるため、再利用する価値のある 調査結果が得られた場合は、ワーカーにリポジトリの docs/research/（またはプロジェクト 相当のディレクトリ）へ保存させ、そのパスを報告します。実行で作成した PR がマージ されたら、 クリーンアップまたは、インストール されている場合は cleanup-merged-branches などのブランチクリーンアップスキルに従って、 ワークツリーとブランチを削除するか提案します。依頼された作業が完了するか、許可された 作業を続けられない具体的なブロッカーが生じれば完了です。

引き継ぎ

ワーカーには、割り当てプロンプトと、ハーネスが読み込むプロジェクトの指示（CLAUDE.md や AGENTS.md など）が表示されます。この会話、以前の報告、ほかのワーカーが読んだファイルは確認できず、ユーザーに質問することもできません。引き継ぎには、必要な情報をすべて含めてください。

• タスク：完了条件、担当するパスまたはリソース、すでに付与されている権限を記載します。
• 目標：実装タスクと検証タスクについて、作業が重要である理由を記載します。
• これまでの決定事項：決定した内容とその理由、推測せずに確認事項として挙げるべき未解決の質問を記載します。
• これまでの調査結果：返却された要約から、一字一句そのまま引用します。このタスクに必要な部分を貼り付け、省略した内容も明記します。長い成果物の場合は、パスと読むべき行またはセクションを示します。秘密情報や個人データは伏せてください。
• 実行ディレクトリ：存在しない場合は作成するパスと、パスを指定して読み込むスキルを記載します。
• 返却形式：status、files_changed、tests_run、verification_evidence、decisions_made、open_questions、artifact_path などのフィールドを指定します。

ワーカーは、大量の調査結果やコマンド出力を実行ディレクトリ内の成果物に書き込み、各成果物の項目につきインデックス行を1行含む短い要約を返します。最初の引き継ぎの後は、決定事項の一覧を引き継ぎのたびに記載し、そのタスクに関係する内容に絞り込みます。ユーザーへの質問は open_questions に記載し、独立して進められる作業は続行します。

構成

利用するスキルによって、タスクの内容に応じてこれらのルールがさらに厳しくなる場合があります（たとえば、チケット1件だけでも作業ツリー内に隔離する場合など）。また、ルールに明記されていれば、これらを置き換える場合もあります（たとえば、変更を一切行っていない統合ワーカーを検証担当にできる場合など）。特に記載がない場合は、このスキルのルールを適用します。