requirement-to-prd

name	requirement-to-prd
description	将用户需求转换为规范的产品需求文档（PRD）。用户说"生成PRD"、"需求转PRD"、"创建PRD"、"写PRD"或"帮我写个PRD"时立即触发。支持一句话需求、功能清单、用户故事等多种输入形式。PRD 默认保存到项目目录下的 docs/prd/（如果在项目目录中），否则询问用户或保存到全局目录。
triggers	["生成PRD","需求转PRD","创建PRD","写PRD","requirements to PRD","把需求转成PRD","帮我写个PRD"]

Requirement to PRD - 需求转 PRD 生成器

执行流程（严格遵循）

Step 1: 解析需求与确定项目

1. 识别输入类型：一句话需求 / 功能清单 / 用户故事
2. 提取关键信息：目标用户、核心功能、技术栈（如有）
3. 确定 PRD 保存位置：
   • 检查当前工作目录是否在项目目录下（~/src/production/* 或 ~/src/projects/*/*）
   • 如果是，提取项目名，PRD 保存到 {项目目录}/docs/prd/
   • 如果不是，询问用户："这个 PRD 属于哪个项目？" 或保存到全局 ~/src/docs/prd/
4. 如果信息不足，向用户确认（最多3个问题）

Step 2: 读取模板

读取 references/prd-template.md，严格按照模板结构生成。

Step 3: 生成 PRD

必须包含的章节（按模板）：

1. 文档信息（版本历史、相关人员）
2. 产品概述（背景、目标、目标用户）
3. 功能需求（清单+详细描述，含验收标准）
4. 非功能需求（性能、安全、兼容）
5. 技术方案（技术栈、架构、数据模型、API）
6. UI/UX 设计（原则、页面、交互流程）
7. 项目规划（里程碑、任务分解）
8. 附录（术语表、参考资料）

输出要求:

• PRD ID: prd-YYYYMMDD-HHMMSS-[4位随机]
• 项目内保存: {项目目录}/docs/prd/prd-[ID].md
• 全局保存（无项目时）: ~/src/docs/prd/prd-[ID].md
• 确保目录存在: mkdir -p {保存目录}/docs/prd/

Step 4: 输出结果

返回格式：

✅ PRD 生成完成

**PRD ID**: [ID]
**文件**: `{实际保存路径}/prd-[ID].md`
**项目**: [项目名 或 "全局文档"]
**技术栈**: [技术栈]

**功能清单**:
- P0: [核心功能数量] 个
- P1: [重要功能数量] 个
- P2: [增强功能数量] 个

**下一步**:
1. [ ] 评审 PRD
2. [ ] 确认技术方案
3. [ ] 运行 `根据 PRD [ID] 实现代码`

---

输入类型处理

输入类型	处理方式
一句话需求	推断关键信息，补充合理假设
功能清单	逐项扩展为详细功能描述
用户故事	提取角色、功能、价值，扩展相关功能
竞品参考	分析核心功能，定义差异化范围

---

协作流程

requirement-to-prd (本技能)
    ↓
prd-evolution (版本管理)
    ↓
prd-to-code (代码实现)

---

原则

1. 效率优先 - 不追求完美，先完成核心内容
2. 合理推断 - 用户未明确时，基于最佳实践自动补充
3. MVP 导向 - 区分 P0（必须）/ P1（应该）/ P2（可以）
4. 可执行性 - PRD 必须可直接用于开发

---

版本: v2.0 | 优化: 精简流程，提升效率