--- name: delegation description: > 高度な委譲の経路選択、継続、停滞検知又は複数主体調整が必要な場合に起動し、実行経路固有の契約を提供する。 user-invocable: false --- # 委譲 本スキルは、高度な委譲の経路選択、継続、停滞検知及び複数主体調整の手順を提供する。 基本的な委譲は`agent-toolkit/rules/02-agent-operations.md`「基本委譲契約」節を適用し、 本スキルは高度な経路固有の契約を定める。受信者が行う用途固有の作業は 受信者用のタスク文書またはagent定義を正本とする。 委譲先とモデルを選ぶ時点では`agent-toolkit/skills/delegation/references/runtime-routing.md`を全文読み、同文書の経路選択とモデル区分を適用する。 Claude Code固有経路を確定する時は`agent-toolkit/skills/delegation/references/claude-code-runtime.md`を全文読む。 完了通知及び待機・停滞を確定する時は`agent-toolkit/skills/delegation/references/waiting-and-monitoring.md`を全文読む。 計画実装の受領契約を確定する時は`agent-toolkit/skills/plan-mode/references/plan-impl-caller-reception.md`を全文読む。 ## 送信 起動文は呼び出し元と委譲先の双方のコンテキストを消費するため、 受信者が作業を成立させるために必要な最小限へ縮める（努力目標）。 1. 委譲する独立した作業、読取専用か書込可能か、完了条件、受領経路を確定する 同一の母集団を複数の委譲先へ分割する場合は、起動前に母集団の全要素と担当の対応表を作成する。 未割当と重複が0件であることを集合演算で確認する。 分割単位が母集団の要素と一致しない場合（主題単位の分割など）は、要素単位の対応を担当決定の正本とする。 独立コンテキストのレビューのように同じ対象を複数系統で意図的に確認する作業は、重複の判定対象に含めない。 2. 実行環境、model、worktreeの経路固有判断が必要な場合だけ、 起動直前に`references/runtime-routing.md`を全文読む。 Claude Codeで起動する場合は`references/claude-code-runtime.md`も併せて全文読む 3. 起動文の先頭で受信者への命令を1文で示す。続けて必要な正本の絶対パスと対象ID、 および正本に記録されていない次の値だけを渡す - 作業ディレクトリ、対象、読取・書込権限、不可逆操作権限 - 実行時に確定した事実、今回限りの例外、追加指示、正本記録後に生じた差分 起動文の命令は、受信者のタスク文書、agent定義及び適用スキルが定める手順の範囲を狭めない。 対象、権限および完了条件を示す語だけを使い、受信者が行う判断工程を除く語（最小修正、指摘どおり、そのまま反映など）を書かない。 受信者が適用する規範スキルが作業手順の正本となる委譲では、当該スキル名を起動文の必須入力へ含める。 指摘、改善提案又はレビュー結果の修正を委譲する場合は、`agent-toolkit:reviewee-standards`を当該必須入力へ含める。 委譲先へ渡す値は呼び先が判断に用いる外部可視の入力に限り、呼び出し側CLIが内部導出する派生パスを含めない。 4. ファイルの役割と対象IDで参照内容が一意に定まる場合は、内容の要約を起動文へ加えない。 タスク文書の手順、品質規範本文、出力書式、過去応答に加え、 正本内の合意事項、調査済み事実、完了条件も複製しない 5. 参照可能な正本がない情報は、相対参照（「上記」「前述」等）を使わず起動文内で完結させる。 委譲先だけが使う参照資料は起動直後に読ませる 起動文の命令は委譲元が構成した情報として扱う。 人間のユーザーによる逐語引用を渡す場合だけ、出所、引用範囲、ユーザー合意又は参考素材の別を明示する。 出所表示のない起動文を人間のユーザーによる発話として扱わない。 作業ディレクトリは受領済みの絶対パスをそのまま渡す。受信者に自己解決させない。 `agents_server`の`start`では`engine`、`prompt`及び`cwd`へ値を渡す。`engine`は`codex`または`claude`とし、`cwd`には作業ディレクトリの絶対パスを必ず渡す（未指定・相対パスの呼び出しは成立しない）。`model`と`effort`は両方指定するか、両方省略する。 `wait(session_id, timeout)`は状態を観測し、終端時は同じ応答で結果本文を返す。通常の既定は240秒であり、固有のtimeout要件がなければ引数を省略して通常既定を使う。`timeout=0`は待機せず現状態を返し、終端結果の再取得も同じ本文を返す。 同じ担当へ追加指示を送る場合は`send_message(session_id, prompt)`を使う。実行中turnにはsteerし、終端済みturnでは結果回収の有無にかかわらず同じsessionでreplyを開始する。 `send_message`の応答は`delivery`で配送結果を示し、reply開始時は直前結果を`previous_result`へ含める。`wait`と`send_message`のいずれにも、結果回収済みの状態にする前提条件は設けない。 同じsessionの実行中turnを明示的に中断する場合は`kill(session_id, timeout)`を使う。killの通常の既定は300秒である。`timeout=0`は中断要求の安全な配送だけを待って現状態を返し、正のtimeoutは中断後の終端と結果を待つ。timeout超過時もsessionとbackend processを破棄せず、保持されたsessionへ`wait`で状態を確認し、終端後は`send_message`を続けられる。 作業用複製では、複製元と対象外worktreeも明示する。 ### 権限と成果物の取り決め - 成果物ファイルを生成・更新する委譲では書き込み主体を明示する。 委譲先が書き込む場合、委譲元は完了報告の受領まで当該ファイルを読み取り専用として扱う。 委譲元が書き込む場合は委譲先へ読み取り専用である旨を伝える - ファイルを生成・更新する委譲では、成果物の絶対パスと実在・分量を示すコマンド （`ls -l <パス>`・`wc -l <パス>`等）の実行結果を完了報告へ含めるよう求める - 行、表、リストなどの構造化された成果物も、指定された絶対パスへ直接書き込む。委譲先は完了時に 集計値、成果物の絶対パス、`wc`等による分量及び内容要約を返す。委譲元は返却された成果物を 新しい本文へ転記せず、必要な場合だけ指定パス間で`cp`又は`mv`を実行する - 委譲範囲を超える不可逆操作の返却は`agent-toolkit/rules/02-agent-operations.md`「委譲時の厳守事項」節が定める。 委譲元がフィードバック投入を明示的に指示した場合だけ、委譲先は当該指示の範囲で投入してよい （フィードバック処理スキルが分類の委譲先へ確認事項の記録を求める場合などを含む） - 対応方針の選択・推奨を求める調査、及び実装上の制約・必須条件を返す調査では、対象リポジトリの明文化された方針文書と対象機能の外部仕様文書の該当節（絶対パス）を委譲先へ読ませ、推奨案・制約と当該文書の整合判定を報告させる。 文書と衝突する案・制約を返す場合は衝突箇所を明示させる - 点検・調査では、各指摘の裏付けに用いた手段を報告させる。指摘に必要な裏付けを取得できない場合は、証拠不足の範囲と必要な検証を返して完了しないよう求める - 複数の委譲先についてツール、権限、モデル又はホスト能力を比較・分類する場合は、全ての対象へ同一の機械照会を同じ条件で実行し、同じ項目を取得する。 対象ごとに照会方法や条件を揃えられない場合は、比較結果を未検証として返す。 委譲先自身の申告だけで能力の不在や差異を確定しない。 これは能力を比較する工程だけに適用し、単一対象の通常のstatus確認、常時収集、hook・状態保存を要求しない ### 未検証情報の取り扱い `未検証`は、自ら裏付けを取っていない具体値・挙動・制約に付すラベルとする。本節を定義の正本とする。 - 委譲先が着手時に読む成果物（委譲プロンプト・計画ファイルなど）へ、自ら確認していない具体値や 既存実装の挙動・制約に関する主張を書く場合は`未検証`と明記し、委譲先へ着手前の裏取りを指示する。 行番号などの位置指定値は転記せず、見出し・識別子など編集の影響を受けにくい参照で位置を指定する（努力目標） - 委譲した調査の完了報告を受領する前に、原因をユーザーへ確定的に報告しない。 自ら得た手掛かりは推定である旨を明示する - 委譲先が実行する手順として外部コマンド・ツールを記述する場合は、記述前にヘルプ出力・公式リファレンス・ ツールスキーマ（`ToolSearch`での照会を含む）で受理パラメーター・既定挙動・相互制約を確認する（努力目標） ### 判断材料と一時領域 - エージェントの作業用一時領域は、実行環境向けに配布されたagent-toolkitの管理CLIで作成する。 標準出力の絶対パスを再生成せず保持し、用途の完了と内容の検収後だけ同じ管理CLIで後始末する。 汎用の一時ディレクトリ作成コマンドと直接削除コマンドは使わず、 管理CLIで作成していない既存領域を自動で後始末しない - 管理対象一時領域へユーザーの認証情報ファイルを配置しない。 Claude Codeの組み込み`Read`に対する拒否設定はBash経由の複製を遮断しないため、 機械的な拒否だけを認証情報の再配置防止として扱わない - 認証を要するClaude Code検証では`CLAUDE_CONFIG_DIR`を変更せず、既定の認証解決経路を維持する。 `--settings `は既存設定への追加読込として扱い、設定ソースを隔離した結果とは扱わない - 設定の反映は`claude auto-mode config`で確認する。 配布元がある場合は、配布元が所有する契約を既存の対象固有テストで確認する。 `claude auto-mode critique`は変更前後の指摘を安定して対応付けられる場合だけ新規・悪化差分を評価し、 対応付けられない場合は参考情報として扱う - 判断材料が2万文字（目安。受信側の初期コンテキストを圧迫しない分量とする）を超える場合は 当該一時領域へ所有者だけが読み書きできるMarkdownとして保存する。 ファイルの役割と対象IDで内容が一意に定まる場合、プロンプトへは絶対パスと対象IDだけを渡す。 一意に定まらない場合は、絶対パスと判断に必要な範囲の要約を渡す。 委譲先は着手時にファイルを読み込む - 委譲元・委譲先のいずれが生成する場合も、作業目的のファイル（退避・比較・中間出力）は分量によらず 対象リポジトリの作業ツリー外へ置く。作業ツリー内へ置くと当該セッションの成果物と混在して 差分の切り分けを要し、削除漏れがそのままコミット対象へ入る ## 継続と新規起動 Codexの初回起動（元担当不在を実測確認した初回生成前失敗からの代替起動を含む）は工程別モデル設定の通常起動契約に従う。 元担当の回復、置換、再起動、代替起動又は役割引継ぎには、`runtime-routing.md`「Codex後続操作の共通先行条件」を先行して適用する。 - 同じ作業と判断履歴を継続し、計画、進捗ログ、保存済みのレビュー表のいずれかが状態の正本となる場合は、 同じrouteと識別子へ正本の絶対パス、対象ID、正本に未記録の差分だけを送る - 参照可能な状態の正本がない場合は、未完了事項と検収済み状態を起動文内で完結させる。 レビュー表の保存先がない場合は、呼び出し元が管理対象領域へ表を作成してから継続する。 表の内容を起動文へ埋め込む経路は採用しない - `feedbacks-planner`が`awaiting_confirmation`を返した場合は、呼び出し元が確認回答又は保存済みTBDを受領した後、 停止済みの識別子へ継続せず、同じ`feedbacks-planner`系列（同じバッチと計画）の新しい識別子を起動する。 初回起動には再開コンテキストを含めない。 確認待ち後の再開起動だけへ元のバッチ全項目の調査結果全文を渡す。 原文frontmatterの`source`原値（欠落は値なし）、`decision`を含むIDごとの累積`user_decisions`、出所と引用範囲付きの逐語回答・保存TBD、 初回起動と同じ計画ファイルの絶対パスも全て渡す。 元の調査結果を再調査せず要約もしない。 回答とTBDを対応する採否記録へ統合し、確定済みの`decision`を再判断せず計画担当へ渡す - 独立したレビュー系統、異なる観点、先行履歴に依存しない評価は新しい識別子で起動する - 追送する要件が未確定の場合は、委譲元がユーザーへ確認して要件を確定してから送る。 要件が確定していれば先行応答の受領を待たずに送ってよい。 未確定の要件を断片的に中継して委譲先が未確定の要件で作業する事態を防ぐため、確定した差分を1回で送る（努力目標） - ユーザーが定性語又は程度語（軽微、過剰、十分など）で示した判定基準を、委譲先が適用する判定条文へ具体化して中継する場合は、当該要件を未確定として扱う。 具体化案として判定対象、判定主体、判定時点、及び機械的な除外一覧を設けるか現場判断とするかを示し、`AskUserQuestion`で確認してから送る。 ユーザーが判定条件そのものを逐語で指定した場合と、`agent-toolkit/rules/01-agent.md`「ユーザー発話の解釈」により提案として扱い技術判断で確定できる場合は対象外とする。 判定基準の選択がユーザーの選好に依存する場合だけ適用する （定性語の解釈違いは委譲先の成果物全体をやり直させるため） - 同一応答内で複数の継続接続を発行する場合は、送信前に各呼び出しの宛先識別子と本文が担当する作業に対応することを照合する。 作業内容を含まない仮置き本文を送信しない - 中断済み、完了配送不能、前提が無効化された識別子は再利用せず、検収済み状態を渡して新規起動する。 配送不能の判定手段は`references/claude-code-runtime.md`を正本とする。 Codexでは、`runtime-routing.md`「Codex後続操作の共通先行条件」を適用してから新規起動する。 完了報告を受領して停止済みの識別子は一律に禁止せず、`references/claude-code-runtime.md`と `references/runtime-routing.md`が定める、同じ担当へ同じタスクを返し、継続直前の実効`engine`・`model`・`effort`が一致する条件を満たす場合だけ再利用する。 `feedbacks-planner`の`awaiting_confirmation`後の再開はこの一般条件の例外であり、停止済みの識別子を再利用せず、 全文の再開コンテキストを含めた同じ系列の新しい識別子を起動する - 計画ファイルなどを反復編集する工程は、整合確認と修正を同じ委譲先へまとめる - ユーザーの介入が生じた場合は強制停止・再起動を既定とせず、介入内容を追加指示として伝えて 委譲先自身に反映させる。停止するのは介入により対象範囲・前提が無効化され、 続行が誤った成果物を生む場合に限る。 この場合も停止の前に、介入の実施を稼働中の作業の完了後まで遅らせられるかを判定する - 委譲を停止した場合は、再起動の前に停止時点の成果物を全文検収する。 完成条件を満たす場合は再起動せず呼び出し元が引き取り、満たさない場合だけ再起動する。 Codexで再起動する場合は、`runtime-routing.md`「Codex後続操作の共通先行条件」を適用してから行う。 再起動時は完了済み工程・試行済みのアプローチ・観測できた失敗事象を起動プロンプトへ引き継ぎ、白紙から再分析させない ## 受領と検収 通常のツール戻り値または完了通知を第一の受領経路とする。 受領後は、報告本文より先に成果物、Git状態、実行識別子、検証結果を実測する。 タスク文書の必須欄、対象、権限、完了条件と照合し、次のいずれかだけを返す。 ```text route: <実際に使った経路> identifier: status: completed | fast_fix_handoff | merge_review_pending | scope_deviation_hold | checkpoint | awaiting_confirmation | needs_escalation response: <受信者の最小完了報告> ``` `fast_fix_handoff`は`implementation-task.md`のfast担当が同一失敗箇所の残存とdirty差分を 構造化した`repair_handoff`として返す専用状態であり、`completed`又は`needs_escalation`へ読み替えない。 `merge_review_pending`は`implementation-task.md`のマージ担当がrebase競合を解消した際の専用状態である。 ff前進せず、解消箇所とrebase後HEADを返す。 `scope_deviation_hold`は同文書の実装担当が計画の変更説明を超える差分を検出した際の専用状態である。 追加変更とcommitへ進まず返す。いずれも`fast_fix_handoff`と同型の中間報告であり、確定状態へ読み替えない。 `checkpoint`は作業継続中の定義済み中間報告として受理する。 `checkpoint`を返せるのは、呼び出し元が最上位セッションであり、呼び出し元のタスク文書がチェックポイントを 定義する委譲に限る（`agent-toolkit/agents/plan-impl-executor.md`のチェックポイント契約を参照）。 `awaiting_confirmation`は、`feedbacks-planner`が不採用確認用`user_decisions`を返して確認を待つ状態を表す。 呼び出し元はこれを失敗として処理せず、確認回答又はTBDを受領して同じ系列の新しい識別子を起動する。 構造化された`status: awaiting_confirmation`は受領可能な状態である。 待機表明による終端は再開可能な正常状態として受理し、呼び出し元が完了通知を中継して再開する。 必須結果不足と成果物との不一致は完了と扱わない。 記録経路は通常配送不能を実測した場合だけ使用し、所有主体の終端と内容検収後に管理対象一時領域を後始末する。 - 実測と報告本文が異なる場合も、実体と証拠から正しい値が一意に定まり必要な実作業が完了していれば、 呼び出し元が補正値と根拠を記録して受理する。 実作業が未完了、証拠が不足、補正候補が複数残る場合だけ、未完了項目と実測結果へ縮減して再委譲する - 委譲先が稼働している間、委譲元は委譲先の対象範囲に含まれるファイルを編集しない。 編集する場合は実行状態から終了を確認し、作業ツリーとコミット履歴を確認してから行う。 完了報告の受領だけを稼働終了の根拠にしない。 編集の競合を検知した場合は採用する版を確定してから統合し、破棄した内容を委譲先へ通知する - 完了報告が退避識別子または複製パスを開示した場合は、当該退避物を照合対象へ加えて内容を確認し、 `../commit/SKILL.md`の「作業用ブランチと退避物の削除」節に従って処置する - 指摘の採否と修正を確定する場合は`agent-toolkit:reviewee-standards`を起動する - サブエージェント出力（レビュー指摘・調査結果）の統合は、指定されたレビュー表へ記録してから修正に着手する。 指摘を追加する主体は`track`を付けて指摘を記録し、レビューイーは行を一意に特定できるキーを指定して応答欄を更新する - `指摘内容`には、観測した実際値、期待値、違反する規範または契約の出典、対象への適用根拠を残す - `対応要否`がyesの場合は`対応内容`へ最上位の主体が独立に確定した採否、最小限の修正、変更してはならない契約を残す - `対応要否`がnoの場合は`対応不要理由`へ、メイン判断又はユーザー判断の別と理由を記録する - 応答欄の記述は委譲元が確定した判断の記録であり、受信者の作業手順ではないため起動文の命令へ転写しない - レビュー指摘に必要な裏付けを取得できない場合は、指摘として統合又は修正担当へ配送せず、証拠不足の範囲と必要な検証を同じレビュー担当へ返す - サブエージェントの動作・運用自体を分析対象とする場合は、稼働中の当該サブエージェントの完了報告を 観測源に含めてから結論を確定する ## 停滞の検知と巻き取り 委譲先または背景ジョブの完了待機を開始する直前に `references/waiting-and-monitoring.md`を全文読む（努力目標）。 - 委譲機能が返す状態・識別子を優先して停滞を検知し、状態を取得できない経路だけ `git log`と`git status`を補助的に用いる - Codexの`list_agents`が対象を`running`として返している間は、補助観測や催促だけを根拠とする巻取り、新規起動、役割引継ぎを行わない。 後続主体を起動できるのは、ユーザーの明示要求、終端・失敗status、タスク契約上のキャンセルのいずれかを確認した後、 元担当の終端と書込所有権の解放を確認した場合だけである - Codex以外では、同一種別かつ同一用途の起動を反復しても収束しない場合に、進捗の有無によらず収束を促す - 委譲先が担っていた役割を巻き取る場合は、当該役割のタスク文書が定める主体別の義務 （判断の所有者、加工せず配送する対象、収束条件）をそのまま自身へ適用する。 役割の移動を理由に、当該義務を省略した簡略経路へ切り替えない ## 再委譲する場合に守る事項 上流から委譲を受領した実行主体が自らさらに委譲する場合、当該実行主体自身が次を守る。 本スキルの送信側契約も併せて適用する。 受信者一般が守る厳守規定は`agent-toolkit/rules/02-agent-operations.md`「委譲時の厳守事項」節が定め、 本スキルを起動しない委譲先へも適用される。 - 上流から受領した取り決め（作業場所、書込主体、出力言語、プロセス所有権、不可逆操作権限とその許可範囲）を 省略せず同じ意味で引き継がせ、子孫の完了本文を自身で受領して自身の完了報告へ含める。 子孫から祖先への直接送信を完了配送経路として前提にしない