prd

PRD ジェネレーター

明確で実行可能であり、実装に適した詳細な製品要件ドキュメントを作成します。

---

作業内容

1. ユーザーから機能の説明を受け取ります
2. 重要な確認質問を3～5件（選択肢にアルファベットを付けて）尋ねます
3. 回答に基づいて、構成の整ったPRDを作成します
4. tasks/prd-[feature-name].md に保存します

重要： 実装を開始しないでください。PRDの作成のみを行ってください。

---

ステップ1：確認質問

最初のプロンプトが曖昧な場合に限り、重要な質問をしてください。次の点に焦点を当てます。

• 問題／目標： どのような問題を解決しますか？
• 主な機能： 重要な操作は何ですか？
• 範囲／境界： 何を対象外としますか？
• 成功基準： 何をもって完了と判断しますか？

質問の形式：

1. What is the primary goal of this feature?
   A. Improve user onboarding experience
   B. Increase user retention
   C. Reduce support burden
   D. Other: [please specify]

2. Who is the target user?
   A. New users only
   B. Existing users only
   C. All users
   D. Admin users only

3. What is the scope?
   A. Minimal viable version
   B. Full-featured implementation
   C. Just the backend/API
   D. Just the UI

この形式なら、ユーザーは「1A, 2C, 3B」のように回答して、素早くやり取りできます。選択肢にはインデントを付けてください。

---

ステップ2：PRDの構成

次のセクションを含むPRDを作成します。

1. はじめに／概要

機能と、それが解決する問題について簡潔に説明します。

2. 目標

具体的で測定可能な目標を箇条書きにします。

3. ユーザーストーリー

各ストーリーには次の内容が必要です。

• タイトル： 簡潔で内容がわかる名前
• 説明：「[ユーザー]として、[メリット]を得るために[機能]を実現したい」
• 受け入れ条件： 完了の条件を確認できるチェックリスト

各ストーリーは、1回の集中した作業で実装できる規模にしてください。

形式：

### US-001: [Title]
**Description:** As a [user], I want [feature] so that [benefit].

**Acceptance Criteria:**
- [ ] Specific verifiable criterion
- [ ] Another criterion
- [ ] Typecheck/lint passes
- [ ] **[UI stories only]** Verify in browser using dev-browser skill

重要：

• 受け入れ条件は曖昧ではなく、確認できる内容にしてください。「正しく動作する」は不適切です。「削除前に確認ダイアログが表示される」は適切です。
• UIの変更を伴うストーリーには、必ず受け入れ条件として「dev-browser スキルを使ってブラウザーで確認する」を含めてください。 これにより、フロントエンドの作業を視覚的に確認できます。

4. 機能要件

具体的な機能を番号付きリストで記載します。

• 「FR-1：システムはユーザーが……できるようにする」
• 「FR-2：ユーザーがXをクリックしたとき、システムは……する」

明確で曖昧さのない表現にしてください。

5. 非目標（対象外）

この機能に含めない内容を記載します。範囲を管理するうえで重要です。

6. デザイン上の考慮事項（任意）

• UI／UXの要件
• モックアップがある場合はそのリンク
• 再利用する既存コンポーネント

7. 技術上の考慮事項（任意）

• 既知の制約または依存関係
• 既存システムとの統合ポイント
• パフォーマンス要件

8. 成功指標

成功をどのように測定しますか？

• 「Xの完了時間を50％短縮する」
• 「コンバージョン率を10％向上させる」

9. 未解決の質問

追加の確認が必要な質問や項目を記載します。

---

初級開発者向けの記述

PRDを読むのは、初級開発者またはAI エージェントかもしれません。そのため、次の点に留意してください。

• 明確で曖昧さのない表現にする
• 専門用語を避けるか、説明を加える
• 目的と主要なロジックを理解できるだけの詳細を記載する
• 参照しやすいよう、要件に番号を付ける
• 役立つ場合は具体例を使う

---

出力

• 形式： Markdown（.md）
• 保存先： tasks/
• ファイル名： prd-[feature-name].md（ケバブケース）

---

PRDの例

# PRD: Task Priority System

## Introduction

Add priority levels to tasks so users can focus on what matters most. Tasks can be marked as high, medium, or low priority, with visual indicators and filtering to help users manage their workload effectively.

## Goals

- Allow assigning priority (high/medium/low) to any task
- Provide clear visual differentiation between priority levels
- Enable filtering and sorting by priority
- Default new tasks to medium priority

## User Stories

### US-001: Add priority field to database
**Description:** As a developer, I need to store task priority so it persists across sessions.

**Acceptance Criteria:**
- [ ] Add priority column to tasks table: 'high' | 'medium' | 'low' (default 'medium')
- [ ] Generate and run migration successfully
- [ ] Typecheck passes

### US-002: Display priority indicator on task cards
**Description:** As a user, I want to see task priority at a glance so I know what needs attention first.

**Acceptance Criteria:**
- [ ] Each task card shows colored priority badge (red=high, yellow=medium, gray=low)
- [ ] Priority visible without hovering or clicking
- [ ] Typecheck passes
- [ ] Verify in browser using dev-browser skill

### US-003: Add priority selector to task edit
**Description:** As a user, I want to change a task's priority when editing it.

**Acceptance Criteria:**
- [ ] Priority dropdown in task edit modal
- [ ] Shows current priority as selected
- [ ] Saves immediately on selection change
- [ ] Typecheck passes
- [ ] Verify in browser using dev-browser skill

### US-004: Filter tasks by priority
**Description:** As a user, I want to filter the task list to see only high-priority items when I'm focused.

**Acceptance Criteria:**
- [ ] Filter dropdown with options: All | High | Medium | Low
- [ ] Filter persists in URL params
- [ ] Empty state message when no tasks match filter
- [ ] Typecheck passes
- [ ] Verify in browser using dev-browser skill

## Functional Requirements

- FR-1: Add `priority` field to tasks table ('high' | 'medium' | 'low', default 'medium')
- FR-2: Display colored priority badge on each task card
- FR-3: Include priority selector in task edit modal
- FR-4: Add priority filter dropdown to task list header
- FR-5: Sort by priority within each status column (high to medium to low)

## Non-Goals

- No priority-based notifications or reminders
- No automatic priority assignment based on due date
- No priority inheritance for subtasks

## Technical Considerations

- Reuse existing badge component with color variants
- Filter state managed via URL search params
- Priority stored in database, not computed

## Success Metrics

- Users can change priority in under 2 clicks
- High-priority tasks immediately visible at top of lists
- No regression in task list performance

## Open Questions

- Should priority affect task ordering within a column?
- Should we add keyboard shortcuts for priority changes?

---

チェックリスト

PRDを保存する前に、次の項目を確認してください。

• アルファベット付きの選択肢を含む確認質問をした
• ユーザーの回答を反映した
• ユーザーストーリーが小さく、具体的である
• 機能要件に番号が付いており、曖昧さがない
• 非目標のセクションで明確な境界を定めた
• tasks/prd-[feature-name].md に保存した