| name | check-plan |
| description | Plan ファイルを Issue 化前に監査し、必須セクションの充足と影響範囲の網羅をチェックする。「check-plan」「plan をチェック」と指示されたとき。 |
Check Plan
Plan ファイルを Issue 化（/to-issues）の前 に監査する。後工程で発覚すると手戻りが大きい「必須セクションの欠落」「影響範囲の見落とし」を、最も安いこの段階で潰す（シフトレフト）。通常は /to-plan から自動で呼ばれるが、単体でも実行できる。
対象 Plan の特定
- 引数でパス・slug が渡されたらそれを使う。
- 無ければ
~/.claude/plans/ の最新ファイル、または会話コンテキスト上の Plan。
- どれも特定できなければユーザーに確認する。
チェック観点
着手前に docs/design-hub.md・docs/policy-hub.md・docs/policy/refined-engineer-judgment-principles.md（判断の北極星）を参照する（CLAUDE.md 「必読ドキュメント」）。加えて、Plan が触れる領域に該当 ADR（docs/adr/）があれば読む。
必須セクションの充足
| 項目 | 合格条件 |
|---|
| 設計書・要件定義への影響 | セクションが存在し埋まっている。設計書に加え docs/requirements.md（要件定義）の更新要否も判断されている。更新不要なら「更新不要・理由：〇〇」が明記されている（空欄・省略は不合格） |
| 更新タスク | 影響が「更新不要」でない限り、タスク一覧に設計書・requirements.md の更新タスクが含まれる |
| 背景・目的（WHY） | 実装者が優先順位を自力判断できる粒度で書かれている（HOW の羅列は不合格） |
| grill-me 確定仕様 | 確定仕様・設計判断の根拠・却下した代替案が転記されている。未実施なら「grill-me 未実施」と明記 |
影響範囲の網羅（コードベース）
Plan が挙げる変更箇所と、実際のコードベースを照合する。コードを探索し、Plan に書かれていない波及先（呼び出し元・共有モジュール・テスト・型定義など）が無いかを確認する。漏れがあれば具体名を挙げて指摘する。
影響範囲の網羅（ドキュメント）
docs/design-hub.md を起点に、変更が影響する設計書を洗い出す。Plan の「設計書への影響」と突き合わせ、ハブから辿れるのに記載漏れしている設計書が無いかを確認する。ADR が必要な意思決定（/create-adr 対象）が含まれていないかも見る。
ポリシー整合・判断原則との照合
docs/policy/ の指針・該当 ADR に反する方針が Plan に含まれていないか確認する。あわせて、docs/policy/refined-engineer-judgment-principles.md を Plan に当てる。各原則のトリガーに状況を引き当てたうえで、特に Plan 段階で効く次の観点を確認し、反していれば指摘する：
- 決定を遅らせる：確信のない詳細（DB / FW / 外部サービス）を今 Plan で固定していないか
- 新規開発（0 からの立ち上げ）の場合：new-development-policy に照らし、薄い縦スライス（曳光弾/walking skeleton）先行・スパイクは使い捨て・ドメイン/コアから着手の方針か。水平な層ごとの作り込みや FW/DB から始める計画なら
⚠️
- YAGNI／コードは負債：その追加は本当に要るか、作らない選択肢を検討したか。とくに 仕様（requirements 等）に裏付けのない投機的な要件・機能が Plan に紛れ込んでいないか（「将来要るかも」での追加は YAGNI 違反。発生源は
/grill-me で断つが、未実施なら最左の砦はここ）
- Less is more（シンプル）：もっと小さい打ち手で同じ効果を狙えないか
- シフトレフト：Plan が挙げる検証は、置ける最も早い工程にあるか
[!IMPORTANT]
（AI・必須） 上の観点は refined-engineer-judgment-principles.md からの要約（発火しやすさのための転記）。**正典は常に同ファイル（SSOT）**であり、食い違えば原文を優先する。原則が改定されたら、ファイル名 refined-engineer-judgment-principles.md で横断検索（grep）し、この箇所も追従更新すること。
あわせて、Plan が 新規ライブラリ追加（package.json への依存追加） を含むなら dependency-policy の早見表の問いを通したか確認する。赤信号があれば代替（自前実装・標準機能・軽量パッケージ）を促す。依存は導入後に剥がしにくいので、最左のこの段階で問うのが最も安い（dependency-policy が正典）。
コールドスタート再現性
会話履歴を一切持たない別セッション が、この Plan だけ読んで意図と判断を再構築できるかを確認する。次が欠けていれば指摘する: 目的・WHY、却下した代替案とその理由、前提・制約・スコープ境界（やらないこと）、受け入れ基準。逆に、陳腐化する実装詳細（具体的なファイルパス・コードスニペット・レイヤーごとの実装手順）が紛れていれば削減を促す。
設計書更新タスクの配置先妥当性（目的適合）
各「設計書更新タスク」について、更新先の文書を実際に開き、その対象読者・目的（・スコープ外）を読んだうえで、計画している追記・変更がその目的に奉仕するかを照合する。文書冒頭に目的の宣言があればそれを基準にし、無ければ冒頭・見出し構成から目的を推測して判断する。他文書の目的に属する／スコープ外の内容なら ❌ とし、正しい配置先の提案、または当該タスクの削除を促す。
これは観点「影響範囲の網羅（ドキュメント）」（記載漏れ＝書くべき文書を挙げていない）の逆方向で、取り違え（目的に合わない文書への割当） を捕まえる。ここで見逃すと、issue 化後に別セッションの AI が「issue がそう指示したから」と目的違反の内容を忠実に書いてしまう。発生源で断つのが本観点の役割。
[!TIP]
（AI・推奨） 判定の鋭さは更新先文書が目的を明示しているかに依存する。推測ベースで ⚠️ 止まりにしかできない場合は、その旨を報告に明記する。
実行Skillの明記（開発フロー追従）
Plan の「実装フロー（使用するSkill）」を確認する。Plan が触れる変更種別（設計書・アプリ・CDK）それぞれに、対応する開発フローSkillが実行順に明記されているか照合する。対応は CLAUDE.md「開発フロー」を正典とする（設計書→/design、アプリ実装→/code-dev、CDK→/cdk-dev）。種別があるのに Skill 未記載・対応違い・順序欠落なら ❌。
加えて、Plan の変更がマクロ構造・境界（UI/DB/外部サービス/言語の差し替え可能性・依存方向・レイヤー構成）に影響するなら、任意レビュー /arch-review が実装フローに含まれているか確認する。これは変更種別1:1で決まる必須Skillではなく条件付き——該当する変更なのに未記載なら ⚠️ 推奨（実装フローへの追加を促す）、無関係なら不問とする。/arch-review の記載自体を未知Skillとして ❌ にしてはならない。
これは issue 番号だけで開発フローを再現するための情報であり、/to-issues で各 Issue に転記される。ここで欠けると下流の自動追従（「issue NNN 対応して」）が成立しないため、issue 化前に必ず揃える。
静的解析タスクの明記
Plan が TypeScript（app/・infra/・eslint-rules/ 等）または静的解析設定（eslint.config.mjs・tsconfig.json・knip.jsonc・package.json の scripts 等）を変更するなら、タスク一覧に 静的解析を実行するタスク（npm run check:static、または該当する test:hooks・knip 等）が含まれているか確認する。含まれていなければ ❌。
狙いは、push 後に GitHub Actions で初めて落ちるのを防ぎ、ローカルで潰し切ること。アドホック編集はターン末ゲートの Stop フック（turn-end-gate.mjs）が担うが、Plan 経由の変更はこの観点でタスク化を担保する。
報告
各観点を ✅ / ⚠️ / ❌ で表にして報告する。
| 観点 | 判定 | 指摘・修正提案 |
|---|
| 必須セクションの充足 | ❌ | 「設計書への影響」が空欄。更新要否を判断して記載が必要 |
| 影響範囲の網羅（コード） | ⚠️ | 〇〇 の呼び出し元 △△ が Plan 未記載 |
| 配置先妥当性 | ❌ | 「文書Yに手順を追記」タスクが Y の目的（選定理由）に不適合。運用設計書へ移すべき |
| 実行Skillの明記 | ❌ | CDK変更があるのに「実装フロー」に /cdk-dev が未記載 |
| 静的解析タスクの明記 | ❌ | .claude/ の TS を変更するのに静的解析を実行するタスクが未記載 |
| ... | ... | ... |
- ❌・⚠️ があれば、Plan ファイルを修正してから再報告する（自動修正できない判断はユーザーに確認）。
- すべて ✅ なら「次は
/to-issues <Planパス> で Issue 化できます」と案内する。
