PlanGate

サブエージェント行動規範 — 軽量版 / フル版

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

0. これは何か(既存資産との違い・優先順位不衝突)

本ファイルは、派遣プロンプト(dispatch-template.md 要素8)に埋め込む「サブエージェントの作業規律・報告品質」の規範を、軽量版フル版の2段階で定義する。

既存ルールを置き換えない・上書きしない。 本規範は「派遣されたサブエージェントが、既に承認された作業をどう遂行するか」という 実行時の作法であり、以下の既存正本より下位に位置する:

既存正本 扱う範囲 本ファイルとの関係
docs/ai/core-contract.md Iron Law 8 項目(不可侵)/ Stop rules / Output discipline 最上位。Iron Law に抵触する行動規範は無効。本ファイルの各項目は Iron Law の運用解釈であり矛盾しない(§4 参照)
docs/ai/project-rules.md F節 AI 運用4原則(実行前確認 / 迂回禁止 / 決定権 / 解釈変更禁止) Core Contract と同格で不可侵。本ファイルはこれを緩めない
.claude/rules/orchestrator-mode.md 親子 PBI の承認 Gate(C-3 / C-4 / AS-1〜5) 承認境界は本ファイルの対象外。本ファイルは「承認済みタスクの遂行作法」のみを扱う
.claude/rules/review-principles.md レビュー時の5観点・Severity・判定基準 レビュー系サブエージェントの出力内容の基準は review-principles.md に従う。本ファイルは作業姿勢(結論先行・進捗実証等)を扱い、内容基準を再定義しない

モデル別に分けない(issue #714 注意点): Fable / Sonnet / Opus / Haiku のいずれに貼ってもそのまま使える内容にする。モデル・reasoning effort の選定自体は docs/ai/model-profiles.md が正本であり、本ファイルは行動規範のみを扱う。

1. 軽量版

使いどころ

小さな調査、短いレビュー、限定的なファイル確認など、単一ターンで完結する・影響範囲が明確なタスク

内容(5項目)

# 項目 内容
1 結論先行 調査過程を長々と述べる前に、まず結論(分かったこと / できたこと)を1〜2行で述べる
2 未検証は未検証と明記 確認していないことを確認済みのように書かない。「未確認」「推測」「実測」を区別する
3 スコープ外作業をしない 依頼されたタスク以外に手を広げない。気づいた別件は指摘に留め、勝手に着手・修正しない
4 要判断事項は [P0]/[P1]/[P2] で返す 人間または依頼元の判断を要する事項は優先度付きで報告する(定義・記法は outcome-contract.md §2 参照)
5 最終行に OUTCOME を付ける OUTCOME: success \| partial \| failure を最終行に1行で明記する(詳細は outcome-contract.md

軽量版テンプレート断片(派遣プロンプトへの埋め込み用)

## 行動規範(軽量版)

- 結論を先に述べてから根拠を説明すること
- 確認していないことは「未確認」と明記し、確認済みと混同しないこと
- 依頼されたタスク以外に着手しないこと。気づいた別件は指摘のみに留めること
- 判断が必要な事項は `[P0]`/`[P1]`/`[P2]` を付けて報告すること(P0=即判断が必要、P1=次アクション前に判断、P2=参考情報)
- 最終行に `OUTCOME: success|partial|failure` を1行で記載すること

2. フル版

使いどころ

真因調査、設計レビュー、監査、長時間実装、複数ファイル変更、外部情報検証など、複数ターン・複数ファイルにまたがり、判断の誤りが下流に波及しうるタスク

内容(フル版 7 項目+軽量版固有分を展開した 11 行表記)

軽量版の5項目(結論先行 / 未検証明記 / スコープ外禁止 / P0-P1-P2 / OUTCOME)を含んだ上で、以下2種を全項目に追加する。

# 項目 内容
1 結論先行 軽量版と同一
2 即行動 方針が決まったら確認待ちで止まらず、許可された範囲内で手を動かす。ただし Iron Law・制約(派遣プロンプト要素6)に抵触する操作は止めて確認する
3 進捗の実証 「できたはず」ではなく、実行結果・grep 出力・テスト結果など一次証跡を添えて進捗を示す(core-contract.md Iron Law #3・#8 の運用解釈)
4 スコープ規律 軽量版の「スコープ外作業をしない」を継続し、加えてタスク遂行中に発見したスコープ外事項は都度記録し、最後にまとめて報告する(都度脱線しない)
5 ターン終了規律 1ターンを未完了のまま曖昧に終えない。完了 / 中断(理由付き)/ 要判断で明確に締める
6 境界: 評価依頼と修正依頼を混同しない 「レビューして」と頼まれたら指摘に留め、勝手に修正しない。「直して」と頼まれたら指摘で終わらせず修正まで行う。依頼の種別を自己判断で変えない
7 優先順位: CLAUDE.md / rules / 派遣プロンプト制約 / SSOT 矛盾が生じた場合の参照順(詳細は §3)
8 未検証は未検証と明記 軽量版と同一
9 スコープ外作業をしない 軽量版と同一(4 のスコープ規律に統合して運用してよい)
10 要判断事項は [P0]/[P1]/[P2] で返す 軽量版と同一
11 最終行に OUTCOME を付ける 軽量版と同一

表は issue #714 の「フル版に含める内容」7項目(結論先行・即行動・進捗の実証・スコープ規律・ターン終了規律・境界・優先順位)と、軽量版5項目の完全上位互換であることを明示するために展開している。実運用でのテンプレート埋め込みは下記「フル版テンプレート断片」の7項目表記を使えばよい(軽量版相当の4項目は自動的に含まれる)。

フル版テンプレート断片(派遣プロンプトへの埋め込み用)

## 行動規範(フル版)

- 結論を先に述べてから根拠を説明すること
- 方針が決まったら確認待ちで止めず、許可された範囲内で行動すること。ただし制約(read-only/write可・禁止操作等)に抵触する場合は止めて確認すること
- 進捗は「できたはず」ではなく、実行結果・grep 出力・テスト結果等の一次証跡を添えて示すこと
- スコープ外の発見事項は都度脱線せず記録し、最後にまとめて報告すること。依頼されたタスク以外に着手しないこと
- 1ターンを曖昧なまま終えないこと。完了 / 中断(理由付き)/ 要判断のいずれかで明確に締めること
- 「レビューして」は指摘のみに留め、「直して」は修正まで行うこと。依頼の種別を自己判断で変えないこと
- 矛盾が生じた場合は CLAUDE.md → プロジェクトルール(rules) → 本派遣プロンプトの制約 → SSOT の順で優先すること(本規範や派遣プロンプトが Iron Law・AI運用4原則に抵触する場合はそちらが優先)
- 確認していないことは「未確認」と明記すること
- 判断が必要な事項は `[P0]`/`[P1]`/`[P2]` を付けて報告すること
- 最終行に `OUTCOME: success|partial|failure` を1行で記載すること

3. 優先順位項目の位置づけ(既存正本との不衝突の明示)

issue #714 のフル版に含める「優先順位: CLAUDE.md / rules / 派遣プロンプト制約 / SSOT を優先する」は、サブエージェントが派遣プロンプト実行中に情報源同士の矛盾に迷った場合の一般的な参照順である。以下を明確にする。

  1. この優先順位は docs/ai/core-contract.md 冒頭の「実行契約の優先順位」(Core Contract > project-rules > ai-driven-development、実行判断で重複時は Core Contract が最終根拠)を置き換えない。Core Contract レベルの制約(Iron Law 8項目)が本優先順位のどの段より常に優先する
  2. CLAUDE.md・.claude/rules/*.md はいずれも docs/ai/project-rules.md §G の参照先一覧に連なるドキュメント群であり、両者は通常矛盾しない。矛盾が生じた場合(想定外の記述不整合)はサブエージェント側で断定判断せず、要判断事項(P0)として差し戻す
  3. 「派遣プロンプト制約」(dispatch-template.md 要素6)は当該タスク限定の追加制約であり、CLAUDE.md・rules が定める禁止事項を緩和する方向には作用しない(追加のみ許可、緩和不可)
  4. SSOT(派遣プロンプト要素3で示す最初に読む資料)は最後尾に位置づける。SSOT の記述が古い・現状と乖離している場合は実測結果を優先し、その旨を報告する
  5. EH-3(scripts/hooks/check-plan-hash.sh の Edit ゲート)にブロックされた場合、Bash 経由の直接書き込みでのゲート迂回は禁止事項として緩和されない。正規経路(PLANGATE_SKIP_REASON を設定して再実行し、docs/working/_audit/skip-decision-log.jsonl に記録させる)に従う(dispatch-template.md 要素6参照)

4. 使い分け基準

判定軸 軽量版 フル版
ターン数見込み 単一ターンで完結 複数ターンにまたがる
影響範囲 限定的(1〜2ファイルの確認・軽微な調査) 複数ファイル・複数レイヤーにまたがる、または判断誤りが下流に波及する
タスク種別 小さな調査、短いレビュー、限定的なファイル確認 真因調査、設計レビュー、監査、長時間実装、複数ファイル変更、外部情報検証
モデル格上げ理由(dispatch-template.md 要素2)との対応 定型・構造化寄り 判断系・high-risk/critical 相当

判定不能・境界事例の扱い: タスクがどちらに該当するか迷う場合はフル版を選ぶ(軽量版は明確に小さいタスクのみに限定する安全側判定。mode-classification.md の「自動推定の安全側」原則と一貫)。

5. 派遣プロンプトへの組み込み方

dispatch-template.md 要素8「行動規範」には、以下いずれかの方法で組み込む。

方法 やり方 向いている場面
埋め込み型 本ファイルの「テンプレート断片」をそのまま派遣プロンプト本文にコピーする 大半のケース。サブエージェントが本ファイルを別途読みに行く保証がないため既定はこちら
参照型 behavior-norms.md の軽量版/フル版に従うこと。まずこのファイルを読むこと」と明記し、要素3(最初に読むもの)にも本ファイルへのパスを追加する 同一セッション内で複数回派遣する場合、または派遣プロンプトの文字数を抑えたい場合

いずれの方法でも、軽量版かフル版のどちらを適用するかは派遣プロンプト側で明示する(サブエージェントに判定させない)。

6. 参照