Delegate（委譲） は何をしますか？
オーケストレーターのコンテキストは、セッション全体を通じて持続する唯一のウィンドウです。オーケストレーターが読み取るすべてのファイルと保持するすべてのコマンド出力は、判断リソースの消費となります。サブエージェントはタスクごとに新しいウィンドウを取得するため、オーケストレーターはルーティング、完了条件の定義、判断を行い、エージェントは読み取り、実行、書き込みを行います。
二つの役割
すべての派遣プロンプトは、Your ROLE_TYPE is sub-agent. で始まります。この行は再帰防止マーカーです。このスキルを継承したサブエージェントは、これ以上タスクを展開してはいけません。プロンプトがこのように始まった場合は、ここで処理を停止し、references/sub-agent-contract.md に従ってください。そうでなければ、あなたは委譲者であり、このファイルの残りの部分が適用されます。
適用条件
ファイルを変更する、原因を調査する、事実を収集する、バグを修正する、作業をレビューするリクエスト — 規模を問わず — および、自分自身でソースを読んだり診断を実行したりしようとしている瞬間（それを委譲せずに）。「たった二行だけ」という場合も委譲対象です。唯一の例外は、このターンで自分自身が編集した単一ファイルに限定されたチェックです。
また、作業が進行中の場合も適用されます：サブエージェントのレポートの審査（「審査」を参照）、フェーズの再派遣、ユーザーが指定したパターンインスタンスの一般化（「パターン拡張」を参照）。
答えがすでにコンテキスト内にあり、ファイル変更が不要な場合は、インラインで回答してください。
分解
リクエストをフェーズに分割します。成果を生むフェーズのみを保持し、決して水増ししてはいけません。
| フェーズ | 成果物 |
|---|---|
| read（読み取り） | 作業の依存する資料を特定し、読み取る |
| gather（収集） | 外部の事実：ドキュメント、先行事例、現在のシステム状態 |
| process（処理） | 分析と選択したアプローチ |
| verify（検証） | 実際のコードと環境に対してアプローチをチェック |
| write（書き込み） | 変更 |
| validate（検証） | リント、型チェック、ビルド結果 |
| test（テスト） | テストの実行、および変更をカバーする新しいテスト |
| report（報告） | 変更内容とその証拠 |
| review（レビュー） | 結果に対する独立した批評 |
いくつかのパターンは繰り返し発生し、それぞれに専用の取り扱いがあります：
- バグ修正 → references/fix-cycle.md：変更前に再現する。
- 多数のターゲットに対する同一の編集 → 1回の
process派遣で変更を決定し、N回の汎用派遣で適用し、1回のreview派遣でチェックします。parallel-work（並列作業） を参照。
派遣
- 1回の派遣につき1フェーズ。フェーズはN個のターゲットに展開できます（N回の派遣、同じフェーズ）。他のフェーズと混在させてはいけません。
- 独立した派遣は、同時に実行できるように1ターンでまとめて送信します。直列化が必要なのは、一方が他方の結果を消費する場合、または隔離なしに同じファイルに書き込む場合のみです。
read/gather/processの結果は、あなたのコンテキストではなくファイルに出力します。パスを次のフェーズに渡し、内容を転送してはいけません。
エージェントの選択
タスクがエージェントに求めるものに基づいて分類し、名前では分類しません：
- スペシャリスト — フェーズのドメインに説明が一致するエージェント。観察事項、成功基準、コンテキストを渡します。実装手順は決して渡しません。
- 汎用 —
general-purpose（またはハーネス相当）とExplore。規定された実装（正確な編集、正確なファイル、正確な検証）を渡します。Exploreは完全一致検索のみに使用します。 - レビューア —
reviewフェーズ用。書き込みを行ったエージェントとは異なるエージェントで、ドメインに対してレビューアまたは監査役タイプのエージェントを優先します。
適切なスペシャリストがいない場合は、規定されたタスクを指定して汎用エージェントを派遣します。
両方のプロンプトは同じ2行で始まります — 以下のテンプレートの最初の行にそのままコピーします：Your ROLE_TYPE is sub-agent. Follow the sub-agent contract at <absolute path to references/sub-agent-contract.md>.
プロンプト — スペシャリストモード
PHASE: <フェーズ名のいずれか>
TASK: <一文>
OBSERVATIONS（観察事項）:
- <コンテキスト内に既にある事実：ユーザーの発言、以前のSTATUSレポート、エラーの原文、既知のfile:line>
DEFINITION OF SUCCESS（成功の定義）:
- <測定可能な成果>
- <受理条件>
- <検証方法 — コマンドと期待される結果、またはチェックするレビューア>
DELIVERY（納品）:
- 1行を超えるものはすべて .tmp/scratch/reports/<YYYYMMDD>-<slug>.md に書き込み、パスを返却する。
CONTEXT（コンテキスト）:
- Location（場所）: <どこを探すか>
- Scope（範囲）: <境界>
- Constraints（制約）: <ユーザーが要求した要件；従うべき既存のパターン>
- Commands（コマンド）: <プロジェクトの検証/テストの品質ゲート、または「このプロジェクトが定義するものを発見する」>
ECOSYSTEM CONTEXT（エコシステムコンテキスト）: （セクションが空の場合は省略）
- <エージェントがどこからも読み取れないセッションの事実：認証済みCLI、レビュー中のPR、同じファイルで稼働中の別エージェント>
YOUR TASK（あなたのタスク）:
<下の表のフェーズに対応する行をそのまま>
YOUR TASK のフェーズ行：
| フェーズ | 行 |
|---|---|
| read | この作業が依存する資料を特定し、読み取る。正確なパスと引用内容を納品ファイルに書き込む。後続のフェーズで必要となる詳細を要約して省略しない。何も編集しない。 |
| gather | CONTEXTで指定された外部の事実を収集する。それぞれを出典とともに納品ファイルに記録する。何も編集しない。 |
| process | OBSERVATIONSのパスにある資料を分析する。アプローチを選択し、その理由と代替案を却下した理由を記録する。何も編集しない。 |
| verify | 選択したアプローチを、CONTEXTの実際のコードと環境に対してチェックする。成立する箇所と失敗する箇所を記録する。何も実装しない。 |
| write | DEFINITION OF SUCCESSに従って変更を行う。CONTEXT Scope内のファイルのみに触れる。 |
| validate | CONTEXT Commandsのコマンドを実行するか、このプロジェクトのリント/型/ビルドゲートを発見し、実行したものを明記する。正確な出力（成功と失敗）を報告する。沈黙した失敗は失敗である。 |
| test | CONTEXT Commandsのテスト呼び出しを実行するか、それを発見し、実行したものを明記する。変更をカバーするテストを追加する。正確な出力を報告する。 |
| report | 何が変更されたか、およびその証拠（ファイル、コマンド、出力）を述べる。証拠が裏付けない主張は行わない。 |
| review | OBSERVATIONSのパスにある結果を、DEFINITION OF SUCCESSに照らして批評する。ギャップ、矛盾、根拠のない主張を報告する。修正は行わない。 |
記入ルール：
- 既にコンテキスト内にある情報で埋められないセクションは、省略します。創作してはいけません。空のOBSERVATIONSやECOSYSTEM CONTEXTは有効な状態です。推測は無効です。
- OBSERVATIONSはパススルーです：すでにコンテキスト内にあるもののみ。埋めるために読み取り、grep、コマンド実行を行うことは事前収集に当たります。エージェントは新しいウィンドウでそれを行います。
- 観察事項は事実として記述します（「終了コード1」、「エラーテキストは：…」）。仮説を保持している場合は、ラベルを付けます：
検証すべき仮説：…。 - 制約（Constraints）は成果と境界であり、手順ではありません。Commandsにプロジェクト独自のゲートを指定することは制約であり、手順ではありません。
- エージェントが継承するもの（リポジトリ規約、ツールチェーン、「自由に探索」、「利用可能なスキルを使用」）については何も言及しないでください。これらはプロジェクトのエージェント指示に存在します。スキルを指定するのは、エージェントがそれを読み込む必要があり、かつ自力では読み込まない場合のみです。
- パス：エージェントが自身の作業ディレクトリから解決できるように記述します。リポジトリ内では相対パス、シンボリックリンクを通るものについては（解決先ではなく）リンク形式を使用します。
プロンプト — 汎用モード
PHASE: <write | validate | test | read>
TASK: <正確な指示 — 行う編集、見つけるパターン、実行するコマンド>
FILES（ファイル）:
- <正確なパス>
DEFINITION OF SUCCESS（成功の定義）:
- <検証コマンドと期待される結果>
DELIVERY（納品）:
- 検証出力をレポートに含めること。
審査
レポートは主張です。それぞれについて：
- 証拠が結論を裏付けていることを確認します。「テスト合格」という言葉だけでコマンド出力がないのは証拠ではありません。出力を取得するために再派遣します。
- 返された作業を判断します。それを再導出してはいけません。エージェントが読んだものを再読することは、委譲によって節約したコンテキストを消費します。
- 2つのレポートが矛盾する場合 → 反証可能な主張を見つけ、それをチェックするために派遣します。確信度はタイブレーカーになりません。
PARTIAL→ 残りの部分を正確に指定して再派遣します。BLOCKED（不足する入力による）→ それを提供して再派遣します。複数回試行した後のBLOCKED→ アプローチを変更するか、ユーザーにエスカレーションします。同じプロンプトを再送してはいけません。
同じギャップに対して、同じフェーズの再派遣は最大2回まで。その後は停止し、ギャップを明記して BLOCKED をユーザーに報告します。
コードを変更するすべてのリクエストは、書き手とは異なるレビューアによる独立したレビューを受けます。
パターン拡張
ユーザーが特定の悪臭、バグ、または欠落したチェックのインスタンスを指し示す場合、それはパターンを指定していることになります。「これだけ」と明示しない限り：パターンについてファイルまたはモジュール全体の監査を派遣し、見つかったインスタンスを報告し、指定されたファイルを超える修正の前にユーザーと確認します。
参照
- references/sub-agent-contract.md — 派遣されたエージェントが従う契約。
- references/fix-cycle.md — バグ修正派遣のための「まず再現」サイクル。
- parallel-work — ファンアウト、ファンイン、メーカー/チェッカー、トーナメント、上限付きループ；Claude Codeハーネスの仕組みも含む。
orchestrator-disciplineがインストールされている場合：オーケストレーターが読み取り/実行可能なもの。フックによって強制。process-sirenがインストールされている場合：評価可能なMermaidのひし形図として決定点を記述する。