Menu
grill-me の対話や事前調査の結果を Plan ファイルに構造化して書き出し、続けて /check-plan で監査する。「to-plan」「plan ファイルにして」と指示されたとき。
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/kasiopeiya/claude-dev-template --skill to-planThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
RFC等の入力資料をもとに対話しながら要求を引き出し、requirements.md（PRD）を作成する。顧客が書いた「解決策」を「目的」に還元し、「制約」とされた事項が本当に制約かを疑いながら、目的の認識を合わせて要件を確定する。要求分析・要件定義・requirements.md作成を依頼されたとき、または「elicit-requirements」と指示されたときに使う。
要件定義書（docs/requirements.md）を requirements-doc-policy の基準でレビューし、凍結してよい品質かを合否判定する。「requirements-review」「要件定義書をレビューして」と指示されたとき。
アプリの設計・アーキテクチャの「質」をレビューする。UI/DB/外部サービス/言語などの詳細を差し替え可能に保てているかを検査する。「arch-review」「設計をレビューして」「アーキテクチャをレビューして」と指示されたとき。
Showing 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 スキルに委ねる。