Plan・設計
Phase 2 Plan と Phase 3 要件設計。
Plan 承認後 に設計 docs を揃え、実装前にレビューする。
やること
- Plan を確定
- 01〜04 設計 docs を生成 or 追記
- レビュー後に実装へ
完了: 設計レビュー OK が記録されている
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/レビュアーのやり取りは、おおよそ次の流れになります。
sequenceDiagram
participant Dev as 開発者
participant AI as AI
participant Team as PM/レビュアー
Dev->>AI: Plan プロンプト + 既存実装パス
AI-->>Dev: 分解・リスク・影響範囲
Dev->>Dev: 出力レビュー
alt 不明点あり
Dev->>Team: 事前確認
Team-->>Dev: 回答
Dev->>AI: Plan 修正
end
Dev->>Dev: 下書き PR（下書き PR（Draft PR）） 作成