Subagent Delegation Brief

委譲すると決めた後に、派遣プロンプト 1 通を組み立てて送り、返ってきた報告を受理するまでの実行入口。

サブエージェントは会話履歴を持たない。書かれていない情報は「無い」ものとして扱われる。 このスキルは「何を書くか」のチェックリストであり、契約本文は持たない（正本を複製すると drift する）。

正本（定義はすべてここにある / 本ファイルで再定義しない）

参照解決順（導入先で必ずこの順に探す）: 本 Skill が参照する docs/** は上流リポジトリ基準の相対パスであり、install.sh --claude / plugin（Claude marketplace）/ Codex の 3 経路とも配布対象外（解決不可）。(1) 導入先リポジトリの同名パスを探す → (2) 見つからなければ 「正本 <path> を参照できなかった」と明示し、本 Skill 内の記述を代替正本として扱い、推測で内容を補わない。plugin root 配下の探索は docs/** には適用しない: plugin が配布するのは agents / commands / skills / rules 等の定義ディレクトリのみで docs/ を配布対象として認識せず、plugin root 配下に相当する配布物が存在しないため、plugin root 段を置いても必ず空振りする（クラス A の rules 参照が plugin root 配下で解決できるのは rules/ が実際に配布されるからであり、この非対称を docs/** に持ち込まない）。

1. 派遣前チェックリスト（8 要素）

各行を埋めてから送る。埋められないものは「該当なし」と明示する（空欄は暗黙の許可・暗黙の禁止として誤読される）。

2. 要素 4 の追加規約 — 却下済み仮説と「反証を許可する一文」

要素 4 は 3 つを分けて書く。確定済みの事実だけを書いても足りない。

1. 確定済みの事実・実測値: 数値・ファイルパス・exit code など、再調査させないための一次情報
2. 却下済み仮説: 「これは試さない / 再提案しない」と、その理由（理由が無いと相手は蒸し返す）
3. 反証を許可する一文（必須）: 例 —「上記は実測済み。ただし疑わしければ反証してよい。却下済み仮説以外は、実測が示すなら反論すること」

3 は形式的な礼儀ではない。依頼者の前提自体が誤っていることがあり、反証を明示的に許可した委託だけがそれを発見できる。 許可を書かないと、受け手は誤った前提の上に正しく作業してしまう。

空欄で出さない。本当に無い場合のみ「既知事実なし（新規調査）」と明記する。

実害の負例（要素 4 を落とした結果）

直前に自分で確認した「テスト実行系が新規ファイルを単独実行し、時間超過を失敗として扱う」という事実を渡さずに委託し、 ワーカーが長時間の無進捗で停止した事例がある。自分が数分前に知ったことほど、書き忘れる。

3. 要素 7 の追加規約 — OUTCOME 契約への導線

派遣プロンプトの出力形式欄に、次の 3 点を必ず入れる（定義は docs/ai/subagent-delegation/outcome-contract.md）。

1. 最終行に OUTCOME を 1 回だけ書かせる。表記ゆれ（小文字・スペースなし・コロン前スペース）・複数出現・最終行でない、はすべて契約違反
2. 要判断事項を P0 / P1 / P2 で分類させる。無い場合も「なし」と明記させる（無言の省略と区別できない）
3. 検証状態を「実行済み / 未実行 / 失敗 / 未検証」で明示させる。「問題ありません」は不可

受領後は機械判定にかける（§5）。

4. 8 要素に無い穴 — 成果物そのものの形式

8 要素は「何を渡すか」「何を返すか（報告形式）」を定めるが、成果物そのものの形を定めていない。 その結果、粒度・分量・準拠テンプレートが受け手の裁量になり、統合時に作り直しが発生する。 要素 5（タスク）または要素 7（出力形式）の補足として、次を明示する。

worktree で派遣する場合の定型（要素 6 の補足）

• 隔離 worktree を与える場合、そのディレクトリ配下のみ書き込み可と書く。共有チェックアウトへ cd しないことを明記する
• worktree のガードは複合コマンド（[ ... ] || exit 1 等）やリダイレクトを拒否することがある。 拒否されたらコマンドを分割して実行するよう、あらかじめ書いておく（受け手が回避策を自作して破壊的操作に走るのを防ぐ）
• ブランチを切らせる場合は分岐元を明示し、作成直後に差分が空であることを検証させる

5. 受領時チェック（丸呑みしない）

ユーザーへ返す前に 5 項目を確認する（判定基準の正本は docs/ai/subagent-delegation/outcome-contract.md §6）。

項目 3・4・5 は決定論的に判定できる:

# 報告本文をファイルに落として、または標準入力から
sh scripts/check-outcome-contract.sh report.txt

exit 0 = 3 項目とも充足 / exit 1 = 契約違反（違反箇所を出力）/ exit 2 = 使い方エラー。

いずれか FAIL のときは、別セッションへ再委譲せず同一サブエージェントへ追指示して是正させる。 P0 の要判断事項があれば、是正要求と並行してユーザーへ即エスカレーションする。

機械判定の既知の限界

• 項目 1・2 はタスク依存のため判定しない（目視のまま）
• コードフェンス内に OUTCOME: で始まる行があると、複数出現として検出される（報告に契約の実例を貼るときは行頭を避ける）

6. やらないこと

• 承認境界（計画承認 / PR 承認 / マージ）を代替しない。派遣は承認済みタスクの実行委任にすぎない
• 委譲するか否かの判断基準を再定義しない（codex-multi-agent に従う）
• タスク分配・依存グラフ生成を扱わない（subagent-dispatch の責務）