To 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（フロー0）が会話に登場している場合は <issue番号>-<slug>.md（例: 42-oauth-session-revocation.md）。

貫く原則：コールドスタート再現性

Plan は 会話履歴を一切持たない別セッション が読む前提で書く。判断基準は一文:

この Plan だけ読んで、別セッションが意図と判断を再構築できるか。ただし陳腐化する実装詳細はコードに委ねる。

「詳細に書く」と「簡潔に保つ」は対立しない。増やすべき詳細と、増やすべきでない詳細を分ける:

• 書く（コールドスタートで再構築できないもの）
  • 目的・WHY、判断の根拠
  • 却下した代替案とその理由
  • 前提・制約・スコープ境界（やらないこと）
  • 受け入れ基準・完了の定義
• 書かない（陳腐化する・コードを読めば足りる）
  • 具体的なファイルパス・行番号
  • コードスニペット（決定を encode する例外を除く）
  • レイヤーごとの実装手順の逐次列挙

プロセス

1. コンテキスト収集

会話に既にある情報（/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 を書くのにその内容が要ると判明したときだけ、同じ手順でピンポイントに読む。

続けて、毎回必ず /past-decision-search を Skill ツールで実行し、Plan が触れる仕組み・パス・キーワードについて過去の決定を引く（AI は自分が知らない決定に気づけないので、要りそうかで省かない）。Plan の方針が引いた決定を覆すなら、その決定を出典付きで「grill-me で確定した仕様」の設計判断の根拠に書き、覆す理由を添える。

2. 影響範囲の調査（不足時のみ）

「設計書・要件定義への影響」または「タスク一覧」に、対象ファイルパス・関数名・クラス名などの具体名を1つも書けなければ、コードベースを探索して補う。確定仕様は用語集（docs/project-context/glossary.md）の語彙を使い、該当領域の ADR（docs/adr/）を尊重する。

3. Plan ファイルを書き出す

assets/plan-template.md の構成に従って Plan を書く。省略不可の必須セクション:

• 設計書・要件定義への影響: 更新が必要な設計書を列挙する。あわせて docs/requirements.md（要件定義）の更新要否も判断する——通常は実装が要件に従うため変更不要だが、設計・実装で要件の誤り・不足・変更が判明した場合のみ更新対象に挙げる。更新不要なら必ず「更新不要・理由：〇〇」と明記する（空欄・省略禁止）。
• タスク一覧: チェックボックス形式。設計書・requirements.md の更新が必要な場合は更新タスクを必ず含める。
• 実装フロー（使用するSkill）: 変更種別に対応する開発フローSkillを実行順に明記する。種別→Skillの対応は CLAUDE.md「開発フロー」の一覧が正典なので、そこを読んで決める。/to-issues が各Issueへ転記し、issue番号だけで開発フローを再現できるようにするための情報。変更がマクロ構造・境界（UI/DB/外部サービス/言語の差し替え可能性・依存方向・レイヤー構成）に影響する場合は、任意レビュー /arch-review を実装フローに加え、AI から実行を推奨する（常設ステップではないが、ここに記載すれば issue 追従で事後レビューが自動で走る）。決定した内容が docs/policy/adr-policy.md の判定で ADR 対象になるなら、/create-adr を実装フローに加える。

「grill-me で確定した仕様」には決定事項だけでなく、却下した代替案とその理由も書く（別セッションでの蒸し返し防止 / /to-issues がそのまま転記する）。grill-me 未実施なら「grill-me 未実施」と明記する。

/grill-me の Not-now リストが会話にあれば、スコープの「やらないこと」欄へ全行転記する（「何が起きたら決める必要が出るか」のトリガーも一緒に）。Not-now は却下ではなく先送りなので、転記しないとここで消える。

4. 新しい技術要素を照合し、check-plan を自動実行（シフトレフト）

Plan を書き出したら、/check-plan の前に、Plan の新しい技術要素を照合する。/check-plan は外部の制約を調べないので、公式に無い機能やツール名を前提にしたまま Issue 化へ進むのを、ここで止める。

新しい技術要素：Plan に名前が出た外部の製品・サービス・ツール（その機能名を含む）のうち、docs/adr/・docs/design/・各 package.json・README.md・.claude/ 配下（追跡されたファイル）のどこにも同じ名前が出てこないもの。

1. Plan から、外部の製品・サービス・ツールの名前を取り出す

2. 名前ごとに、大文字小文字を区別しない文字列検索で照合する。どこにもヒットしなければ新しい

   grep -rliF -- "<名前>" docs/adr docs/design $(git ls-files 'package.json' '*/package.json') $(git ls-files README.md .claude)

   README.md・.claude/ は git ls-files で追跡されたものだけを渡す。端末ごとに作られる .claude/settings.local.json を混ぜると、同じ名前の判定が端末で変わるからである。

3. 新しい技術要素が無ければ、聞かずに /check-plan <Planパス> を実行する

4. あれば AskUserQuestion で、新しい技術要素の名前を挙げて「外部の制約を調べる /premise-check を実行するか」を聞く。選択肢は「実行する」「実行しない」の2つ

   • 「実行しない」：/check-plan <Planパス> を実行する
   • 「実行する」：/check-plan を走らせず、/to-issues へ進む案内も出さず、/premise-check <Planのパス> を打つよう案内して止まる。/premise-check はモデルから呼べない。見直すなら Plan を直し、続けて /check-plan <Planパス> を打つことも添える

「実行する」で /check-plan を走らせないのは、/check-plan が合格すると /to-issues へ進む案内を必ず出し、調べる前に進む道が開くからである。

/check-plan は、必須セクションの充足とコードベース・ドキュメントの影響範囲の網羅を Issue 化前に監査し、不足があれば Plan を修正する。判定基準と報告フォーマットは check-plan スキルに委ねる。