prd-to-issues

PRD からイシューへ

PRD を垂直スライス（トレーサーバレット）を使って、個別に着手できるイシューに分割し、ローカルの Markdown ファイルとして作成します。

プロセス

1. PRD を見つける

PRD ファイルのパスをユーザーに尋ねます（例：issues/prd.md）。

PRD がまだコンテキストウィンドウにない場合は、ファイルから読み込みます。

2. コードベースを調査する（任意）

まだコードベースを調査していない場合は、コードの現在の状態を把握するために調査します。

3. 垂直スライスを下書きする

PRD をトレーサーバレットイシューに分割します。各イシューは、1 つのレイヤーだけを対象とする水平スライスではなく、すべての統合レイヤーをエンドツーエンドで貫く薄い垂直スライスです。

スライスには「HITL」または「AFK」を指定できます。HITL スライスでは、アーキテクチャ上の決定やデザインレビューなど、人間の介入が必要です。AFK スライスは、人間の介入なしで実装してマージできます。可能な場合は、HITL より AFK を優先してください。

- 各スライスは、すべてのレイヤー（スキーマ、API、UI、テスト）を通る、狭くても完全な経路を提供します - 完了したスライスは、それ単独でデモまたは検証できます - 少数の分厚いスライスより、多数の薄いスライスを優先します

4. ユーザーに確認する

提案する内訳を番号付きリストで提示します。各スライスについて、次の項目を示します。

• タイトル：短く内容を表す名前
• 種類：HITL / AFK
• ブロック要因：先に完了する必要がある他のスライス（ある場合）
• 対象となるユーザーストーリー：PRD に記載されている、このスライスが対応するユーザーストーリー

ユーザーに次の点を尋ねます。

• 粒度は適切ですか？（粗すぎる／細かすぎる）
• 依存関係は正しいですか？
• 統合またはさらに分割すべきスライスはありますか？
• HITL と AFK の指定は適切ですか？

ユーザーの承認が得られるまで、調整を繰り返します。

5. イシューのファイルを作成する

承認された各スライスについて、issues/NNN-short-title.md という命名規則で、issues/ に Markdown ファイルを作成します（例：issues/001-add-user-auth.md）。

issues/ に既存のファイルがあるか確認し、次に利用可能な番号からイシュー番号を付けます。

「Blocked by」欄で実際のファイル名を参照できるよう、依存関係の順（ブロック要因となるものを先に）でファイルを作成します。

gh issue create や GitHub CLI コマンドは使用しないでください。GitHub のイシュー番号を参照しないでください。相互参照にはすべてローカルのファイル名を使用してください。

## 親 PRD

issues/prd.md（または使用した PRD ファイル）

作成する内容

この垂直スライスの簡潔な説明です。レイヤーごとの実装ではなく、エンドツーエンドの動作を説明します。内容の重複を避け、親 PRD の該当するセクションを参照します。

受け入れ条件

• 条件 1
• 条件 2
• 条件 3

ブロック要因

• issues/NNN-title.md にブロックされています（該当する場合）

または、ブロック要因がない場合は「なし - すぐに着手できます」と記載します。

対象となるユーザーストーリー

親 PRD の番号で参照します。

• ユーザーストーリー 3
• ユーザーストーリー 7

親 PRD ファイルを閉じたり、変更したりしないでください。