9uiLe モデル・コンテキスト・委譲の実行方針
必要な品質を満たしながら、タスク完了までにメインと委譲先が処理する入力・出力を抑える。モデル単価に加え、会話履歴の反復処理、依頼と回答の往復、エージェントの起動と結果統合を考慮する。
メインはユーザーへの応答と成果物の受け入れを担う。実装担当は範囲を定めた作業を行い、アドバイザーは判断材料を返す。アドバイザーの回答を採用する責任はメインにある。
1. 依頼条件を確認する
ユーザーが指定したモデル・effort・アドバイザー利用を優先し、未指定の部分を選ぶ。指定された機能が利用できなければ制約を説明し、別のモデルや実行環境へ無断で置き換えない。
セッション冒頭または方針変更時にこのスキルを使い、同じ方針が続く間は再実行しない。外部への書き込みなどは、会話内の承認と実行環境の権限に従う。
2. 会話を作業単位で管理する
- 開始時の入力が大きい場合は、ツール・常駐指示・メモリの内訳を確認する。作業中に増えた場合は、読み込んだファイル・ログ・過去の議論が次の判断にも必要かを確認する
- 作業の区切りで目的・決定事項・対象ファイル・検証結果・残作業を短く保存する。不要な履歴を切り離すなら新規セッション、継続性を保って履歴を縮めるなら compact を選ぶ。実行環境で利用可能な機能を使い、圧縮と再構築の負担も考慮する
- 読み取りは対象範囲を絞り、結果は結論・証拠の場所・失敗箇所を中心に返す。定型コマンドは同じ目的の処理をまとめ、生ログや巨大な差分を会話へ持ち込まない
詳細な切り分けと計測は references/03-cost-levers.md、大規模リポジトリの探索は references/04-large-codebase.md を必要時に読む。
3. 担当とモデルを選ぶ
次の表は担当候補を選ぶためのもの。指定のない追加委譲は、作業が独立し、目的・対象範囲・受け入れ条件を一度に渡せて、起動・文脈複製・結果統合を含めても直接実行より有利な場合に行う。
| 区分 | 作業 | 担当候補 |
|---|---|---|
| P0 | 外部への書き込み、破壊的操作、履歴改変 | 承認済みの範囲と実行権限を確認 |
| R0 | 既知ファイルの短い読み取り、単発の状態確認 | メインで直接実行 |
| R1/R2 | 複数ファイルの探索、広域抽出、独立した検証 | 範囲を定めた探索・検証担当 |
| R3 | 対象・期待結果・変更範囲・検証方法が確定した実装 | 実装担当 |
| R4 | 設計、曖昧さの解消、デバッグ、レビューの統合 | メイン。指定されたアドバイザーの根拠も検証して判断 |
Claude Code では探索・検証に haiku-scout、仕様が確定した実装に sonnet-implementer を利用できる。Codex では利用可能なモデルと委譲機能に合わせる。コスト削減目的の委譲ではモデルを明示し、親会話を継承する fork の文脈複製も見積もる。短い操作ごとに起動せず、並列化は独立作業の所要時間短縮に価値がある場合に選ぶ。
モデル・effort が未指定なら、既知手順や定型実装は Sonnet 級、複雑な判断はより高性能なモデルを候補にする。必要な推論量に合わせて effort を選び、能力不足や手戻りの証拠に応じて引き上げる。Fable や最大 effort の起動自体を品質保証とみなさない。
厳密な分類・git 操作・実装依頼の条件は references/02-decision-matrix.md、価格と effort の根拠は references/00-pricing.md と references/01-effort-levels.md、Codex 固有の対応は references/07-codex.md を必要時に読む。
4. 依頼と受け入れをまとめる
実装・探索の依頼には目的、対象、変更可能範囲、受け入れ条件、検証方法を渡す。回答は結果、検証の根拠、未完了事項に絞る。追加依頼は不足情報を整理し、対象の差分をまとめて渡す。
アドバイザーには重要な設計判断・リスク・見落としの検証を依頼する。
- 目的・制約・検討案・具体的な質問・必要なファイルや差分を渡し、調査範囲を定める。回答は重要な指摘・根拠・推奨案・未解決事項に絞る
- メインが事実や検証結果と照合する。新しい証拠、重大な未解決点、結論に影響する変更がある場合に限り、同じ相手へ差分をまとめて再相談する
- 合意の有無ではなく、受け入れ条件と根拠で採否を決める。同じ論点で新しい根拠が出なくなったら往復を終え、理由と残るリスクを記録する。受け入れ条件を満たせない点は未解決として扱う
Orca を使う場合、このスキルが相談範囲と判断基準を定め、公式 orchestration の現行ガイドがエージェントの起動・待機・完了処理を定める。Orca のコマンドやフラグは現行ガイドで確認する。利用者向けの依頼例は README.md にある。
5. 完了または状態変化を待つ
完了通知や runtime の wait / monitor を利用し、待機中は結果に依存しない作業を進める。sleep の完了通知・端末読込・状態確認だけでモデルを繰り返し呼び出さない。
通知を受けられない場合は、実行環境が対応する期限付きの待機処理にまとめる。タイムアウトは完了や失敗の証拠ではない。必要な状態診断を行い、復旧できなければ取得できていない結果と作業への影響を明記する。
権限拒否・存在しないツール・引数の誤りは、同じ条件で再試行しない。原因を直した場合だけ再試行し、同じ失敗が残れば未解決として報告する。
6. 方針と結果を報告する
推奨だけを求められた場合は、次の形式で短く答える。
推奨: <メインモデル / effort / 必要な委譲先>
理由: <品質・コンテキスト量・往復回数の判断根拠>
区切り: <会話を継続・圧縮・分離する条件>
実行も求められた場合は方針を開始時に一度共有し、作業を進める。完了時は成果物と検証結果に加え、重要な指摘の採否・理由・未解決事項を報告する。利用量を計測する場合は通常入力・キャッシュ作成・キャッシュ読み取り・出力を区別し、総 token 数を料金や利用枠に換算しない。
任意の監査
ユーザーが監査可能なルーティング、独立判定、conductor mode を求めた場合に references/08-conductor-mode.md を読み、割当マニフェスト、変更範囲の基準線、scripts/route-policy.mjs audit を使う。judge / judge-fable は高保証モードで独立判定を担う。通常のアドバイザー相談だけではこのモードを有効にしない。
資料の場所
PLUGIN_ROOT は Claude Code では ${CLAUDE_PLUGIN_ROOT}、Codex ではこのスキルのディレクトリから2階層上にある model-strategy ディレクトリ。本文中の README.md、references/、scripts/ はこのルートからの相対パス。