idea-to-product → PRD Skill
前提检查
开始前先判断用户提供了什么：
| 用户提供的内容 | 处理方式 |
|---|---|
| 完整产品规划文档（含第十一章 PRD 摘要） | 直接从摘要提取，开始生成 |
| 规划文档但无 PRD 摘要章节 | 通读全文自行提取关键信息，告知用户 |
| 只有零散的产品描述 | 先问 3 个关键问题补全，见下 |
| 什么都没有 | 告知先运行 idea-to-product skill |
如果需要补问，最多 3 个问题：
1. 产品是什么类型？（Web/App/插件/API）
2. 核心用户是谁？MVP 要做哪 3-5 个功能？
3. 技术栈有没有限制/偏好？
执行流程
步骤一和步骤二之间有强依赖（串行），其余参考文件可并行读取。
步骤一：解析输入文档（串行，必须先完成）
→ 读 references/phase-1-parse-input.md，执行提取
→ 向用户确认关键信息，等用户确认后再进入步骤二
步骤二：生成完整 PRD（依赖步骤一结果）
→ 同时读取以下三个文件（可并行，无依赖关系）：
- references/phase-2-prd-sections.md — 各章节写作指南
- references/prd-template.md — 输出格式参考
- references/tech-specs.md — 写第 5、7 章时查阅
→ 按章节顺序逐章生成内容
步骤三：输出质量检查
→ 执行本文件底部的检查清单，全部通过才输出
PRD 文档结构
# [产品名称] PRD v1.0
## 0. 文档说明
## 1. 产品概述
## 2. 用户故事
## 3. 功能规格
## 4. 数据模型
## 5. API 设计（纯前端产品改为：状态管理规格）
## 6. 页面与交互流程
## 7. 非功能性要求
## 8. 验收标准
## 9. 开发优先级与里程碑
## 10. 开放问题（待决策）
输出质量检查
生成 PRD 后逐条确认，全部通过才输出：
- [ ] 每个用户故事都有对应的验收标准（AC），AC 是可测试的
- [ ] 功能规格描述的是"做什么"，不是"怎么实现"
- [ ] 数据模型列出了所有核心实体和字段类型
- [ ] API 设计有请求/响应示例（纯前端产品已改为状态管理规格）
- [ ] 页面流程覆盖了错误状态和边界情况
- [ ] 非功能性要求有可测量的具体指标（不是"要快"）
- [ ] 开放问题列出来了，不是假装都想清楚了
- [ ] 里程碑时间根据 MVP 功能数量动态估算，不是硬编码 8 周
特殊情况
| 情况 | 处理方式 |
|---|---|
| 规划文档里技术栈不明确 | PRD 里注明"待定"，在开放问题章节列出推荐选项 |
| 功能描述有歧义 | 在"开放问题"章节列出，不要自己假设 |
| 第三方集成细节不足 | 列出需要调研的问题，给出常用方案对比 |
| 用户要求特定格式 | 优先按用户要求，以本模板为基础调整 |
| 产品很简单（<5个功能） | 合并数据模型和 API 章节，不要为了结构而凑内容 |
| 纯前端/无后端产品 | 第 5 章改为"状态管理规格"，见 phase-2-prd-sections.md 说明 |
