prd-to-plan

PRD から計画へ

PRD を垂直スライス（トレーサーバレット）を使った段階的な実装計画に分割します。出力は ./docs/<feature-name>/plan.md にある Markdown ファイルです。

プロセス

1. PRD がコンテキストに含まれていることを確認する

PRD は会話内にすでに含まれているはずです。含まれていない場合は、ユーザーに貼り付けるか、ファイルの場所を教えるよう依頼してください。

2. コードベースを調査する

まだコードベースを調査していない場合は、現在のアーキテクチャ、既存のパターン、統合レイヤーを把握するために調査してください。

3. 長期にわたって維持されるアーキテクチャ上の決定を特定する

スライスに分割する前に、実装中に変更される可能性が低い、次のような高レベルの決定を特定してください。

• ルート構造／URL パターン
• データベーススキーマの構造
• 主要なデータモデル
• 認証／認可の方式
• サードパーティサービスとの境界

これらを計画のヘッダーに記載し、すべてのフェーズで参照できるようにします。

4. 垂直スライスを作成する

PRD をトレーサーバレットフェーズに分割します。各フェーズは、単一レイヤーの水平スライスではなく、すべての統合レイヤーをエンドツーエンドで貫く薄い垂直スライスです。

- 各スライスでは、すべてのレイヤー（スキーマ、API、UI、テスト）を通る、範囲は狭くても完全なパスを提供します - 完了したスライスは、それだけでデモまたは検証が可能です - 少数の厚いスライスより、多数の薄いスライスを優先します - 後続のフェーズで変更される可能性が高い具体的なファイル名、関数名、実装の詳細は含めないでください - 長期にわたって維持される決定（ルートパス、スキーマ構造、データモデル名）は必ず含めてください

5. ユーザーに確認する

提案する分割案を番号付きリストで提示します。各フェーズについて、次の項目を示してください。

• タイトル：短く内容が分かる名前
• 対象となるユーザーストーリー：PRD のどのユーザーストーリーに対応するか

ユーザーに次の点を尋ねてください。

• 粒度は適切ですか？（粗すぎる／細かすぎる）
• フェーズを統合したり、さらに分割したりする必要はありますか？

ユーザーが分割案を承認するまで調整を続けてください。

afk によって起動された場合（ユーザーとのやり取りがない場合）： 確認を省略します。粒度を最適と判断したうえで、計画を直接作成してください。

6. 計画ファイルを作成する

./docs/<feature-name>/ が存在しない場合は作成します。以下のテンプレートを使用し、機能名をファイル名にした Markdown ファイルとして計画を記述します（例：./docs/meta-direct-whatsapp/plan.md）。

タスクの形式（実行にあたって重要）

各フェーズの 「What to build」 セクションによって、ralph がそのフェーズをどのように実行するかが決まります。

• 番号付きリスト（1.、2.、3.）— 各項目が、それぞれ独自のコミットを持つ個別の実装タスクになります。複数の成果物があるフェーズでは、この形式を優先してください。
• 箇条書き（-、*）— 各項目が個別のタスクになります。
• 単一の段落 — フェーズ全体が1つのタスクとして実行されます。

フェーズに複数の論理的な成果物がある場合は、番号付き項目を使用してください。これにより、ralph は焦点を絞った小さな実装セッションを行え、コミット履歴も細分化できます。

# 計画：

PRD の参照元：<PRD.md への相対パス。例：docs/feature/PRD.md>

アーキテクチャ上の決定

すべてのフェーズに適用される、長期にわたって維持される決定：

• ルート：...
• スキーマ：...
• 主要なモデル：...
• （必要に応じてセクションを追加／削除してください）

---

フェーズ 1：<タイトル>

ユーザーストーリー：<PRD の番号をカンマ区切りで記載>

実装内容

1. 最初のタスク — このスライスの最初の成果物について説明します
2. 2つ目のタスク — 次の成果物について説明します
3. 3つ目のタスク — その次の成果物について説明します

受け入れ基準

• 基準 1
• 基準 2
• 基準 3

---

フェーズ 2：<タイトル>

ユーザーストーリー：<PRD の番号をカンマ区切りで記載>

実装内容

1. 最初のタスク — ...
2. 2つ目のタスク — ...

受け入れ基準

• ...