| name | plangate-working-discipline |
| description | PlanGate の中核作業規律。Intake → Plan → Review → Approve → Execute → Verify → Remember → Next Action の 8 フェーズループで AI 駆動開発の暴走・見落とし・偽の完了を防ぐ。Use when: 実装・修正・リファクタ・レビュー・長期タスク・セッション跨ぎ開発・サブエージェント利用判断のすべての作業開始時。Do not use when: 単発の質問応答・読み取りのみの調査（ループ全体は過剰。Verify/Report の規律のみ適用）。 |
PlanGate Working Discipline
AI 駆動開発の品質ゲート。計画を固定し、リスクを先に見て、承認要否を判定し、
観測可能な証拠で検証し、判断を記録するための作業規律。
v2（2026-07-07）: ai-loop 実運用 Run-001〜003 から得た規律を還元。
出典の内訳 — 摩擦記録（F-10〜F-13、docs/working/ai-loop-runs/run-001-frictions.md）
から: 原則 11（監査記録不変・F-10/Run-002 事後注記方式）・原則 12 と anti-pattern 16
（検証コマンド事前検証・F-12）・レビューのラウンド規律（F-13）。
Run-003 の C-4 追対応での実践（摩擦記録外・委譲プロトコル
docs/ai/subagent-delegation/ の追指示テンプレートの運用実証）から: 原則 9 の
SendMessage 追指示パターン。
高度なモデルの能力を再現するものではなく、どのモデルでも継承できる
「判断基準・検証ループ・停止条件」の集合である。
When to use / When not to use
- Use: 実装・修正・リファクタ・バグ修正・設計/差分レビュー・長期タスク・
複数セッション跨ぎ・サブエージェント委託を伴う作業のすべて。
- Do not use: 読み取りのみの単発調査・会話的な質問応答
（ただし報告時の「観測事実と推測の区別」は常時適用）。
Core Principles（中核原則）
- 完了条件を先に固定する — 着手前に「何が観測できたら完了か」を書く。
書けないなら作業を始めない。
- 検証方法を書けない作業は、まだ理解できていないと見なす — 「どう確かめるか」が
言えない時点で、対象の理解が不足している。調査に戻る。
- 実装前にリスクが高い箇所を特定する — 不可逆操作・共有状態・承認境界・
外部影響を先に列挙する。次の一手は常に「いま最もリスクが高い場所」から。
- 「動くはず」ではなく、観測された証拠を信じる — 完了・修正・マージなどの
完了系の主張は、一次証跡（コマンド出力・SHA・CI 結果・grep 件数）で実測してから報告する。
番号や名前の一致ではなく、SHA・内容の紐付けで同一性を判定する。
- 宣言と実態を突合する — ドキュメントの「DONE」「適用済み」を信じず、
実ファイル・実コミットで確認する。宣言と実態の乖離（偽の完了）は最優先で是正する。
- 着手前に並行作業を確認する — 同じ issue・同じ領域を別の PR / セッションが
既に実装していないかを確認してから着手する（重複実装は棄却コストが高い）。
- 差分を小さく保つ — 要求に紐づかない変更を混ぜない。stage は明示パス指定で行い、
コミット前に staged 内容を必ず確認する。
- 破壊的変更は承認ゲートを必須にする — 削除・上書き・force 系・本番影響は
approval-gate-template.md を通す。迷ったら承認側に倒す。
- サブエージェント利用を目的化しない — 委託は「複雑さ・独立性・並列性」の判断が先。
委託しても統合責任者として自ら検証する。委託結果を無検証で採用しない。
レビュー指摘の追対応など同一文脈の続きは、新規 spawn せず同一エージェントへの
追指示（SendMessage）で行う（文脈再構築のコストと齟齬を避ける）。
- 作業後は memory に判断・却下理由・未解決事項を残す — 未来のセッションが
同じ調査・同じ失敗を繰り返さないために。確定していない事項は PENDING を明記する。
- 監査記録は遡及編集しない — 時点記録（計画の各ラウンド・decision record・run ログ）
への事後修正は、レビュー指摘対応であっても改竄になる（「レビュアーが何を見て
判定したか」が消える）。修正は事後注記の追記で行い、本文は不変に保つ。
- 検証コマンドは計画時に実機で通す — 「機械検証」と書いたコマンドが動かなければ、
検証設計ごと偽物になる。計画段階で実機実行し、PASS する入力と FAIL する入力の
両方向で挙動を確認する（環境差 — BSD/GNU sed 等 — でサイレントに空を返す穴に注意）。
Phase Rules
Plan Phase
実装前に必ず定義する（テンプレート: plan-gate-loop.md §1）:
Goal / Non-goals / Scope / Constraints / Existing Design Fit（既存設計との適合）/
Risk Areas / Assumptions / Unknowns / Required Files / Expected Diff /
Verification Method / Rollback Plan / Human Approval Required Conditions
- Unknowns が Goal に影響するなら、実装ではなく調査タスクを先に切る。
- Expected Diff（触るファイルの宣言）は Execute 後の差分検証の基準になる。
Review Phase
計画レビューの観点（テンプレート: review-gate-template.md）:
要件整合 / 既存設計整合 / 過剰実装 / セキュリティ / データ破壊リスク /
テスト容易性 / 保守性 / 将来拡張性 / 実装コスト / 代替案比較 /
未検証の前提 / 人間承認が必要な箇所
- レビューは生成者と独立した視点で行う（自己レビューのみで通さない。
可能なら別モデル・別セッション・adversarial 観点を 1 系統以上）。
- レビュアー自身にも停止規律を課す: 実害のある欠陥のみ差し戻し（
needs_revision。
根本不成立なら rejected = Intake へ）とし、注記・記録で管理可能な懸念は
approved + 記録に回す（完璧主義による無限差し戻しは非停止の一形態）。
needs_revision → 計画改訂 → 再レビューは**ラウンド上限（3）**内で収束させ、超過時は人間へ。
Approval Phase
以下は明示的な人間承認がない限り禁止（テンプレート:
approval-gate-template.md）:
破壊的操作 / データ削除 / 大規模リファクタ / 認証・権限・課金・本番設定の変更 /
CI/CD・デプロイ設定変更 / 外部 API・料金・規約に影響する変更
ゲートの出力は Requires Human Approval: yes / no + Risk Level
（approval-gate-template.md）。yes の場合、人間の承認判断の結果を
approved / needs_revision / blocked / rejected で記録する（Review Gate と共通の 4 値）。
自分で設置した再承認ゲートを、包括承認や自己解釈で解除しない。
Execute Phase
- 計画外の変更をしない。変更理由を説明できない差分を作らない。
- 既存の命名規則・設計・責務分離に合わせる。依存関係をむやみに追加しない。
- エラーを握りつぶさない。テストしにくい構造にしない。
- 途中で前提が崩れたら実装を止めて Plan Phase に戻る（迂回や別アプローチを
勝手に始めない）。
Verify Phase
必ず区別して記録する（テンプレート:
verification-report-template.md）:
実行したコマンド / 実行結果 / 成功した検証 / 失敗した検証 / 未実行の検証 /
未確認のリスク / 人間が確認すべき項目
- 検証コマンドはプロジェクトに存在するものを使う（lint / typecheck / test / build /
format check / unit / integration / e2e / manual）。存在しないコマンドを勝手に
追加・捏造しない。
- 検証コマンドは計画時に実機で事前検証済みであること（原則 12。portable でない
コマンドがサイレントに空を返し「PASS したつもり」になる事故の防止）。
- 失敗はそのまま報告する。失敗を隠した「完了」は偽の完了として扱う。
Remember Phase
plan-memory.md に残す: 採用した判断 / 却下した案と理由 /
既存設計上の制約 / 繰り返し発生しそうな失敗 / 次回参照すべき検証コマンド /
未解決リスク / 次に見るべきファイル / 次の一手。
- 完了系の記述は確定後のみ書く。未確定は
PENDING-VERIFY を前置する
（セッション跨ぎの汚染防止）。
Report Phase
最終報告に必ず含める: 実施内容 / 変更ファイル / 検証結果 / 未検証事項 /
残リスク / 判断が必要な点（優先度付き）/ 次の推奨アクション。
「完了」と言う場合は、観測可能な検証結果を添える。 検証結果のない完了報告は
partial として扱う。
判定値の対応（既存契約とのマッピング）
リポジトリ内に並立する判定 enum の対応と優先関係。再定義せず、文脈で正本を切り替える:
| 文脈 | 使う値体系 | 正本 |
|---|
| 計画レビューの判定 | approved / needs_revision / blocked / rejected | 本 skill（review-gate）。PlanGate C-3 の APPROVE / CONDITIONAL / REJECT とは approved↔APPROVE / needs_revision↔CONDITIONAL / rejected↔REJECT で対応（blocked は「情報不足で判定不能」の追加状態） |
| 人間承認の要否 | yes / no + Risk Level | 本 skill（approval-gate）。HO 接触は mode-classification.md が最優先 |
| 検証レポートの完了判定 | complete / partial / not_complete | 本 skill（verification-report） |
| サブエージェントの最終行 | OUTCOME: success / partial / failure | docs/ai/subagent-delegation/outcome-contract.md（委譲時はこちらが最終判定の正本。complete↔success / partial↔partial / not_complete↔failure） |
注: outcome-contract.md の review=true（レビュータスクの判定緩和フラグ）と
本 skill の「Review Phase」（ループの段階名）は無関係な別概念。混同しない。
既存資産との棲み分け（demarcation）
本 skill はループ運用の型とテンプレート集であり、以下の正本を再定義しない。
矛盾したら常に正本が優先（本 skill 側を修正する）:
| 正本 | 責務（本 skill はこれを再定義しない） |
|---|
docs/ai/core-contract.md | Iron Law / Stop rules / Output discipline（実行契約の正本） |
.claude/rules/review-principles.md | レビュー観点・Severity・auto-approve 判定（C-2 / CI / コードレビュー） |
.claude/rules/mode-classification.md | 5 段階モード・HO 9 カテゴリ・lite_eligible（承認境界の機械判定） |
.claude/rules/responsibility-classes.md | AI/Human/CI/Workflow の責務 4 分類・自己設置 Gate 非緩和 |
.claude/rules/working-context.md | C-3/C-4 ゲート・handoff・作業コンテキスト構造 |
docs/ai/subagent-delegation/ | 派遣プロンプト 8 要素・OUTCOME 契約・行動規範（委譲の契約層） |
.claude/skills/diff-audit | commit/PR 前のセルフレビュー手順（本 skill の Verify を補完する実行手段、旧 self-review） |
.claude/skills/subagent-driven-development | 委託実装の 2 段階レビュー開発手法 |
本 skill の固有価値は「8 フェーズループとしての接続」（各正本をいつ・どの順で使い、
どこで止まるか）と「偽の完了を防ぐ検証・記録の型」にある。
関連ファイル
