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. 用户故事

每个故事都需要：

• 标题： 简短、描述性强的名称
• 描述： “作为一名[用户]，我希望[功能]，以便[收益]”
• 验收标准： 可验证的清单，明确说明“完成”的含义

每个故事应足够小，以便在一次专注的工作会话中完成。

格式：

### 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 Agent。因此：

• 表述明确，不含歧义
• 避免使用行话；如需使用，应加以解释
• 提供足够的细节，帮助理解目的和核心逻辑
• 为需求编号，便于引用
• 在有帮助时提供具体示例

---

输出

• 格式： Markdown（.md）
• 位置： tasks/
• 文件名： prd-[feature-name].md（kebab-case）

---

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