prd

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 に保存した