cadre

ユーザーに質問し、以下のテンプレートに従って docs/PRD.md を作成または拡張します。

プロセス

1. 必要に応じてリポジトリを調べ、既存のコンテキスト（CLAUDE.md、ADR、業務用語集、関連コード）を把握します。PRDではプロジェクトの用語を再利用し、すでに決定済みのアーキテクチャ上の判断を尊重します。質問への答えがリポジトリ内にある場合は、質問するのではなく調査してください。

2. docs/PRD.md がある場合は読みます。受け取ったブリーフと照らし合わせ、差分についてのみ質問します。矛盾があれば確認します：「Xと決めていましたが、ブリーフではYを示唆しています。どちらにしますか？」。PRDもブリーフもない場合、最初の質問は「何を整理したいですか？」にします。

3. 一度に質問するのは1つだけとし、根拠を添えて推奨案を示します。依存関係に沿って進めます：問題 → 対象ユーザー → 解決策 → 成功基準 → 対象外。ユーザーストーリーと実装上の決定事項は、ほかの項目を通じて明らかにします。次に進む前に「補足メモに記載することはありますか？リスク、依存関係、前提など」と尋ねます。

4. 各セクションに抜けがなく、記述できる状態になったら、その旨を一文で伝え、テンプレートに従ってPRD全文をチャットに記載します。この時点で、ほかの回答に基づいてユーザーストーリーをまとめ、確認を求めます。

5. ユーザーがセクションごとに承認または修正します。修正があった場合は、該当するセクションのみを再投稿します。すべて承認されたら docs/PRD.md に書き込みます（必要に応じて docs/ を作成）。完了後、「✓ docs/PRD.md に書き込みました」と伝えます。

問題

ユーザーが経験していること：不満、状況、「なぜ今なのか」。三人称で記述し、一人称は使いません。

解決策

ユーザーの視点から見たプロダクトの方向性：プロダクトによって何ができるようになるかを記述し、どのように構築されるかは記述しません。

対象ユーザー

実在する人物を思い描けるほど具体的なプロフィールと利用状況。

ユーザーストーリー

「<アクター>として、<機能>をしたい。そうすることで、<メリット>が得られる」という形式の網羅的な番号付きリスト。主な操作、空の状態、エラー、代替フロー、境界事例を含めます。

成功基準

直接検証できる基準：観測可能なイベント（クリック、生成されたファイル、受信したメールなど）、または客観的な測定値（所要時間、件数、しきい値）。「Xを理解する」「Yを特定する」といった内面的な行動の判断は含めません。

対象外

明示的に対応しないこと。過剰な設計を防ぐため、網羅的に記載します。

実装上の決定事項

ユーザーから見えるプロダクトの動作（数値制限、空の状態、表示形式、UXの選択、フォームファクター、エラーなど）。内部の技術的な詳細（アルゴリズム、数式、環境変数、ライブラリ名、技術カテゴリ）は含めません。判断基準：利用時にユーザーが違いを認識できないものは除外します。

補足メモ

その他の事項：リスク、外部依存関係、前提、参考情報、今後の項目。簡潔にまとめます。該当事項がなければ「特記事項はありません。」とします。

ルール

• 用語はユーザーが使ったものをそのまま使用します。
• PRDには、特定の技術、抜け、ファイルパス、コードスニペットを含めません。
• ユーザーストーリーには必ず番号を付けます：US-1、US-2 ...