Plan・設計
Phase 2 Plan と Phase 3 要件設計。
Phase 2 は、コードを書く前に「何を・どの順で・どこまでやるか」を AI と一緒に固める段階です。Plan が通れば Phase 3 の設計 docs に進みます。
着手前の確認
着手前チェック：中規模以上の機能は、Approved PRD（または 00_brief.md）を Plan 入力に入れてから始めてください。未承認のまま Plan に入ると、あとで設計や実装がやり直しになりやすいです。
Plan プロンプト
新規タスクの最初のメッセージとして、Plan モード（または同等の計画フェーズ）のチャットに貼り付けます。角括弧 [...] は自分の PRD パス・Issue・既存コードのパスに置き換えてから送ってください。
新規タスクに着手します。Planモードで進行表を作ってください。
実装の中身はまだ書かないでください。
【タスク】
- PRD（Approved）: [docs/prd/xxx.md へのパス]
- Issue: [URL]
【コンテキスト】
- 関連する既存実装: [パス]
- 関連するルールファイル (.cursor/rules / CLAUDE.md / .claude/skills): [該当ファイル]
- 関連する個人メモ (あれば): [z_docs などへのリンク]
- スプリント目標との関係: [あれば]
- 期限・優先度: [あれば]
【作ってほしいもの】
1. タスク分解 (各サブタスクの完了条件)
2. 影響範囲の調査結果 (どのモジュール/ファイル/テストが影響を受けるか)
3. 設計判断が必要なポイント (代替案を3つまで)
4. リスクと回避策
5. レビュアー観点での確認ポイント
6. PoC/プロトタイプで先に確認すべき不確実箇所 (あれば)
出力先: **まずはこのチャット**。チームで追う Plan は **tasks/todo.md** にチェックリスト化（テンプレ同梱）。個人たたき台だけなら **z_docs/<feature-name>/00_plan.md** でも可（docs/ の公式成果物ではない）
実装やコード生成はまだ不要です。
大事なポイント：コンテキストの「関連する既存実装」は省略しないでください。パスが無いと、AI はリポジトリの慣習と違う案を出しがちです。
Plan の成果物
Plan 完了時に揃えたい出力は次のとおりです。tasks/todo.md はチーム共有の Plan 正式な記録、z_docs/ は個人メモ用（詳細は tasks/（リポジトリ））。
| 出力 | 必須 | 保存先 |
|---|---|---|
| タスク分解（完了条件付き） | 必須 | チャット / tasks/todo.md（推奨）/ z_docs/<feature>/00_plan.md（個人のみ） |
| Plan 結果・レビュー | 推奨 | tasks/todo.md の「レビュー・結果」 |
| 影響範囲調査 | 必須 | チャット |
| 設計判断ポイント（代替案） | 推奨 | チャット → Phase 3 で docs へ |
| リスクと回避策 | 必須 | チャット |
| レビュアー確認ポイント | 推奨 | PR description 下書き |
| 下書き PR（下書き PR（Draft PR）） | 推奨 | GitHub |
進め方（流れ）
開発者・AI・PM/レビュアーのやり取りは、おおよそ次の流れになります。
小規模は 3段フロー で足りることも。完了 → Phase 4
Phase 3 = AI と docs を作る手順。DDD / クリーンアーキなどの設計方針はプロジェクト固有です。正式な記録は docs/・ADR・rules。参考は メモ — DDD / クリーンアーキ。
設計ドキュメント生成
Phase 3 では、要件と設計を docs/<feature>/ にまとめます。レイヤ分割やモジュール構成は既存コードと ADR に合わせる。方針が未決なら、実装の前に ADR を起票してください。
AI 協働・設計 docs・検証の役割の違いは、次の表のとおりです。
| 観点 | AI 協働（本フロー） | 設計（docs / ADR） | 検証 |
|---|---|---|---|
| 役割 | AI 出力の範囲・禁止・進め方を固定 | 責務・データ・API・不変条件の記述 | 仕様・ルールとの整合確認 |
| 主な適用 Phase | Phase 1 → 全 Phase | Phase 3 | Phase 4〜4、PR 前 |
- 推奨順：Phase 1 のルール → Phase 3 の設計 docs → それに沿った実装 → lint / テスト / CI / レビュー。
- TDD 採用時：Phase 4 で 10.2 TDDテンプレ（任意） を使う。
- DDD / クリーンアーキ採用時：下の折りたたみ、または メモ の追記ブロックをプロンプト末尾に足す。
Plan が承認されたあと、設計用チャットで docs 生成まで進める流れは次のとおりです。
貼り付けタイミング：Phase 2 の Plan がレビューで OK になったあと、設計専用のチャット（または同チャットの続き）で、下のブロックをそのまま送ります。技術スタックの [選択] と参照パスを埋めてから貼ってください。
Planを承認します。技術スタックは [選択] で確定。
これから挙げる4ドキュメントを **`docs/<feature-name>/`** (チーム公式ドキュメント置き場) に生成または既存ファイルへ追記してください。
途中で確認を求めず一気通貫で出してください。
【前提】 ※ .cursor/rules/ または CLAUDE.md / AGENTS.md のプロジェクト制約に準拠
- 既存のアーキテクチャ・ディレクトリ構成・命名規則を踏襲する（逸脱する場合は 04_tech_decisions + ADR で理由を書く）
【既存コードベースの参照必須箇所】
- [類似機能のディレクトリ]
- [共通基盤のディレクトリ]
【生成/更新物】
1) docs/<feature-name>/01_requirements.md
- 機能要件 (Must/Should/Won't を表で)
- 非機能要件 (性能/信頼性/セキュリティ/保守性)
- スコープ外
- ユースケース図と主要シーケンス図 (Mermaid最小構文)
- 既存機能との関係 (どこを拡張するか)
- 用語 (既存 glossary.md と整合)
2) docs/<feature-name>/02_design.md
- 影響を受けるモジュール/レイヤと変更点
- 主要コンポーネントの責務 (新規/変更を区別)
- データフロー・API 境界（該当する場合）
- エラー設計方針
- トランザクション境界・並行制御方針（該当する場合）
- 既存パターンを踏襲した箇所 / 新規導入した箇所の説明
3) docs/<feature-name>/03_db_schema.md (DB変更がある場合のみ)
- 既存ER図への差分 (Mermaid erDiagram)
- 新規/変更テーブル: カラム/型/NULL/制約/INDEX/用途を表で
- マイグレーション計画 (forward / rollback)
- データ移行が必要なら別途記載
4) docs/<feature-name>/04_tech_decisions.md
- 新規ライブラリ導入があれば理由と代替案
- アーキテクチャ・設計スタイルの選択と理由（採用しなかった案も）
- 既存規約と異なる選択をした場合の理由
最後に docs/<feature-name>/README.md にこれら4ドキュメントへのリンクを生成してください。
重要な技術選定 (FW変更・DB変更・破壊的変更等) は `docs/adr/NNNN-<slug>.md` として ADR (11.7 ADR) も併せて生成してください。
プロンプト追記 — DDD / クリーンアーキ採用時のみ
チームが DDD + クリーンアーキを採用しているときだけ、上のプロンプト末尾に次を追加します。詳細は メモ — DDD / クリーンアーキ。
集約境界の明文化と設計判断の記録 — 集約境界が曖昧なときは、02_design に「注文＝集約ルート、明細は VO」と書き、04_tech_decisions に Vertical Slice を採らなかった理由を 3 行で残す。
【02_design.md 追記 — DDD / クリーンアーキ採用時】
- DDD を適用する範囲 (Entity / Value Object / Aggregate / Domain Service / Repository)
- クリーンアーキテクチャの層境界と依存方向
- 業務例外と技術例外の分離
【04_tech_decisions.md 追記】
- DDD / クリーンアーキテクチャをどこまで採るか、その理由
- Vertical Slice / CRUD モノリス等、採用しなかった選択肢