メニュー
grill-me の対話や事前調査の結果を Plan ファイルに構造化して書き出し、続けて /check-plan で監査する。「to-plan」「plan ファイルにして」と指示されたとき。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/kasiopeiya/claude-dev-template --skill to-planコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
RFC等の入力資料をもとに対話しながら要求を引き出し、requirements.md（PRD）を作成する。顧客が書いた「解決策」を「目的」に還元し、「制約」とされた事項が本当に制約かを疑いながら、目的の認識を合わせて要件を確定する。要求分析・要件定義・requirements.md作成を依頼されたとき、または「elicit-requirements」と指示されたときに使う。
要件定義書（docs/requirements.md）を requirements-doc-policy の基準でレビューし、凍結してよい品質かを合否判定する。「requirements-review」「要件定義書をレビューして」と指示されたとき。
アプリの設計・アーキテクチャの「質」をレビューする。UI/DB/外部サービス/言語などの詳細を差し替え可能に保てているかを検査する。「arch-review」「設計をレビューして」「アーキテクチャをレビューして」と指示されたとき。
SKILL.md を表示中
| name | to-plan |
| description | grill-me の対話や事前調査の結果を Plan ファイルに構造化して書き出し、続けて /check-plan で監査する。「to-plan」「plan ファイルにして」と指示されたとき。 |
/grill-me の対話・Plan モードでの調査結果を、後続の /check-plan → /to-issues に渡せる Plan ファイル に構造化して書き出す。開発フロー（docs/guide/development-flow.md）の「Plan作成＋チェック」工程に対応する。
~/.claude/plans/<slug>.md（Plan モードと同じホームディレクトリの .claude/plans/）。
<slug> はトピックを表すケバブケース（例: oauth-session-revocation）。<issue番号>-<slug>.md（例: 42-oauth-session-revocation.md）。Plan は 会話履歴を一切持たない別セッション が読む前提で書く。判断基準は一文:
この Plan だけ読んで、別セッションが意図と判断を再構築できるか。ただし陳腐化する実装詳細はコードに委ねる。
「詳細に書く」と「簡潔に保つ」は対立しない。増やすべき詳細と、増やすべきでない詳細を分ける:
| 書く（コールドスタートで再構築できないもの） | 書かない（陳腐化する・コードを読めば足りる） |
|---|---|
| 目的・WHY、判断の根拠 | 具体的なファイルパス・行番号 |
| 却下した代替案とその理由 | コードスニペット（決定を encode する例外を除く） |
| 前提・制約・スコープ境界（やらないこと） | レイヤーごとの実装手順の逐次列挙 |
| 受け入れ基準・完了の定義 |
会話に既にある情報（/grill-me の対話、Plan モードでの調査結果）を起点にする。引数で Issue 番号・URL・パスが渡された場合は gh issue view 等で本文・コメントを取得して読む。
着手前に必ず docs/design-hub.md・docs/policy-hub.md（CLAUDE.md 「必読ドキュメント」）に加え、要件定義 docs/requirements.md を参照する。設計書ハブが未作成の場合はその旨を Plan に記録する。requirements.md は要件の正典であり、設計判断はこれに照らして下す。ただし長大になるため全文は読まない——grep -n '^## ' docs/requirements.md で見出し位置を取り、「非機能要件」セクション（SLI・SLO を含む）だけを行範囲指定で読む。とくに SLO（レイテンシ・可用性・スループットの目標）は、設計の構造（同期/非同期・ネットワークホップ段数・冗長化）が目標を満たせるかを左右する制約なので必ず確認する。他の節は、Plan を書くのにその内容が要ると判明したときだけ、同じ手順でピンポイントに読む。
設計書への影響・コードベースへの影響を判断できるだけの情報が揃っていなければ、コードベースを探索して補う。確定仕様は用語集（docs/reference/glossary.md）の語彙を使い、該当領域の ADR（docs/adr/）を尊重する。
assets/plan-template.md の構成に従って Plan を書く。省略不可の必須セクション:
docs/requirements.md（要件定義）の更新要否も判断する——通常は実装が要件に従うため変更不要だが、設計・実装で要件の誤り・不足・変更が判明した場合のみ更新対象に挙げる。更新不要なら必ず「更新不要・理由：〇〇」と明記する（空欄・省略禁止）。/to-issues が各Issueへ転記し、issue番号だけで開発フローを再現できるようにするための情報。変更がマクロ構造・境界（UI/DB/外部サービス/言語の差し替え可能性・依存方向・レイヤー構成）に影響する場合は、任意レビュー /arch-review を実装フローに加え、AI から実行を推奨する（常設ステップではないが、ここに記載すれば issue 追従で事後レビューが自動で走る）。「grill-me で確定した仕様」には決定事項だけでなく、却下した代替案とその理由も書く（別セッションでの蒸し返し防止 / /to-issues がそのまま転記する）。grill-me 未実施なら「grill-me 未実施」と明記する。
Plan を書き出したら、続けて /check-plan <Planパス> を実行する。必須セクションの充足とコードベース・ドキュメントの影響範囲の網羅を Issue 化前に監査し、不足があれば Plan を修正する。判定基準と報告フォーマットは check-plan スキルに委ねる。