subagent-delegation-brief

name	subagent-delegation-brief
description	サブエージェントへの派遣プロンプトを必須 8 要素で組み立て、OUTCOME 契約付きの完了報告を受け取るための薄い実行入口。Use when: 「サブエージェントに委託する」「Agent を起動する」「派遣プロンプトを書く」「委託の完了報告を受け取った」「並列でワーカーを走らせる」。Do not use when: 委譲するか否かの判断そのもの（codex-multi-agent）／ロール割当・依存グラフ生成・並列 dispatch（subagent-dispatch）／実装品質の 2 段階レビュー手法（subagent-driven-development）。

Subagent Delegation Brief

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

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

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

正本	何が書いてあるか
docs/ai/subagent-delegation/dispatch-template.md	必須 8 要素の定義・省略時の実害・用途別テンプレート本体（調査 / 実装 / レビュー / 追指示）
docs/ai/subagent-delegation/outcome-contract.md	OUTCOME の表記ルール・P0/P1/P2 の定義・検証状態 4 区分・review=true・受け入れ確認 5 項目の判定基準
docs/ai/subagent-delegation/behavior-norms.md	行動規範（軽量版 / フル版）
docs/ai/subagent-delegation/examples.md	フルサンプル
docs/ai/subagent-delegation/README.md	配置 ADR・オーケストレータ責務・索引

参照解決順（導入先で必ずこの順に探す）: 本 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 要素）

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

#	要素	この委託で具体的に何を書くか
1	役割・プロジェクト・項目ID・タスク名	後から報告を突合できる識別子を含めたか
2	なぜこのモデルか	定型作業ではなく判断系である理由を 1 行
3	最初に読む SSOT	優先順に列挙し、1 つ目だけで着手できるか。リンク切れを送信前に確認したか
4	既知の事実・実測値・確定済み結論・却下済み仮説	§2 の追加規約に従う（最も落ちやすい）
5	順序付きタスク	依存順の番号付き。並列可能な範囲を明示したか
6	制約	write 可否 / 対象パス / 触ってはいけないもの / 禁止操作 / ソフト上限。§4 の worktree 定型も参照
7	出力形式	§3 の追加規約に従う（2 番目に落ちやすい）
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）。

#	項目	判定
1	要求した成果物があるか	目視（タスク依存のため機械判定しない）
2	制約違反がないか	目視（同上）
3	OUTCOME が最終行に 1 回あるか	機械判定（下記）
4	要判断事項が P0/P1/P2 で分類されているか	機械判定
5	検証結果が 4 区分で明示されているか	機械判定

項目 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 の責務）