PlanGate

サブエージェント派遣プロンプト テンプレート

親 issue: #710 サブエージェント委譲プロトコルを PlanGate 運用に組み込む 対応子 issue: #713 サブエージェント派遣プロンプトの必須8要素テンプレートを追加する 関連（同ディレクトリ）: README.md（正本入口・全体像、#711）/ outcome-contract.md（OUTCOME 契約、#712）/ behavior-norms.md（行動規範 軽量版・フル版、#714）/ plangate-flow-integration.md（委譲タイミング、#715）/ examples.md（サンプル、#716）

0. これは何か（既存資産との違い・重複させない）

サブエージェント派遣は本リポジトリに複数の既存資産があるが、いずれも「委譲の判断基準・分配構造」または「TDD 実装フロー限定のファイル授受」を扱っており、派遣プロンプト本文そのものの自己完結性契約を定義したものではない。本ファイルはその隙間を埋める。

既存資産 扱う範囲 本ファイルとの関係
.claude/skills/codex-multi-agent（SKILL.md） いつ委譲するか / どう分割するか / 並列化可否の判断基準 委譲するかどうかの判断は codex-multi-agent に従う。委譲すると決めた後のプロンプト本文の書き方が本ファイル
plugin/plangate/skills/subagent-dispatch（SKILL.md） high-risk / critical モードでの依存関係グラフ生成・並列 dispatch・dispatch/task-NNN-brief.md 等のファイル授受 TASK exec 中の実装 dispatch では task-NNN-brief.md がタスク別要件ファイルになる。本テンプレートの要素はそのファイルを派遣プロンプト本文に落とし込む際の共通フォーマットとして使える（矛盾しない・置換しない）
.claude/rules/orchestrator-mode.md 親子 PBI の Gate 不変条件・状態遷移・AI 自己完結禁止 承認境界（C-3 / C-4 / 親子 Gate）は本ファイルの対象外。派遣プロンプトは承認済みのタスクを渡す手段であり、承認そのものを代替しない

本ファイルが定義するのは、会話履歴を持たないサブエージェント（Task / Agent 起動、または新規ワーカーへの SendMessage）に渡す 1 回の派遣プロンプトが備えるべき必須8要素と、用途別の具体テンプレートである。

1. 前提

2. 必須8要素

# 要素 目的 省略すると起きること
1 役割・プロジェクト・項目ID・タスク名 サブエージェントが自分の立ち位置を即座に把握する 別タスクの文脈を混同する
2 なぜこのモデルに格上げされたか タスクの難度・リスクに見合った推論深度で臨ませる 軽いモデル前提の浅い調査で終わる、または逆に過剰トークン消費
3 最初に読む SSOT・Issue・関連資料 正本を自分で探させない 誤った・古い情報源を正とみなす
4 既知の事実・実測値・確定済み結論・却下済み仮説 再調査・再検討のコストを排除する 確定済み事項を再調査する、却下済みの選択肢を再提案する
5 順序付きタスク 実行順序の曖昧さを排除する 依存関係を無視した手順で進める
6 制約（read-only / write可、対象 worktree、禁止操作） 破壊的操作・越権操作を未然に防ぐ 想定外のファイル・repo・プロセスに影響を与える
7 出力形式（成果物URL、要判断事項、OUTCOME） 統合側が機械的に結果を解釈できるようにする 自由記述で終わり、統合コストが増える
8 行動規範（軽量版 / フル版） 報告品質と作業規律を安定させる 結論を後回しにする、スコープ外に手を広げる、進捗を実証しない

各要素の詳細:

要素1: 役割・プロジェクト・項目ID・タスク名

要素2: なぜこのモデルに格上げされたか

要素3: 最初に読む SSOT・Issue・関連資料

要素4: 既知の事実・実測値・確定済み結論・却下済み仮説

要素5: 順序付きタスク

要素6: 制約

以下を状況に応じて明記する（該当なしの項目も「該当なし」と明示し、暗黙の許可と誤読させない）。

制約カテゴリ 記載例
read-only / write可 「本タスクは read-only。ファイルの新規作成・編集を行わない」/「write可。対象は下記 worktree 配下のみ」
対象 worktree 絶対パス 「/Users/xxx/repo/.claude/worktrees/feat-xxx 配下のみ書き込み可」
触ってはいけないファイル・ディレクトリ・repo 「.claude/rules/*.md / .claude/settings*.json 等の HO パスは Write/Edit 禁止（作成のみ許可、適用は人間）」
稼働中プロセス停止禁止 「他セッションが起動しているプロセス・サーバーを kill しない」
削除・外部投稿・破壊的操作 「git push / PR 作成 / issue 起票 / ファイル削除は事前承認なしに行わない」
作業ツリーを一括で戻すコマンドを禁じる（理由つきで） 「git stash / git checkout <rev> -- <dir> / git reset --hard / git clean を使わない。禁止の理由: (a) stash スタックはリポジトリ横断で共有され、並走エージェントが互いの stash を pop して壊す (b) git checkout <rev> -- <dir> は自分の未コミット編集を予告なく全消しする（2026-09-07 実測: ワーカーが自分の 8 編集を消失し再適用に往復した）。代替: 作業を退避したいなら一時 WIP commit（git commit -m wip → 後で git reset --soft HEAD^）。原本と比較したいなら git show <rev>:<path> > /tmp/orig.md で別ファイルに出して差分を見る。検証で repo を汚したくないなら git clone --no-hardlinks か git archive で repo 外にサンドボックスを作る」
EH-3（check-plan-hash.sh）にブロックされた場合 「Edit ゲートに拒否されたら成果を commit して状態報告し停止する。EH-3 の env（PLANGATE_HOOK_TASK / PLANGATE_SKIP_REASON）は起動時固定で、ワーカーが実行中に export / インライン付与しても hook には届かない（2026-09-05 実測: ワーカー 3 体が同経路で停止）。派遣側は 起動時に PLANGATE_HOOK_TASK=TASK-XXXX を与える。hook は ${CLAUDE_PROJECT_DIR}/scripts/hooks/ = 共有 checkout 側で実行される（worktree 側には hook-events.log が生成されないことを 2026-09-05 に実測）ため、worktree の ref ではなく 共有 checkout が BASH_LANE_NOOP（#1104 hotfix）を含む ref にあることを派遣前に確認する（確認コマンドの正本は要素 4 の bullet）。ただし共有 checkout の hook は worktree 配下の HO パス（.claude/worktrees/*/CLAUDE.md 等）を判定しない（#1277）。worktree での HO 編集を止めるのは本表「触ってはいけない」行の派遣側指定が唯一の防御。maintenance.json の 30 分窓に依存させない。Bash 経由の直接書き込みでゲートを迂回しない」
実装ワーカーの派遣元セッション 「.md 以外を書く実装ワーカーは PLANGATE_HOOK_TASK または PLANGATE_SKIP_REASON を起動時 env に持つセッションから派遣する。no-task セッションからの派遣では設計・docs までしか進めない（2026-09-05 wave-6 で 3 体が 2 回停止）」
.md 編集ツール（EH-13 偽陽性） 「.md の編集は Edit / Write ツールを使う。Bash heredoc に Markdown 引用（行頭 >）や強調（**。2026-09-05 実測: rule=file-redirect, redirect_target=**DRAFT で block）を含めると EH-13 が承認トークン書込と誤認して block する（#1243 / #1269 の既知クラス。** 形状は #1269 の台帳へ追記済み）。迂回せず Edit へ切り替える」
PostToolUse formatter の整形ノイズ 「formatter がファイル全体を再整形する環境では、git show origin/main:<path> の原本へ変更行だけを再適用して diff を最小にする。整形ノイズを含む diff を PR に出さない」
不在の結論は表記揺れまで試す 「grep が 0 件でも『存在しない』と結論づけない。大小（-i）・英日の表記揺れ・区切り文字違いを試してから書く（2026-09-07 実測: human intervention の大小区別 grep が Human intervention rate を取りこぼし、ワーカーが『参照は存在しない』と誤報告した）」
ミラー生成物のあるファイルを編集する 「編集対象が同期スクリプトでミラーされるファイルなら、ミラー側の差分まで確認する。fenced block 内の相対リンクなどミラー側で書き換えが効かない記法があり、正本では正しくミラーだけ壊れる（2026-09-07 実測）。編集後に同期スクリプトを実行し、git diff --stat が想定どおりか・2 回目の実行が no-op（冪等）かを確認する」
環境差の原因帰属 「CI とローカルで挙動が違っても OS 名に帰属させない。決定要因（/bin/sh の実体・python のマイナー版・coreutils の実装など）を列挙して実体ごとに測る。エラーモードが複数あるならモード別に測る（2026-09-07 実測: EH-3 の監査ログ書込失敗が /bin/sh=bash で rc=1・dash で rc=2 だが、mkdir 失敗は dash でも rc=1。『macOS 固有』という帰属は /bin/sh が bash な Linux を取りこぼし、最も危険なケースを安全側に見せた）。『CI が緑 = 実運用が安全』とは書かない」
CI 赤に対する期待値の緩和 「CI の失敗を期待値を緩めて通す前に、repo 側の判定規約（tests/extras/README.md の P-1〜P-10 等）を読む。『この緩和で何が検出できなくなるか』を 1 文で書けないなら緩めない。環境依存の値は定数を捨てるのではなく実行時に測って定数の代わりにする（捨てると検査が消え、測れば検査は残る）。緩めたら逆方向の対照（同じ述語を『直った側』の入力に当てて成立しないことの assert）を必ず足す（2026-09-07 実測: rc を ≠0 に緩める指示が P-1/P-2 に抵触し、検査したかった rc の差そのものを消していた）」
照合コマンドの前提検査 「コマンド置換の結果を照合に使うなら、変数が空でないことを先に検査する（[ -n "$X" ] が偽なら中断する）。空変数は『差分なし』に化ける（2026-09-07 実測: gh の 401 で H=$(gh pr view …) が空になり git show "$H:path" が index を返して恒真の『変更なし』を出した）。positive control は検査対象の領域内を壊すこと」
コード中の文字列の引用 「コードが出力する診断文字列を設計意図として引用しない。周辺の定義・コメント・条件分岐を読んでから引用する（2026-09-07 実測: ta-61 の診断文『それでも本 TC は FAIL のまま』を『予算引き上げでは根治しない』の意味と解し、起票済み issue の受入基準に誤って書いた。実際は『その run の判定を降格しない』の意味）」
調査の基点 SHA を固定する 「調査・監査系の派遣では git fetch origin を実行し origin/main の SHA を実測してから始める。共有 checkout のローカル main は遅れていることがあり、古い基点で調べると結論が stale になる（2026-09-07 実測: ローカル main が 4 commit 遅れており、既にマージ済みの是正を『未是正』と報告した）。報告には実測した対象 SHA を必ず書く」
ソフト上限 「Nステップ（目安 15）または概算 Mトークン相当で一旦中断し、進捗を報告する」

要素7: 出力形式

要素8: 行動規範

3. テンプレート本体（基本形）

## 役割・タスク

あなたは <プロジェクト名> の<役割>です。項目ID: <ID>。タスク名: <タスク名>。

## モデル格上げ理由

<なぜ判断系 / high-risk 相当の推論深度が必要か>

## 最初に読むもの（順に）

1. <SSOT / Issue へのパス>
2. <関連資料>

## 既知の事実・確定済み結論・却下済み仮説

- 確定済み: <事実>
- 実測値: <数値>
- 却下済み仮説: <試さない理由>
  （新規調査で本当に無い場合のみ）既知事実なし

## タスク（順序付き）

1. <タスク1>
2. <タスク2>（1 完了後）

## 制約

- read-only / write可: <どちらか>
- 対象 worktree: <絶対パス、または該当なし>
- 触ってはいけないもの: <一覧、または該当なし>
- 禁止操作: <一覧、または該当なし>
- ソフト上限: <Nステップ / Mトークン目安>

## 出力形式

- 成果物: <パス / URL>
- 要判断事項: `[P0]`/`[P1]`/`[P2]` を付けて列挙（無ければ「なし」）
- 最終行: `OUTCOME: success|partial|failure`（[outcome-contract.md](/PlanGate/ai/subagent-delegation/outcome-contract.html) 準拠）

## 行動規範

<[behavior-norms.md](/PlanGate/ai/subagent-delegation/behavior-norms.html) の軽量版 or フル版を埋め込み、または要約+参照>

4. バリアント別テンプレート

4-A. 調査エージェント向け

## 役割・タスク

あなたは <プロジェクト名> の調査エージェントです。項目ID: <ID>。タスク名: <調査対象>の実挙動調査。

## モデル格上げ理由

既存資料だけでは判断できない実挙動の確認と、複数候補の中からの推奨判断を要するため。

## 最初に読むもの（順に）

1. <調査対象に関する既存 issue / SSOT>
2. <関連コード・設定ファイルのパス>

## 既知の事実・確定済み結論・却下済み仮説

- 確定済み: <既に分かっていること>
- 却下済み仮説: <調べ直さなくてよい選択肢>

## タスク（順序付き）

1. <対象の現状を実測する（grep / 実行結果 / ファイル存在確認）>
2. <既存資料との差分を特定する>
3. <選択肢を比較し推奨案を1つ提示する（決定はしない）>

## 制約

- read-only。ファイルの新規作成・編集は行わない
- 対象 worktree: 該当なし（読み取りのみ）
- 触ってはいけないもの: 対象リポジトリ外への外部送信、破壊的コマンド全般
- ソフト上限: 15 ステップ相当

## 出力形式

- 成果物: 調査結果のサマリ（本文またはファイル）
- 要判断事項: 推奨案の採否は `[P1]`/`[P2]` として提示（実装可否の最終判断は依頼元）
- 最終行: `OUTCOME: success|partial|failure`

## 行動規範

軽量版（[behavior-norms.md](/PlanGate/ai/subagent-delegation/behavior-norms.html) §軽量版）。真因調査に発展する場合はフル版に切替える。

4-B. 実装エージェント向け

## 役割・タスク

あなたは <プロジェクト名> の実装エージェントです。項目ID: <TASK-XXXX-Tn>。タスク名: <実装対象>。

## モデル格上げ理由

複数ファイルにまたがる設計判断を伴う実装のため（単純な機械的置換ではない）。

## 最初に読むもの（順に）

1. `docs/working/TASK-XXXX/plan.md` の該当 Work Breakdown 項目
2. `dispatch/task-NNN-brief.md`（Target Files / Spec / Existing Tests / Constraints）

## 既知の事実・確定済み結論・却下済み仮説

- 確定済み: <採用済み設計判断>
- 却下済み仮説: <plan で不採用と決めた代替案>

## タスク（順序付き）

1. `task-NNN-brief.md` の Spec を満たす実装を行う
2. Existing Tests を実行し GREEN を確認する
3. `dispatch/task-NNN-report.md` に実行コマンド・結果・変更サマリを記録する

## 制約

- write可。対象は `task-NNN-brief.md` の Target Files のみ
- 対象 worktree: <絶対パス>
- 触ってはいけないもの: Target Files 以外の全ファイル、Hardening Override 対象パス（`.claude/rules/*.md` 等）
- 禁止操作: `git push` / PR 作成（依頼元が行う）
- ソフト上限: <Nステップ / Mトークン目安>

## 出力形式

- 成果物: `dispatch/task-NNN-report.md` の絶対パス
- 要判断事項: 設計上の疑問が生じた場合は実装を止めて `[P0]` として報告
- 最終行: `OUTCOME: success|partial|failure`

## 行動規範

フル版（[behavior-norms.md](/PlanGate/ai/subagent-delegation/behavior-norms.html) §フル版）。長時間実装・複数ファイル変更のため。

4-C. レビュー / 監査 / 真因調査エージェント向け

## 役割・タスク

あなたは <プロジェクト名> のレビュー/監査エージェントです。項目ID: <ID>。タスク名: <対象>の<レビュー種別>。

## モデル格上げ理由

表面的なチェックではなく、故障確率に基づく判断と根本原因の特定を要するため。

## 最初に読むもの（順に）

1. `.claude/rules/review-principles.md`（5観点 / Severity定義 / 判定基準）
2. <レビュー対象の diff / PR / ファイル一覧>

## 既知の事実・確定済み結論・却下済み仮説

- 確定済み: <既に合意済みの前提>
- 却下済み仮説: <既に否定された原因候補>

## タスク（順序付き）

1. 対象の変更内容を把握する
2. 5 観点（可読性・拡張性・パフォーマンス・セキュリティ・保守性）で Severity 分類する
3. critical/major は再現手順または根拠を示す（推測で断定しない）

## 制約

- read-only。修正は行わず指摘のみ
- 対象 worktree: 該当なし
- 禁止操作: 該当ファイルへの直接修正、外部への指摘内容の共有
- ソフト上限: <Nステップ / Mトークン目安>

## 出力形式

- 成果物: Severity 別指摘一覧（`.claude/rules/review-principles.md` 準拠）
- 要判断事項: critical は `[P0]`、major は `[P1]` として明示
- 最終行: `OUTCOME: success|partial|failure`

## 行動規範

フル版（[behavior-norms.md](/PlanGate/ai/subagent-delegation/behavior-norms.html) §フル版）。真因調査・設計レビュー・監査のため。

4-D. 同一サブエージェントへの追指示（SendMessage）

会話履歴を保持したまま追加指示を送る場合でも、前回のタスク完了状態と新しい制約の再宣言を省略しない（暗黙の継続を前提にしない）。

## 前回タスクの完了状態（要約）

<前回の OUTCOME と成果物への参照>

## 追加タスク（順序付き）

1. <追加タスク1>
2. <追加タスク2>

## 変更・追加された制約（あれば）

- <前回から変わった制約。無ければ「前回と同一」と明記>

## 出力形式

- 前回と同様。最終行に `OUTCOME: success|partial|failure` を再掲する

5. 「既知の事実」「却下済み仮説」を必須入力にする理由

6. 使い方の目安

状況 使うテンプレート
単発の調査・影響範囲確認 4-A 調査エージェント向け
TASK exec 中の実装 dispatch（high-risk/critical） 4-B 実装エージェント向け（plugin/plangate/skills/subagent-dispatch の dispatch/task-NNN-brief.md と併用）
PR レビュー・監査・真因調査 4-C レビュー/監査エージェント向け
起動済みサブエージェントへの追加指示 4-D 追指示テンプレート

7. 参照

This site is open source. Improve this page.