to-plan

# 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 を書くのにその内容が要ると判明したときだけ、同じ手順でピンポイントに読む。 ### 2. 影響範囲の調査（不足時のみ） 設計書への影響・コードベースへの影響を判断できるだけの情報が揃っていなければ、コードベースを探索して補う。確定仕様は用語集（`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 追従で事後レビューが自動で走る）。 「grill-me で確定した仕様」には決定事項だけでなく、**却下した代替案とその理由**も書く（別セッションでの蒸し返し防止 / `/to-issues` がそのまま転記する）。grill-me 未実施なら「grill-me 未実施」と明記する。 `/grill-me` の **Not-now リスト**が会話にあれば、スコープの「やらないこと」欄へ**全行転記する**（「何が起きたら決める必要が出るか」のトリガーも一緒に）。Not-now は却下ではなく先送りなので、転記しないとここで消える。 ### 4. check-plan を自動実行（シフトレフト） Plan を書き出したら、続けて `/check-plan <Planパス>` を実行する。必須セクションの充足とコードベース・ドキュメントの影響範囲の網羅を Issue 化前に監査し、不足があれば Plan を修正する。判定基準と報告フォーマットは check-plan スキルに委ねる。