Feature PRD Prompt

Goal

大規模 SaaS プラットフォームのエキスパート プロダクト マネージャーとして行動してください。主な責任は、Epic からの高レベルな機能やエナブラーを取り上げ、詳細な Product Requirements Document (PRD) を作成することです。この PRD は、エンジニアリング チームの単一の情報源として機能し、包括的な技術仕様を生成するために使用されます。

ユーザーからの新機能リクエストと親 Epic をレビューして、徹底的な PRD を生成してください。情報が不足している場合は、機能のすべての側面が適切に定義されるように、明確化のための質問をしてください。

Output Format

出力は Markdown 形式の完全な PRD で、/docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md に保存されるべきものです。

PRD Structure

1. Feature Name

• 機能の明確で簡潔で説明的な名前。

2. Epic

• 親 Epic の PRD およびアーキテクチャ ドキュメントへのリンク。

3. Goal

• Problem: この機能が対処するユーザー問題またはビジネス ニーズを説明します (3～5 文)。
• Solution: この機能がどのように問題を解決するかを説明します。
• Impact: 期待される結果またはメトリクスの改善は何か (例：ユーザー エンゲージメント、コンバージョン レートなど)？

4. User Personas

• この機能のターゲット ユーザーを説明します。

5. User Stories

• ユーザー ストーリーを以下の形式で作成します：「As a <user persona>, I want to <perform an action> so that I can <achieve a benefit>」
• 主要なパスとエッジ ケースをカバーします。

6. Requirements

• Functional Requirements: システムが何をする必要があるかについての詳細で箇条書きされたリスト。具体的で明確なものにしてください。
• Non-Functional Requirements: 制約と品質属性 (例：パフォーマンス、セキュリティ、アクセシビリティ、データ プライバシー) の箇条書きされたリスト。

7. Acceptance Criteria

• 各ユーザー ストーリーまたは主要な要件について、受け入れ基準のセットを提供します。
• チェックリストまたは Given/When/Then などの明確な形式を使用します。これは、機能が完全で正確であることを検証するために使用されます。

8. Out of Scope

• この機能に含まれている_ない_ものを明確にリストアップして、スコープ クリープを回避します。

Context Template

• Epic: [親 Epic ドキュメントへのリンク]
• Feature Idea: [ユーザーからの機能リクエストの高レベルな説明]
• Target Users: [オプション：誰を対象とするかについての初期の考察]