prd

用途

prd 用于把一个功能想法转化为清晰、可执行、适合直接实施的产品需求文档（PRD）。它面向的使用场景是：当你有一个功能点但需求尚未明确时，先用它把需求梳理成结构化文档，而不是立刻进入编码。

主要能力

接收功能描述：由用户提供一段功能说明。
提出澄清问题：只针对初始描述中含糊的关键点提问，数量为 3-5 个，每题附带字母选项，覆盖以下方面：
- 问题/目标：这个功能解决什么问题？
- 核心功能：关键操作有哪些？
- 范围/边界：不应该做什么？
- 成功标准：如何判断已完成？问题格式示例：
```
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]
```
用户可以用“1A, 2C, 3B”快速作答。
生成结构化 PRD：根据回答生成包含固定章节的文档。
保存文件：输出为 Markdown，存放于 tasks/ 目录，文件名为 prd-[feature-name].md（kebab-case）。

PRD 的章节结构

生成的 PRD 包含以下部分：

简介/概述：功能的简要描述及其解决的问题。
目标：具体、可衡量的目标（项目符号列表）。
用户故事：每个故事包括标题、描述（“As a [user], I want [feature] so that [benefit]”）和验收标准（可勾选清单）。每个故事应足够小，能在一个专注的会话内实现。格式示例：
```
### 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
```
验收标准必须可验证，忌用“works correctly”这类模糊表述，应采用“Button shows confirmation dialog before deleting”这类具体描述。凡是涉及 UI 变更的故事，都要加入“用 dev-browser 技能在浏览器中验证”的验收项，以确保前端工作得到视觉确认。
功能需求：编号列出的具体功能，如“FR-1: The system must allow users to...”，要求明确无歧义。
非目标（范围外）：明确本功能不包含什么，用于控制范围。
设计考量（可选）：UI/UX 要求、设计稿链接、可复用的现有组件。
技术考量（可选）：已知约束或依赖、与现有系统的集成点、性能要求。
成功指标：如何衡量成功。
待解决问题：尚存疑问或需要澄清之处。

面向初级开发者的写作要求

PRD 的读者可能是初级开发者或 AI 代理，因此要求：表述明确无歧义；使用平实语言并解释领域术语；提供足够细节以理解目的与核心逻辑；需求编号以便引用；在有用处给出具体示例。

使用方式

向该技能提供功能描述。
回答它提出的 3-5 个澄清问题（可用字母选项作答）。
获取生成的 PRD，并确认已保存到 tasks/prd-[feature-name].md。

重要限制与说明

该技能明确要求：不要开始实现，只创建 PRD。
输出格式固定为 Markdown，位置为 tasks/ 目录，文件名为 prd-[feature-name].md。
澄清问题只聚焦初始描述中含糊的关键点。
关于运行环境、安装命令、具体模型或平台支持、收费方式等信息，资料中暂未提供。

示例

资料中包含一份示例 PRD（“Task Priority System”，任务优先级系统），演示了各章节的完整写法：简介中说明为任务增加优先级以帮助用户聚焦重要事项；目标包括允许为任务分配高/中/低优先级、提供清晰的视觉区分、支持按优先级筛选和排序、新任务默认中优先级；用户故事涵盖数据库新增 priority 列、任务卡显示优先级标记、任务编辑中增加优先级选择器、按优先级筛选任务；功能需求、非目标、技术考量、成功指标与待解决问题等章节也均有示例内容。该示例的验收标准同样遵循可验证原则，并为 UI 相关故事附上了浏览器验证项。