输入一个产品 idea（一句话或详细描述均可），自动生成图文并茂、结构完整的 PRD（产品需求文档），以 Markdown 格式保存到当前项目 markdown/ 目录，同时输出配套 SVG 图表文件。触发条件：用户提到"写 PRD"、"帮我写需求文档"、"生成 PRD"、"写产品需求文档"、"写商业需求文档"、"我有个产品想法"、"帮我把这个 idea 写成文档"、"PRD 模板"、"产品立项文档"、"产品需求"、"功能需求文档"。即使用户只给出一句简短的产品描述如"我想做一个 XX 产品"，也应立即使用本 skill 生成 PRD。本 skill 面向产品经理、创业者、产品负责人，输出可直接用于团队评审和立项决策的专业文档，深度整合 JTBD 用户洞察框架、MoSCoW 优先级方法论和北极星指标体系。
Install with the open skills CLI (global, non-interactive — available in every Claude Code session):
npx skills add digoal/blog --skill "write-prd" -g -a claude-code -yOr manually — copy the SKILL.md below into:
~/.claude/skills/write-prd-digoal/SKILL.md---
name: write-prd
description: 输入一个产品 idea（一句话或详细描述均可），自动生成图文并茂、结构完整的 PRD（产品需求文档），以 Markdown 格式保存到当前项目 markdown/ 目录，同时输出配套 SVG 图表文件。触发条件：用户提到"写 PRD"、"帮我写需求文档"、"生成 PRD"、"写产品需求文档"、"写商业需求文档"、"我有个产品想法"、"帮我把这个 idea 写成文档"、"PRD 模板"、"产品立项文档"、"产品需求"、"功能需求文档"。即使用户只给出一句简短的产品描述如"我想做一个 XX 产品"，也应立即使用本 skill 生成 PRD。本 skill 面向产品经理、创业者、产品负责人，输出可直接用于团队评审和立项决策的专业文档，深度整合 JTBD 用户洞察框架、MoSCoW 优先级方法论和北极星指标体系。
---
# Write PRD Skill
将一个产品 idea 转化为完整、可直接评审的 PRD（Product Requirements Document）。
> 核心理念：PRD 是团队在不确定性中的共同契约。它的价值不在于格式，而在于把 **WHY → WHAT → HOW → MEASURE** 四个维度讲清楚。
---
## 工作流总览
```
用户输入 Idea
↓
Step 1: 信息补全 & JTBD 推演（不急于提问，先推断）
↓
Step 2: 搜索市场背景与竞品（web search）
↓
Step 3: 生成配套 SVG 图表（独立文件）
↓
Step 4: 生成完整 PRD Markdown 文件
↓
输出到 markdown/ 目录
```
---
## Step 1：信息补全与 JTBD 推演
拿到用户的 idea 后，**不要立刻问问题**，先做推演：
### 1.1 JTBD 框架推断用户痛点
用以下格式在内部推断，不要直接展示给用户：
> **当** [目标用户] **在** [特定场景] **时，**
> **他们需要** [完成某项工作/达到某个目标]，
> **但目前面临** [具体障碍]，
> **导致** [可量化的业务/体验影响]。
### 1.2 五维推断清单
1. **目标用户**：谁会用这个产品？主用户 vs. 次要用户区分
2. **核心痛点**：用 JTBD 格式描述，不是"用户想要功能"，而是"用户想完成什么任务"
3. **商业模式**：产品如何盈利？服务于什么更大的商业目标？
4. **差异化**：和竞品相比，核心的差异化价值主张是什么？
5. **成功指标**：什么数字能证明这个产品成功了？（北极星指标）
### 1.3 推断优先于询问
- 如果信息足够推断，直接进入 Step 2
- 在 PRD 中用 **[待确认]** 标注推断字段
- 如需询问，**一次性问不超过 3 个**最关键的问题后再执行
---
## Step 2：搜索市场背景（使用 web_search）
搜索以下信息，充实 PRD 背景章节：
1. **市场规模**：`[产品领域] market size 2024/2025`
2. **主要竞品**：`[产品类型] top competitors features comparison`
3. **行业趋势**：`[用户痛点] trends [当前年份]`
4. **参考案例**：`[类似产品] success failure case study`
搜索后提炼关键数据点，填入 PRD 对应章节。
---
## Step 3：生成 SVG 图表
**必须生成以下至少 2 个 SVG 图表**，保存到 `markdown/` 目录：
### 图表 A：产品功能架构图（必选）
展示核心功能模块及其层级关系。
- 文件名：`[product-name]-architecture.svg`
- 风格：分层色块 + 箭头，清晰展示模块间关联
- 必须包含：用户层、功能层、数据层（或类似的三层结构）
### 图表 B：核心用户旅程图（必选）
展示用户从发现问题到完成目标的完整路径，**必须包含异常路径**。
- 文件名：`[product-name]-user-journey.svg`
- 风格：横向流程 + 状态标注 + 情绪曲线（可选）
- 必须包含：触发点、关键节点、决策分叉、异常处理、成功终态
### 图表 C（视产品类型选择其一）：
- **竞品对比矩阵**（有明确竞品时）：`[product-name]-competitor-matrix.svg`
- **数据流图**（技术型/数据型产品）：`[product-name]-data-flow.svg`
- **商业模式关键要素**（B端/平台类产品）：`[product-name]-business-model.svg`
### SVG 技术规范
```
viewBox="0 0 860 [适当高度]"
font-family="'PingFang SC', 'Helvetica Neue', Arial, sans-serif"
使用 defs 定义 linearGradient 和 filter shadow
配色方案：
主色：#4f46e5（靛蓝）或 #0f766e（深青）
成功/正向：#10b981（绿）
警告/注意：#f59e0b（琥珀）
错误/风险：#ef4444（红）
辅助文字：#64748b
背景：#f8fafc 或 white
每个图表包含：标题行 + 图例（如有）+ 内容 + 底部说明
SVG 必须独立保存为文件，在 Markdown 中用  引用
```
---
## Step 4：PRD Markdown 文件结构
文件命名：`[product-name-en]-prd.md`（英文小写，连字符分隔）
### 完整 PRD 模板
```markdown
# [产品名称] PRD
> [一句话定位：这个产品为谁解决了什么问题，通过什么方式，预期带来什么价值]
**文档类型**：PRD（产品需求文档）
**文档状态**：草稿 / 评审中 / 已批准
**版本**：v1.0
**作者**：[PM 姓名]
**最后更新**：[日期]
**阅读时长**：约 X 分钟
---
## 一、执行摘要（Executive Summary）
[3-5句话的高管版摘要，包含：
- 我们在解决什么问题（问题规模）
- 我们的解决方案是什么（一句话）
- 成功后能带来什么商业价值（量化预期）]
---
## 二、问题定义
### 2.1 背景与现状
[市场背景，数据支撑，不超过200字。来自 Step 2 搜索结果]
### 2.2 用户痛点（JTBD 框架）
**当** [目标用户] **在** [使用场景] **时，**
他们需要 [完成某个任务/达到某个目标]，
但目前面临 [具体障碍]，
导致 [业务/用户体验影响，尽量量化]。
### 2.3 目标用户
**主要用户群体**：[描述]
**用户画像**：
- 人口属性：[年龄 / 职业 / 地域 / 数字化程度]
- 核心使用场景：[什么时候、在哪里、为什么用]
- 当前替代方案：[他们现在怎么解决这个问题]
- 最痛的三个点：[按严重程度排序]
### 2.4 市场机会
| 指标 | 数值 | 来源 |
|------|------|------|
| TAM（总可寻址市场） | | [来源] |
| SAM（可服务市场） | | [来源] |
| SOM（可获取份额） | | 推断 |
| 市场增长率 | | [来源] |
---
## 三、解决方案
### 3.1 产品定位
> 我们是 **[产品类型]**，帮助 **[目标用户]** **[核心价值主张]**，不像 **[竞品]**，我们 **[差异化]**。
### 3.2 功能架构
*[一句话说明图的阅读方式]*
### 3.3 核心功能（MoSCoW 优先级）
> ⚠️ 注意：Must Have 应严格控制，"所有功能都是 Must"意味着 PRD 未完成取舍。
#### ✅ Must Have（MVP 必须包含，缺失则不可上线）
| 功能 | 用户故事 | 验收标准 | 优先级 |
|------|---------|---------|--------|
| [功能1] | As a [用户类型], I want [行为], so that [目的] | Given [前置条件] When [用户操作] Then [系统响应+性能指标] | P0 |
#### 🔶 Should Have（重要但 MVP 可简化版本交付）
| 功能 | 用户故事 | 优先级 |
|------|---------|--------|
| [功能] | As a [用户], I want [行为], so that [目的] | P1 |
#### 🔷 Could Have（有余力再做，不影响核心价值）
- [功能列表，简述即可]
#### ❌ Won't Have（本期明确不做——这行和上面同等重要）
| 功能 | 排除原因 |
|------|---------|
| [功能] | [资源限制 / 复杂度过高 / 非核心路径] |
### 3.4 核心用户旅程
*[说明图中的关键决策节点和异常路径处理]*
### 3.5 非功能需求
| 维度 | 要求 | 验证方式 |
|------|------|---------|
| 性能 | [页面加载 ≤ Xms / P95 响应时间 ≤ Xms] | 压测 / 监控 |
| 安全 | [数据加密标准 / 合规要求] | 安全审计 |
| 可用性 | [99.X% Uptime SLA] | 监控告警 |
| 扩展性 | [支持 X 并发用户 / X QPS] | 架构评审 |
| 兼容性 | [支持的平台/浏览器版本] | 兼容性测试 |
---
## 四、竞品分析
[竞品对比，说明差异化优势。如生成了竞品矩阵 SVG，在此引用]
| 维度 | 我们 | 竞品A | 竞品B |
|------|------|-------|-------|
| 核心功能 | | | |
| 目标用户 | | | |
| 定价模式 | | | |
| 差异化 | ✅ | | |
---
## 五、成功指标
### 5.1 北极星指标（North Star Metric）
> **[唯一最重要的指标名称]**：[具体计算口径]
>
> 选择理由：[为什么这个指标能同时反映用户价值和商业价值]
### 5.2 分层指标体系
**输入指标**（你能直接影响的）：
| 指标 | 基线 | 目标值（3个月） | 观测周期 |
|------|------|--------------|---------|
| [核心功能使用率] | | | 周 |
| [核心流程完成率] | | | 周 |
| [用户留存率] | | | 月 |
**护栏指标**（不能因为优化北极星而损害的底线）：
| 指标 | 红线 |
|------|------|
| 错误率 | ≤ X% |
| 投诉率 | 不高于基线 |
| 核心链路可用性 | ≥ 99.X% |
### 5.3 实验设计
- **A/B 测试方案**：[实验组 vs. 对照组的划分逻辑]
- **最小可检测效果（MDE）**：[能检测到多大的指标变化]
- **实验周期**：[X 周，需避开节假日和大促干扰]
- **灰度策略**：5% → 20% → 50% → 100%
- **回滚条件**：[出现什么数据信号（具体数字）立即停止并回滚]
---
## 六、执行计划
### 6.1 范围边界
**In Scope（本期包含）**：
- [功能/能力列表]
**Out of Scope（本期不做——和功能清单同等重要）**：
- [明确排除的功能，及原因：资源/复杂度/战略优先级]
### 6.2 里程碑
> 里程碑 = 可验证的交付物，不是时间点
| 阶段 | 可验证交付物 | 时间节点 | 负责人 |
|------|------------|---------|--------|
| Discovery 完成 | 用研报告通过 + 竞品分析输出 | [日期] | PM |
| 设计评审通过 | 高保真原型 + 核心流程走通 | [日期] | Design |
| 技术方案确认 | 架构评审 + 技术风险识别 | [日期] | Tech Lead |
| MVP 开发完成 | 核心 P0 功能通过 UAT | [日期] | 全团队 |
| 灰度上线 | 5% 用户 + 监控正常 | [日期] | PM + Dev |
| 全量上线 | 指标验证通过 | [日期] | PM |
### 6.3 资源需求
| 角色 | 工作量（人天） | 主要职责 |
|------|-------------|---------|
| 产品经理 | | 需求管理、跨团队协调、指标追踪 |
| 设计师 | | 原型设计、交互规范 |
| 前端工程师 | | |
| 后端工程师 | | |
| 测试工程师 | | 测试方案、UAT |
---
## 七、风险评估
| 风险类型 | 具体风险描述 | 可能性 | 影响程度 | 应对方案 |
|---------|------------|--------|---------|---------|
| 技术风险 | [如：第三方 API 稳定性] | 中 | 高 | [降级方案 + SLA 协议] |
| 市场风险 | [如：竞品抢先上线] | 低 | 高 | [差异化策略] |
| 资源风险 | [如：关键工程师离职] | 低 | 中 | [文档化 + 知识转移] |
| 合规风险 | [如：数据隐私合规] | 低 | 极高 | [法务提前介入] |
| 假设失效风险 | [如：用户访谈结论有偏差] | 中 | 高 | [MVP 快速验证 + 预设回滚] |
---
## 八、干系人与审批
### 8.1 RACI 矩阵
| 事项 | PM | 工程 | 设计 | 运营 | 法务 | 管理层 |
|------|----|----|------|------|------|------|
| 需求确认 | R | C | C | C | I | A |
| 技术方案 | C | R | I | | | I |
| 设计评审 | A | C | R | C | | I |
| 上线决策 | R | C | C | C | C | A |
| 数据验收 | R | C | | C | | I |
*R=负责执行 A=最终拍板 C=需要咨询 I=需要知会*
### 8.2 审批记录
| 干系人 | 角色 | 意见摘要 | 签字日期 |
|--------|------|---------|---------|
| | | | |
---
## 九、附录
### 9.1 关键假设清单
> [待确认] 标记的字段，上线前需确认
| 编号 | 假设内容 | 验证方式 | 状态 |
|------|---------|---------|------|
| A1 | [如：用户愿意为此付费] | 用户访谈 / MVP 验证 | 待确认 |
### 9.2 术语表
| 术语 | 定义 |
|------|------|
| [专有名词] | [定义] |
### 9.3 参考文档
- [ ] 用户研究报告：[链接]
- [ ] 竞品分析报告：[链接]
- [ ] 技术可行性评估：[链接]
- [ ] 数据分析报告：[链接]
- [ ] 法务合规意见：[链接]
### 9.4 修订历史
| 版本 | 日期 | 修改内容 | 修改人 |
|------|------|---------|--------|
| v1.0 | [日期] | 初始版本 | |
```
---
## 写作质量核查清单
### WHY 层（问题定义）
- [ ] 是否用 JTBD 格式（当/在/需要/面临/导致）写出用户痛点？
- [ ] 用户痛点是否有具体数字支撑（用研数据 or 市场数据）？
- [ ] 是否明确区分了"用户问题"和"解决方案"（别把功能写成痛点）？
- [ ] 市场机会是否覆盖 TAM/SAM/SOM 三层？
### WHAT 层（功能规格）
- [ ] Must Have 功能是否严格克制（不超过 5 个核心功能）？
- [ ] 所有 Must Have 是否有 Given/When/Then 验收标准？
- [ ] 验收标准是否包含性能指标（数字，不是"快速"）？
- [ ] 是否写了 Won't Have 并注明原因？
- [ ] MoSCoW 是否有真正的分层（不全是 Must）？
### HOW 层（执行计划）
- [ ] 用户旅程图是否覆盖了异常路径（不只是 Happy Path）？
- [ ] 里程碑是否是"可验证交付物"而非"时间点"？
- [ ] 非功能需求是否包含性能、安全、可用性、扩展性？
- [ ] 是否有明确的 Out of Scope？
### MEASURE 层（成功指标）
- [ ] 是否定义了唯一的北极星指标？
- [ ] 是否区分了输入指标和护栏指标？
- [ ] 所有指标是否有基线值和目标值（数字）？
- [ ] A/B 测试方案是否包含回滚条件（具体触发数字）？
### 图表质量
- [ ] 架构图是否展示了三层结构（用户/功能/数据）？
- [ ] 用户旅程图是否有异常路径处理？
- [ ] SVG 是否单独保存为文件并在 Markdown 中正确引用？
- [ ] 每张图是否有标题和简短说明？
### 整体文档
- [ ] 执行摘要能否让不懂背景的人 1 分钟内理解核心价值？
- [ ] 所有 [待确认] 字段是否在文档中明确标注？
- [ ] 是否有清晰的 RACI 和审批链条？
- [ ] 风险评估是否覆盖技术、市场、资源、合规、假设失效五个维度？
---
## 特殊场景处理
### 场景 A：用户只给了一句话 idea
直接推演所有信息，用 **[待确认]** 标注推断字段，生成完整文档后告知用户哪些需要补充确认。
### 场景 B：用户给了详细描述
提取关键信息直接填充模板，搜索市场数据补充背景章节，无需打断流程问问题。
### 场景 C：用户要求简版 PRD（1-2页）
只生成以下核心章节：
- JTBD 问题定义（必须）
- Must Have 功能 + 验收标准（必须）
- 北极星指标（必须）
- 里程碑（必须）
- 省略：竞品分析、RACI、附录
### 场景 D：B 端产品 PRD
- 竞品分析部分增加"购买决策链分析"（谁付钱/谁决策/谁使用）
- 成功指标加入客户成功指标：NPS / Churn Rate / ARR
- 用户旅程区分"购买旅程"和"使用旅程"两条线
### 场景 E：内部工具 PRD
- 简化市场分析（替换为"内部现状分析"）
- 增加"效率提升量化"章节（ROI 测算）
- 指标侧重内部 ROI 和工时节省
### 场景 F：Agile 团队 PRD
- 强调"活文档"属性：标注当前 Sprint 范围
- 功能章节按 Epic → Story 层级组织
- 里程碑对应 Sprint 而非月份
---
## 输出文件清单
生成完成后，`markdown/` 目录应包含：
```
markdown/
├── [product-name]-prd.md ← 主文档
├── [product-name]-architecture.svg ← 功能架构图（必选）
├── [product-name]-user-journey.svg ← 用户旅程图（必选）
└── [product-name]-*.svg ← 其他可选图表
```
---
## 触发示例
以下均应触发本 Skill：
- "帮我写一份 PRD，产品是一个帮助设计师管理灵感的 App"
- "我想做一个企业内部的知识库系统，帮我出一份需求文档"
- "有个 idea：给餐厅做一个 AI 点餐助手，帮我写成 PRD"
- "写个 PRD 模板"
- "产品立项需要一份产品需求文档，我们要做 XX"
- "帮我把这个产品想法整理成文档，方便跟团队对齐"
- "我想做个 XX，帮我写 PRD"
- "用 JTBD 框架帮我写需求文档"
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Use when executing implementation plans with independent tasks in the current session