Plan Review スキル

リスク判定で「Plan 必須」と判定されたタスクに対して、着手前に 計画の批判レビュー を行い、最終 Plan をユーザー承認に回すオーケストレーター。

トリガー

• CLAUDE.md「着手時の自動フロー」でリスク判定が L2 / L3 と判定されたとき
• /pick の新 Step 3 から呼び出し
• ユーザーが明示的に /plan-review 実行時
• フリー依頼でも、実装者が計画の外部レビューを欲しい局面で任意起動

インプット

呼び出し元から以下を受け取る：

• $TASK_CONTEXT: タスクの目的 / 完了条件 / 関連 Issue 番号
• $RISK_FLAGS: リスク判定質問票で Yes になった項目（Security Planner 起動条件判定に使う）

インプットが不足している場合は最初にユーザーに確認する（フォーマットは下記「ユーザー確認の出し方」に従うこと）。

ユーザー確認の出し方（このスキル全体の共通ルール）

このスキル（および配下の Synthesizer）からユーザーに判断を委ねるときは、必ず以下を満たす形で提示する。単純な「A か B か」だけで止めない。

1. 選択肢を 2 つ以上並べる（暗黙の単一案や「どうしますか？」だけは不可）
2. 各選択肢に pro / con を各 1-3 行で添える（冗長化禁止。1 選択肢あたり最大 3 行/種別）
3. 推奨を 1 つ明示する（理由付き 1-2 行）。客観的に決められない場合は「中立。理由: 判断材料が足りない / ケースバイケース」と書き、判定の手がかりを 1 行添える

提示テンプレート：

**A. <選択肢 A の見出し>**
- Pro: ...
- Con: ...

**B. <選択肢 B の見出し>（推奨）**
- Pro: ...
- Con: ...

**推奨理由**: ...

このルールは Step 5 の escalate 二択にも適用される。Synthesizer に二択を生成させる際は、pro / con と推奨を含めた形 で出力するよう指示すること。

実行手順

Step 1. リポ特性シート作成

repo-detector スキルを呼び出し、リポ特性シート を生成する（60 行以内）。以降全 Planner にこのシートを共通インプットとして渡す。

Step 2. Plan 草案作成

固定フォーマットで Plan 草案を書く：

markdown
1# Plan Draft
2
3## Goal
4[何を達成するか]
5
6## Non-goal
7[やらないこと]
8
9## Decision
10[採用する設計 / 実装方針]
11
12## Rejected alternatives
13- [棄却案 1]: [棄却理由]
14- [棄却案 2]: [棄却理由]
15
16## Must-hold constraints
17- [非交渉な制約 1]（Post-Impl で機械照合される）
18- [非交渉な制約 2]
19
20## Acceptance tests
21- [受け入れテスト 1]
22- [受け入れテスト 2]
23
24## References
25- [参照したファイル パス:行番号 / 参照理由]
26
27## Open questions
28- [未決事項 / なし]

草案は会話内に保持する（中間ファイル化は任意）。

Step 3. 5 Planner 並列起動

Agent ツールで以下 5 体を同一メッセージ内で並列に起動する。Security Planner / Reliability Planner は $RISK_FLAGS の内訳によらず 常に起動 する（L2 以上の計画必須条件を満たしている時点で信頼境界・信頼性運用の影響を評価する価値がある）。

注: subagent_type は各 agent の name フィールド（タイトルケース）に揃える。エージェント定義は .claude/agents/<lowercase-kebab>.md に存在し、Claude Code が name を識別子として使う。

重要: 5 つの Agent ツール呼び出しを同一メッセージ内で並列に実行すること。

各 Planner には以下を共通インプットとして渡す：

• Plan 草案全文
• リポ特性シート
• 関連ファイルリスト（Step 2 の References から抽出）
• 判定値は 3 値（accept / revise / escalate）で返すこと

Step 4. Planning Synthesizer で統合

subagent_type: Planning Synthesizer（model: opus）で Agent ツールを起動し、5 Planner の結果と現在のラウンド番号（初回は 1）を渡して統合判定を受け取る。

Step 5. 判定分岐

accept

• Synthesizer の 4 点サマリを Plan に反映して 最終 Plan を確定
• Step 6 へ（ユーザー承認）

revise (ラウンド 1)

• Synthesizer の「Plan 反映指示の差分表」に従って Plan 草案を修正
• 修正した Plan 草案で Step 3 に戻る（ラウンド 2 として）
• ラウンド 2 でも accept にならなければ強制的に escalate（Synthesizer が自動昇格）

escalate

• Synthesizer が生成した「ユーザー向け二択」を 「ユーザー確認の出し方」フォーマットに整形してユーザーに提示する。Synthesizer の出力に pro / con と推奨が含まれていない場合、提示前に補完すること（Synthesizer の出力をそのまま貼らない）
• ユーザー回答を受けて Plan 草案を修正
• 回答が明確で衝突が解けるなら Step 3 をスキップして accept として扱う
• 回答後もまだ曖昧なら、更新した Plan 草案で Step 3 をやり直す（ラウンド 1 からやり直し）

Step 6. 最終 Plan をユーザー承認に回す

1. EnterPlanMode を呼ぶ
2. Plan モードで plan file に最終 Plan を書き出す（Step 2 のフォーマット + Synthesizer の差分反映済み）
3. ExitPlanMode を呼んでユーザー承認を要求
4. 承認されたら通常モードに戻り、実装フェーズへ

Step 7. 最終 Plan の永続化と戻り値

永続化（必須）

最終 Plan を .claude/plans/<task-id>.md にファイルとして保存する。これにより：

• セッション分断・長時間作業でも消えない
• Post-Impl の /review-code (Plan Conformance 検査) が $FINAL_PLAN 未指定でも fallback で読める
• レビュアー（人間）が PR レビュー時に同 commit で計画意図を確認できる

<task-id> の決定ルール（順に試して最初に決まったものを採用）：

1. $TASK_CONTEXT に Issue 番号が含まれる → issue-<NN>
2. 現在の git ブランチ名 → そのまま使用（例: planning-flow-overhaul）
3. 上記が無理なら ISO 日時スラッグ → plan-<YYYYMMDD-HHMM>

ファイル形式：

markdown
1---
2task_id: <task-id>
3issue: <Issue 番号 or なし>
4risk_level: L2 | L3
5risk_flags: [リスクトリガー Yes 項目をリスト]
6status: accept | escalate_resolved
7created: <ISO datetime>
8---
9
10# Plan: <タスクタイトル>
11
12## Goal
13...
14
15## Non-goal
16...
17
18## Decision
19...
20
21## Rejected alternatives
22- ...
23
24## Must-hold constraints
25- ...
26
27## Acceptance tests
28- ...
29
30## References
31- ...
32
33## Open questions
34- ...
35
36## Synthesizer 4 点サマリ
37- 目的:
38- 採用案:
39- 主要トレードオフ:
40- Open Questions:

戻り値（呼び出し元への引き継ぎ）

以下を呼び出し元に返す：

• $PLAN_PATH: 保存した plan ファイルのパス（例: .claude/plans/issue-42.md）
• 最終 Plan の本文（会話内でも使えるように）
• 特に Must-hold constraints と Acceptance tests は Post-Impl の Plan Conformance 検査で機械照合される

/pick から呼ばれた場合は /close および /review-code に $PLAN_PATH をそのまま渡す。フリー依頼の場合は会話コンテキストに $PLAN_PATH を保持して、後続の /review-code で参照させる。

制約

• 5 Planner は常に並列（逐次呼び出し禁止。独立性が崩れるため）
• Synthesizer は必ず経由（5 Planner 結果を直接ユーザーに見せない。衝突解消責任を Synthesizer に持たせる）
• ラウンド上限は 2（それ以上は escalate）
• ユーザー承認対象は 4 点サマリ を中心に。詳細資料は参照用
• Plan 草案を作らずに Planner を起動しない（何を評価するか不明瞭になるため）

判定値

最終 Plan に付随するステータス：

• accept: ユーザー承認後 → 実装フェーズへ
• escalate_resolved: Open Questions に対するユーザー回答を反映済み → 実装フェーズへ
• aborted: ユーザーが承認せず Plan 自体を破棄 → 着手を停止し報告

後続処理との連携

• 実装フェーズ: 最終 Plan の Must-hold constraints を実装者が常時参照
• Post-Impl (/review-code): 最終 Plan の Must-hold constraints と Acceptance tests を Plan Conformance 検査の前処理で機械照合
• Stop-the-line: 実装途中で想定外モジュール追加 / テスト戦略破綻 / 権限変更発覚 / 要件曖昧化が発生した場合、実装を中断し本スキルを再呼び出しして再計画する