Check Plan

Plan ファイルを Issue 化（/to-issues）の前 に監査する。通常は /to-plan から自動で呼ばれるが、単体でも実行できる。

監査の本体は `plan-reviewer-agent` が行う。Plan を書いたセッションが自分で点検すると、書かれていない前提を会話の記憶で補ってしまい、欠落に気づけないからである。判定の観点は agent 定義が正典であり、ここには書き写さない。

このスキルが担うのは、会話を見ないとできないことだけである。

• 会話と Plan の突き合わせ
• Plan の修正とユーザーへの確認

1. 対象 Plan の特定

上から順に見て、最初に当たったものを対象にする。

1. 引数でパスが渡されたらそれを使う。slug なら ~/.claude/plans/<slug>.md、無ければ ~/.claude/plans/*-<slug>.md を探す。
2. この会話で /to-plan または Plan モードが書き出したファイル。
3. Plan が会話上のテキストにしか無ければ、先に /to-plan でファイルにする（agent はファイルしか読めない）。
4. どれも無ければユーザーに確認する。~/.claude/plans/ の最新ファイルは候補として示すだけにする（Plan モードが書き出した別件の Plan が混ざっているため）。

2. plan-reviewer-agent を起動する

plan-reviewer-agent を Task で起動する。渡すのは Plan ファイルの絶対パス（~ を展開したもの）だけにする。会話の要約・作業の経緯・「ここを見てほしい」といった注文は渡さない。渡した時点で agent は書き手の前提を共有し、切り離した意味が消える。

起動したら結果を待たずに手順3を進める。

3. 会話と Plan を突き合わせる

agent は会話を見られないので、次の転記漏れはここでしか見つからない。

• grill-me で確定した仕様：決定事項・判断の根拠・却下した代替案とその理由が、Plan の「grill-me で確定した仕様」に書かれているか
• Not-now リスト：全行が「やらないこと」欄に、トリガーと一緒に転記されているか
• Plan モードでの調査結果：判断の前提にした事実が Plan に残っているか

4. 統合して Plan を修正する

agent の表に、手順3の3項目を1行ずつ足す。会話に該当する内容が無い項目は N/A とする。

合否・再監査回数の規定は ai-review-gate-policy に従う。

• 違反があれば、重大度にかかわらずすべてPlan ファイルを修正する（ai-review-gate-policy「残してよい例外」に当たらない限り、確認を挟まず直す）。修正したら agent をもう一度起動し、指摘が解消したかを確かめる。再監査のたびに手順2と同じくパスだけを渡し、前回の指摘は渡さない。
• 監査は最大2回（初回を含む）。Critical が0件になった回で合格とし、「次は /to-issues <Planパス> で Issue 化できます」と案内する。
• 2回目の監査で指摘が出たら、Plan ファイルを修正したうえで再監査せずに「次は /to-issues <Planパス> で Issue 化できます」と案内する。

5. 報告

統合した表を報告する。形式は agent の出力形式に従う。