prd

PRD 生成器

创建清晰、可执行且适合实施的详细产品需求文档。PRD 确认后，使用 /to-issues 将其拆解为 Issues；在此之前，也可以选择使用 /prd-to-spec 编写技术设计。

---

工作内容

1. 接收用户的功能描述
2. 提出澄清问题，消除关键歧义——根据复杂度调整问题数量，不要固定数量（参见步骤 1）
3. 根据回答生成结构化 PRD
4. 将 PRD 提交给用户审核——询问：“请审核 PRD。如需调整，请告诉我；如确认无误，请回复 OK。”
5. 应用任何调整，然后保存至 tasks/prd-[feature-name].md
6. 建议后续步骤（参见步骤 3）

**重要：**不要开始实施，只需创建 PRD。

---

步骤 1：澄清问题

只询问初始提示中存在歧义的关键问题。根据功能复杂度调整问题数量——重点是消除关键歧义，而不是达到固定数量：

• **简单且范围明确的功能：**2-3 个问题
• **常见功能：**3-5 个问题
• 复杂功能（涉及多个用户角色、跨系统集成或存在重大歧义）：6-8 个问题

如果用户输入已经明确说明某个方面，就跳过该方面——不要为了凑数而提出无关问题。重点关注：

• **问题/目标：**要解决什么问题？
• **核心功能：**关键操作有哪些？
• **范围/边界：**不应该做什么？
• **成功标准：**如何判断功能已完成？

问题格式如下：

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”来快速迭代。请记住为选项添加缩进。

---

特殊情况与后备处理

场景	处理方式
用户跳过澄清问题（例如回复“随便”“直接写吧”）	填入合理的默认值，在 PRD 中用 [Assumption] 标记，并在审核时请用户确认
用户输入过于模糊（例如“添加一个功能”）	询问一次具体信息；如果仍然模糊，则根据项目上下文推断并标记假设
tasks/ 目录不存在	自动创建 tasks/ 目录
难以从输入中提取 feature-name	直接询问用户：“建议的 PRD 文件名为 prd-XXX.md，请确认或修改”
用户在审核后要求修改 PRD	应用修改并重新保存，无需重新进行澄清流程
PRD 内容超过 500 行	建议用户考虑将其拆分为多个子功能 PRD
用户决定不继续	只保存 PRD，用户之后可以运行 /to-issues
之后需要创建 Issue	建议使用已保存的 PRD 文件运行 /to-issues

---

步骤 2：PRD 结构

生成 PRD 时，请包含以下部分：

1. 简介/概述

简要描述该功能及其要解决的问题。使用通俗易懂的语言，避免使用术语，或对术语加以解释。假设读者可能是初级开发者或 AI Agent。

2. 目标

具体、可衡量的目标（项目符号列表）。

3. 用户故事

每个故事都需要：

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

编号规则： US-001、US-002、US-003……（三位数字，从 001 开始）。每个 US 都应可独立实现，且足够小，能在一次专注的 Agent 会话中完成。

强制 E2E 测试故事： 每份 PRD 都必须包含一个端到端（E2E）测试用户故事，并将其作为最后一个用户故事。它需要验证跨越整个技术栈的完整功能流程——从用户操作，经由 UI、API 到数据层，而非孤立的单元测试。其验收标准应描述真实用户为实现功能核心目标而经历的完整顺利流程，以及至少一条关键边界或失败路径，并通过自动化 E2E 测试进行断言（例如，UI 使用 Playwright/Cypress，或仅涉及后端功能时使用 API 层集成测试）。此故事依赖所有其他故事，并确认整个功能能够正常运行。

验收标准自检模板： 每条标准都必须满足以下至少一项，否则会被视为“模糊”，必须重写：

• 可观察：描述具体的 UI 状态或 API 响应（例如，“按钮显示确认对话框”）
• 可测试：具有明确的输入/输出对应关系（例如，“输入空电子邮件地址时会显示红色警告”）
• 可验证：可通过工具检查（例如，“类型检查/ lint 通过”）
• ❌ 反例：“运行正常”“良好的用户体验”“出色的性能” → 这些都无法验证

格式：

### 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 a browser (e.g., via the `run` skill)

E2E 故事格式：

### US-NNN: End-to-end test of [feature] flow
**Description:** As a QA engineer, I want an automated end-to-end test covering the full [feature] journey so that we catch regressions across the entire stack.

**Acceptance Criteria:**
- [ ] Automated E2E test simulates the full happy path (user action → UI → API → data → visible result)
- [ ] Covers at least one critical edge/failure path (e.g., invalid input, empty state, permission denied)
- [ ] Test runs in CI and passes
- [ ] Test is independent and repeatable (sets up and tears down its own data)

重要：

• 验收标准必须可验证，不能模糊。“运行正常”是不好的标准。“删除前按钮会显示确认对话框”是好的标准。
• 对于任何包含 UI 更改的故事： 始终将“在浏览器中验证”列为验收标准（例如，通过 run 技能）。这可确保对前端工作进行视觉验证。

4. 功能需求

使用编号列出具体功能：

• “FR-1：系统必须允许用户……”
• “FR-2：用户点击 X 时，系统必须……”

FR 规范： 每条 FR 都以 FR-N: 开头（N 从 1 开始递增），使用“系统必须/系统应当”的措辞，并且只描述一种具体行为。避免在一条 FR 中使用“和”连接多种行为。

5. 非目标（不在范围内）

说明此功能不会包含哪些内容。对于管理范围至关重要。

6. 设计考量（可选）

• UI/UX 要求
• 可用时，提供原型链接
• 可重复使用的相关现有组件

7. 技术考量（可选）

• 已知限制或依赖项
• 与现有系统的集成点
• 性能要求

8. 成功指标

如何衡量成功？

• “将完成 X 的时间缩短 50%”
• “将转化率提高 10%”

9. 未决问题

仍待回答的问题或需要澄清的方面。

---

输出

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

---

第 3 步：后续步骤

保存 PRD 后，建议用户：

✅ PRD saved to tasks/prd-[feature-name].md

Next steps:
  /prd-to-spec  →  Generate technical SPEC (optional — for complex features)
  /to-issues    →  Decompose into Issues and create tickets

Or go straight to implementation:
  /to-issues    →  Create Issues, then /goal to implement

如果用户想继续，请调用相应的技能。

---

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 a browser (e.g., via the `run` 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 a browser (e.g., via the `run` 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 a browser (e.g., via the `run` skill)

### US-005: End-to-end test of task priority flow
**Description:** As a QA engineer, I want an automated end-to-end test covering the full priority journey so that we catch regressions across the entire stack.

**Acceptance Criteria:**
- [ ] E2E test creates a task, sets its priority via the edit modal, and asserts the badge color updates on the card
- [ ] Test applies a priority filter and asserts only matching tasks remain visible
- [ ] Covers edge case: filtering to a priority with no tasks shows the empty state message
- [ ] Test runs in CI and passes
- [ ] Test sets up and tears down its own task data

## 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 前：

• 使用字母选项提出了澄清问题
• 已纳入用户的回答
• 用户故事足够小且具体
• 包含了强制的端到端（E2E）测试故事，并将其作为最后一个用户故事
• 功能需求已编号且含义明确
• 非目标部分明确界定了范围
• 已保存至 tasks/prd-[feature-name].md
• 已建议后续步骤：/prd-to-spec（可选）和 /to-issues