check-plan

name	check-plan
description	Plan ファイルを早期監査する（シフトレフト）。必須セクションの充足と、コードベース・ドキュメントへの影響範囲の網羅を Issue 化前にチェックする。「check-plan」「plan をチェック」と指示されたとき、または /to-plan から自動で呼ばれる。Plan の不足を指摘し、修正してから次工程へ進めるようにする。

Check Plan

Plan ファイルを Issue 化（/to-issues）の前 に監査する。後工程で発覚すると手戻りが大きい「必須セクションの欠落」「影響範囲の見落とし」を、最も安いこの段階で潰す（シフトレフト）。通常は /to-plan から自動で呼ばれるが、単体でも実行できる。

対象 Plan の特定

1. 引数でパス・slug が渡されたらそれを使う。
2. 無ければ ~/.claude/plans/ の最新ファイル、または会話コンテキスト上の Plan。
3. どれも特定できなければユーザーに確認する。

チェック観点

着手前に docs/design-hub.md・docs/policy/policy-hub.md・docs/policy/refined-engineer-judgment-principles.md（判断の北極星）・該当 ADR（docs/adr/）を参照する（CLAUDE.md 必読ルール）。

A. 必須セクションの充足

項目	合格条件
設計書への影響	セクションが存在し埋まっている。更新不要なら「更新不要・理由：〇〇」が明記されている（空欄・省略は不合格）
設計書更新タスク	影響が「更新不要」でない限り、タスク一覧に設計書更新タスクが含まれる
背景・目的（WHY）	実装者が優先順位を自力判断できる粒度で書かれている（HOW の羅列は不合格）
grill-me 確定仕様	確定仕様・設計判断の根拠・却下した代替案が転記されている。未実施なら「grill-me 未実施」と明記

B. 影響範囲の網羅（コードベース）

Plan が挙げる変更箇所と、実際のコードベースを照合する。コードを探索し、Plan に書かれていない波及先（呼び出し元・共有モジュール・テスト・型定義など）が無いかを確認する。漏れがあれば具体名を挙げて指摘する。

C. 影響範囲の網羅（ドキュメント）

docs/design-hub.md を起点に、変更が影響する設計書を洗い出す。Plan の「設計書への影響」と突き合わせ、ハブから辿れるのに記載漏れしている設計書が無いかを確認する。ADR が必要な意思決定（/create-adr 対象）が含まれていないかも見る。

D. ポリシー整合・判断原則との照合

docs/policy/ の指針・該当 ADR に反する方針が Plan に含まれていないか確認する。あわせて、docs/policy/refined-engineer-judgment-principles.md を Plan に当てる。各原則のトリガーに状況を引き当てたうえで、特に Plan 段階で効く次の観点を確認し、反していれば指摘する：

• 原則2（決定を遅らせる）：確信のない詳細（DB / FW / 外部サービス）を今 Plan で固定していないか
• 原則4（コードは負債）：その追加は本当に要るか。作らない選択肢を検討したか
• 原則5（シンプル）：もっと小さい打ち手で同じ効果を狙えないか
• 原則3（シフトレフト）：Plan が挙げる検証は、置ける最も早い工程にあるか

[!NOTE] 上の観点は refined-engineer-judgment-principles.md からの要約（発火しやすさのための転記）。**正典は常に同ファイル（SSOT）**であり、食い違えば原文を優先する。原則が改定されたら、ファイル名 refined-engineer-judgment-principles.md で横断検索（grep）し、この箇所も追従更新すること。

E. コールドスタート再現性

会話履歴を一切持たない別セッション が、この Plan だけ読んで意図と判断を再構築できるかを確認する。次が欠けていれば指摘する: 目的・WHY、却下した代替案とその理由、前提・制約・スコープ境界（やらないこと）、受け入れ基準。逆に、陳腐化する実装詳細（具体的なファイルパス・コードスニペット・レイヤーごとの実装手順）が紛れていれば削減を促す。

F. 設計書更新タスクの配置先妥当性（目的適合）

各「設計書更新タスク」について、更新先の文書を実際に開き、その対象読者・目的（・スコープ外）を読んだうえで、計画している追記・変更がその目的に奉仕するかを照合する。文書冒頭に目的の宣言があればそれを基準にし、無ければ冒頭・見出し構成から目的を推測して判断する。他文書の目的に属する／スコープ外の内容なら ❌ とし、正しい配置先の提案、または当該タスクの削除を促す。

これは観点 C（記載漏れ＝書くべき文書を挙げていない）の逆方向で、取り違え（目的に合わない文書への割当） を捕まえる。ここで見逃すと、issue 化後に別セッションの AI が「issue がそう指示したから」と目的違反の内容を忠実に書いてしまう。発生源で断つのが本観点の役割。

[!TIP] 判定の鋭さは更新先文書が目的を明示しているかに依存する。推測ベースで ⚠️ 止まりにしかできない場合は、その旨を報告に明記する。

G. 実行Skillの明記（開発フロー追従）

Plan の「実装フロー（使用するSkill）」を確認する。Plan が触れる変更種別（設計書・アプリ・CDK）それぞれに、対応する開発フローSkillが実行順に明記されているか照合する。対応は CLAUDE.md「開発フロー」を正典とする（設計書→/design、アプリ実装→/code-dev、CDK→/cdk-dev）。種別があるのに Skill 未記載・対応違い・順序欠落なら ❌。

これは issue 番号だけで開発フローを再現するための情報であり、/to-issues で各 Issue に転記される。ここで欠けると下流の自動追従（「issue NNN 対応して」）が成立しないため、issue 化前に必ず揃える。

報告

各観点を ✅ / ⚠️ / ❌ で表にして報告する。

観点	判定	指摘・修正提案
A. 必須セクション	❌	「設計書への影響」が空欄。更新要否を判断して記載が必要
B. コードベース影響	⚠️	〇〇 の呼び出し元 △△ が Plan 未記載
F. 配置先妥当性	❌	「文書Yに手順を追記」タスクが Y の目的（選定理由）に不適合。運用設計書へ移すべき
G. 実行Skill明記	❌	CDK変更があるのに「実装フロー」に /cdk-dev が未記載
...	...	...

• ❌・⚠️ があれば、Plan ファイルを修正してから再報告する（自動修正できない判断はユーザーに確認）。
• すべて ✅ なら「次は /to-issues <Planパス> で Issue 化できます」と案内する。