メニュー
Plan ファイルを Issue 化前に監査し、必須セクションの充足と影響範囲の網羅をチェックする。「check-plan」「plan をチェック」と指示されたとき。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/kasiopeiya/claude-dev-template --skill check-planコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
| name | check-plan |
| description | Plan ファイルを Issue 化前に監査し、必須セクションの充足と影響範囲の網羅をチェックする。「check-plan」「plan をチェック」と指示されたとき。 |
Plan ファイルを Issue 化（/to-issues）の前 に監査する。後工程で発覚すると手戻りが大きい「必須セクションの欠落」「影響範囲の見落とし」を、最も安いこの段階で潰す（シフトレフト）。通常は /to-plan から自動で呼ばれるが、単体でも実行できる。
~/.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 に含まれていないか確認する。あわせて、 を Plan に当てる。各原則のに状況を引き当てたうえで、特に Plan 段階で効く次の観点を確認し、反していれば指摘する：
docs/policy/refined-engineer-judgment-principles.md⚠️/grill-me で断つが、未実施なら最左の砦はここ）[!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・推奨） 判定の鋭さは更新先文書が目的を明示しているかに依存する。推測ベースで ⚠️ 止まりにしかできない場合は、その旨を報告に明記する。
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 を変更するのに静的解析を実行するタスクが未記載 |
| ... | ... | ... |
/to-issues <Planパス> で Issue 化できます」と案内する。RFC等の入力資料をもとに対話しながら要求を引き出し、requirements.md（PRD）を作成する。顧客が書いた「解決策」を「目的」に還元し、「制約」とされた事項が本当に制約かを疑いながら、目的の認識を合わせて要件を確定する。要求分析・要件定義・requirements.md作成を依頼されたとき、または「elicit-requirements」と指示されたときに使う。
要件定義書（docs/requirements.md）を requirements-doc-policy の基準でレビューし、凍結してよい品質かを合否判定する。「requirements-review」「要件定義書をレビューして」と指示されたとき。
アプリの設計・アーキテクチャの「質」をレビューする。UI/DB/外部サービス/言語などの詳細を差し替え可能に保てているかを検査する。「arch-review」「設計をレビューして」「アーキテクチャをレビューして」と指示されたとき。