check-plan

# Check Plan Plan ファイルを **Issue 化（`/to-issues`）の前** に監査する。後工程で発覚すると手戻りが大きい「必須セクションの欠落」「影響範囲の見落とし」を、最も安いこの段階で潰す（シフトレフト）。通常は `/to-plan` から自動で呼ばれるが、単体でも実行できる。 ## 対象 Plan の特定 1. 引数でパス・slug が渡されたらそれを使う。 2. 無ければ `~/.claude/plans/` の最新ファイル、または会話コンテキスト上の Plan。 3. どれも特定できなければユーザーに確認する。 ## チェック観点 **着手前に** `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](../../../docs/policy/new-development-policy.md) に照らし、薄い縦スライス（曳光弾/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](../../../docs/policy/dependency-policy.md) の早見表の問いを通したか確認する。赤信号があれば代替（自前実装・標準機能・軽量パッケージ）を促す。依存は導入後に剥がしにくいので、最左のこの段階で問うのが最も安い（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/`・`samples/`・`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 化できます」と案内する。