Skip to main content

check-plan

Plan ファイルを Issue 化前に監査し、必須セクションの充足と影響範囲の網羅をチェックする。「check-plan」「plan をチェック」と指示されたとき。

الانتقال إلى التثبيت

معلومات المصدر

المستودع
kasiopeiya/claude-dev-template
آخر نشاط في المصدر
١٤ سبتمبر ٢٠٢٦ في ٠٦:٠٠
لغة SKILL.md المكتشفة
اليابانية
النجوم
٠
التفرعات
٠

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
name
check-plan
description
Plan ファイルを Issue 化前に監査し、必須セクションの充足と影響範囲の網羅をチェックする。「check-plan」「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 化できます」と案内する。
عرض على GitHub