オートルーター

すべての実行可能なリクエストを分類してから実行を開始します。結果を正しく達成できる最もシンプルなワークフローにルーティングします。

存在する理由

コンテキストは最も高価なリソースです。エージェントの起動、ファイルの読み取り、パイプラインの実行を些細なタスクに費やすことはトークンと時間を浪費します。逆に、横断的なリファクタリングを単一スレッドの編集として処理すると、リスクが生じます。ルーターはこの両方の問題を排除します。

分類体系

クラス A -- 直接応答

リクエストが説明、意見、または単一概念の回答を求めています。

シグナル:

• 疑問詞に動作動詞がない (what, why, how does, explain)
• 変更する必要のあるファイルがない
• 実装の意図がない15語以下

アクション: 直接答えます。スキルは使いません。回答に必要な範囲を超えてファイルを読み取りません。

クラス B -- 単一エージェント実行

リクエストが1つの関心事にスコープされたコード変更を必要とします。

シグナル:

• 1つのバグ修正、1つの機能、1つのファイルまたは密結合されたモジュール
• fix、add、update、rename などの動詞が1つの領域を対象としている
• モジュール間の影響がない

アクション: 直接実行するか、計画のみのために task-decomposer を呼び出します(並列処理なし)。Glob/Grep/Read(offset,limit) を使用してコンテキストを収集します。変更を順序立てて適用します。

クラス C -- マルチエージェント調整

リクエストが複数の独立した関心事にまたがり、分離できます。

シグナル:

• "and" またはカンマで結合された複合リクエストで異なるデリバラブルがある
• refactor、implement、migrate、across、parallel などの動詞
• 2つ以上のモジュールで分離可能な書き込み領域がある
• 並列実行の明示的なユーザーリクエスト

アクション: 完全なパイプライン -- task-decomposer -> conflict-detector -> parallel-orchestrator -> ワーカー -> merge-coordinator

クラス D -- 直列複雑実行

リクエストが横断的ですが、安全に並列化できません。

シグナル:

• 共有抽象化を再構成するアーキテクチャ変更
• 順序を保って実行する必要のある移行シーケンス
• 多くのファイルに影響を与える単一アルゴリズムの書き直し
• すべてのデリバラブル間に高い結合度がある

アクション: task-decomposer -> conflict-detector (直列化の判定を予想) -> 各ステップ間での検証を含む直列実行 -> merge-coordinator

分類出力

続行する前に必ず出力します:

Classification: [A|B|C|D]
Reasoning: [理由を1行で説明]
Route: [direct | single-agent | parallel-orchestrate | serial-orchestrate]

ルーティング規則

1. リクエストを処理できる最も低いクラスに対してデフォルト設定します。過度なオーケストレーションは過度なオーケストレーションより多くのトークンを浪費します。
2. B と C で迷った場合は B を選択します。並列処理はオーバーヘッドがあります。メリットが明確な場合のみ使用します。
3. ユーザーが明示的に並列実行を要求した場合、あなたの判定に関係なく C にアップグレードします。
4. 分類をスキップしないでください。「明らかな」タスクであっても、3行の出力からは監査証跡が作成されます。

トークン効率(すべてのクラスに適用)

ファイルを読み取る前に:

1. Glob を使用して候補ファイルを検索します。
2. Grep を使用して関連セクションに絞り込みます。
3. Read (offset と limit 付き) を使用して必要なもののみを取得します。

ファイルが100行未満またはユーザーが明示的に要求した場合を除き、完全なファイルを読み取らないでください。完全なファイルよりもdiffを、生のログよりも要約を、コンテンツよりも構造を優先します。

コンテキストを収集した後: 学習したことを要約し、作業メモリから生のデータを破棄します。各主要フェーズの後またはコンテキストが重く感じられるときに /compact を使用します。

モデル階層ガイダンス

• Haiku: 探索、ファイル発見、シンプルな編集、ドキュメント
• Sonnet: 実装、テスト作成、中程度のリファクタリング
• Opus: アーキテクチャ決定、複雑なアルゴリズム、横断的な設計

サブエージェントを起動する場合、タスクを処理できる最も軽いモデルを割り当てます。

ハンドオフ

• クラス A: すぐに応答します。
• クラス B: 実装に進みます(オプションで計画のため task-decomposer 経由)。
• クラス C: 完全なリクエストコンテキストで task-decomposer を呼び出します。
• クラス D: 直列実行が予想されることをメモして task-decomposer を呼び出します。完全なパイプラインは引き続き適用されます(分解 -> 競合検出 -> セーフモードでオーケストレーション -> マージ)ですが、オーケストレーターは検証ゲートを使用してワークストリームを順序立てて実行します。