generate-prd

为新功能生成详细、可执行的产品需求文档（PRD）。通过澄清问题引导用户，然后生成适合开发者或 AI Agent 实施的规范。

重要：此技能仅创建 PRD，不会开始实施。

<quick_start>

1. 使用字母选项（A、B、C、D）提出 3-5 个澄清问题
2. 根据答案生成结构化 PRD
3. 保存到 tasks/prd-[feature-name].md </quick_start>

使用 AskUserQuestion 工具提出 3-5 个关键问题，涵盖：

• 问题/目标：要解决什么问题？谁会受益？
• 核心功能：必备功能有哪些？
• 范围/边界：明确不包含哪些内容？
• 成功标准：如何判断功能是否有效？

每个问题都应提供 3-4 个具体选项（A、B、C、D 格式），以及用于自定义输入的“其他”选项。

创建 PRD 文档，包含以下部分：

1. 简介/概述 – 简要介绍功能并说明问题
2. 目标 – 具体、可衡量的目标
3. 用户故事 – 每项均包含标题、描述和可验证的验收标准
4. 功能需求 – 明确编号（FR-1、FR-2 等）
5. 非目标 – 明确的范围边界
6. 设计考量 – UI/UX 要求（如适用）
7. 技术考量 – 约束和依赖项（如适用）
8. 成功指标 – 可衡量的结果
9. 待解决问题 – 仍需澄清的事项

将 PRD 保存到：`tasks/prd-[feature-name].md`

功能名称使用 kebab-case（例如：prd-user-authentication.md）。

避免使用术语，或对术语加以解释。提供具体示例。初级开发者无需额外背景信息，也应能理解每项需求。 验收标准必须具体且可测试。

良好示例：“登录按钮在登录成功后跳转到 /dashboard” 不良示例：“登录功能正常”

每个以 UI 为重点的用户故事都必须包含此验收标准： `"Verify in browser using dev-browser skill"` 每个用户故事都应足够小，可在一个会话中完成。如果某个故事范围过大，请将其拆分为更小的故事。

<prd_template>

# PRD: {{Feature Name}}

## 1. Introduction

{{Brief description of the feature and the problem it solves}}

## 2. Goals

- {{Goal 1: Specific, measurable objective}}
- {{Goal 2: Specific, measurable objective}}

## 3. User Stories

### US-1: {{Story Title}}
**As a** {{user type}}, **I want** {{feature}} **so that** {{benefit}}.

**Acceptance Criteria:**
- {{Specific, testable criterion}}
- {{Specific, testable criterion}}
- Verify in browser using dev-browser skill (for UI stories)

### US-2: {{Story Title}}
...

## 4. Functional Requirements

- **FR-1**: {{Explicit requirement}}
- **FR-2**: {{Explicit requirement}}
- **FR-3**: {{Explicit requirement}}

## 5. Non-Goals

- {{What this feature explicitly does NOT do}}
- {{Scope boundary}}

## 6. Design Considerations

{{UI/UX requirements, wireframe references, design patterns}}

## 7. Technical Considerations

{{Constraints, dependencies, integration points, performance requirements}}

## 8. Success Metrics

- {{Measurable outcome 1}}
- {{Measurable outcome 2}}

## 9. Open Questions

- [ ] {{Unresolved question needing clarification}}

</prd_template>

**良好示例：** - “搜索结果在 2 秒内显示” - “输入格式错误时，显示错误消息 ‘Invalid email format’” - “点击 ‘Save’ 后，按钮变为禁用状态并显示加载动画，直至操作完成”

不良示例：

• “搜索速度快”
• “显示合适的错误消息”
• “保存体验良好”

- **FR-1**：系统应使用 RFC 5322 模式验证电子邮件格式 - **FR-2**：密码至少为 8 个字符，且至少包含一个数字 - **FR-3**：闲置 30 分钟后，用户会话过期

<success_criteria> 满足以下条件时，PRD 才算完整：

• 已提出并回答 3-5 个澄清问题
• 9 个 PRD 部分均已填写具体内容
• 用户故事包含可验证的验收标准
• UI 用户故事包含浏览器验证标准
• 功能需求已编号（FR-1、FR-2 等）
• 非目标明确界定范围边界
• 文档已保存到 tasks/prd-[feature-name].md
• 尚未开始实施（仅创建 PRD） </success_criteria>