菜单
Plan ファイルを早期監査する（シフトレフト）。必須セクションの充足と、コードベース・ドキュメントへの影響範囲の網羅を Issue 化前にチェックする。「check-plan」「plan をチェック」と指示されたとき、または /to-plan から自動で呼ばれる。Plan の不足を指摘し、修正してから次工程へ進めるようにする。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
いま進行中のセッションの会話の流れを5項目で要約し、コンテキストスイッチから戻った人間が状況を思い出すのを助ける。「catchup」「ここまで要約して」「どこまでやったか」「文脈を思い出したい」と指示されたときに使う。
CDK実装の一気通貫オーケストレーションワークフロー。CDK実装→コードレビュー→レビュー指摘修正→CI実行→CI指摘修正を人間への確認なしに自律実行する。CLAUDE.md の開発フロー Step 7（CDK実装）で使用。Issue番号を引数に指定すること（例: /cdk-dev 15）。frontend/backend実装には使用しない。
アプリケーション実装の一気通貫オーケストレーションワークフロー。実装（テスト変更を含む場合はTDD、含まない場合は直接実装）→コードレビュー→レビュー指摘修正→CI実行→CI指摘修正→設計書整合性チェック→設計書修正を人間への確認なしに自律実行する。CLAUDE.md の開発フロー Step 6（frontend/backend実装）で使用。Issue番号を引数に指定すること（例: /code-dev 15）。CDKには使用しない。
統合設計ワークフロー。GitHub IssueをもとにIssueを読み込み設計書（docs/design/）を更新し、自動レビューと修正まで実行する。仕様駆動開発のStep 4で使用。Issue番号を引数に指定すること（例: /design 15）
AWS CDK実装専用コマンド。GitHub IssueからCDK実装・テスト・CDK合成まで自動実行する。CDKインフラの実装を依頼されたときに使用すること。
AWS CDK インフラコードを詳細にレビュー。/cdk-review コマンドが呼ばれたとき、またはユーザーが CDK コードのレビューを依頼したときに使用する。cdk/ ディレクトリ内の TypeScript ファイルを対象に、型安全性・CDK ベストプラクティス・プロジェクトルール準拠を自動チェックする。
| name | check-plan |
| description | Plan ファイルを早期監査する（シフトレフト）。必須セクションの充足と、コードベース・ドキュメントへの影響範囲の網羅を Issue 化前にチェックする。「check-plan」「plan をチェック」と指示されたとき、または /to-plan から自動で呼ばれる。Plan の不足を指摘し、修正してから次工程へ進めるようにする。 |
Plan ファイルを Issue 化（/to-issues）の前 に監査する。後工程で発覚すると手戻りが大きい「必須セクションの欠落」「影響範囲の見落とし」を、最も安いこの段階で潰す（シフトレフト）。通常は /to-plan から自動で呼ばれるが、単体でも実行できる。
~/.claude/plans/ の最新ファイル、または会話コンテキスト上の Plan。着手前に docs/design-hub.md・docs/policy/policy-hub.md・docs/policy/refined-engineer-judgment-principles.md（判断の北極星）・該当 ADR（docs/adr/）を参照する（CLAUDE.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 段階で効く次の観点を確認し、反していれば指摘する：
[!NOTE] 上の観点は
refined-engineer-judgment-principles.mdからの要約（発火しやすさのための転記）。**正典は常に同ファイル（SSOT）**であり、食い違えば原文を優先する。原則が改定されたら、ファイル名refined-engineer-judgment-principles.mdで横断検索（grep）し、この箇所も追従更新すること。
会話履歴を一切持たない別セッション が、この Plan だけ読んで意図と判断を再構築できるかを確認する。次が欠けていれば指摘する: 目的・WHY、却下した代替案とその理由、前提・制約・スコープ境界（やらないこと）、受け入れ基準。逆に、陳腐化する実装詳細（具体的なファイルパス・コードスニペット・レイヤーごとの実装手順）が紛れていれば削減を促す。
各「設計書更新タスク」について、更新先の文書を実際に開き、その対象読者・目的（・スコープ外）を読んだうえで、計画している追記・変更がその目的に奉仕するかを照合する。文書冒頭に目的の宣言があればそれを基準にし、無ければ冒頭・見出し構成から目的を推測して判断する。他文書の目的に属する／スコープ外の内容なら ❌ とし、正しい配置先の提案、または当該タスクの削除を促す。
これは観点 C（記載漏れ＝書くべき文書を挙げていない）の逆方向で、取り違え（目的に合わない文書への割当） を捕まえる。ここで見逃すと、issue 化後に別セッションの AI が「issue がそう指示したから」と目的違反の内容を忠実に書いてしまう。発生源で断つのが本観点の役割。
[!TIP] 判定の鋭さは更新先文書が目的を明示しているかに依存する。推測ベースで ⚠️ 止まりにしかできない場合は、その旨を報告に明記する。
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 が未記載 |
| ... | ... | ... |
/to-issues <Planパス> で Issue 化できます」と案内する。