write-brd

name	write-brd
description	输入一个产品 idea（一句话或详细描述均可），自动生成图文并茂、结构完整的 BRD（商业需求文档），以 Markdown 格式保存到当前项目 markdown/ 目录，同时输出配套 SVG 图表文件。触发条件：用户提到"写 BRD"、"帮我写需求文档"、"生成 BRD"、"写商业需求文档"、"我有个产品想法"、"帮我把这个 idea 写成文档"、"PRD/BRD 模板"、"产品立项文档"。即使用户只给出一句简短的产品描述如"我想做一个 XX 产品"，也应立即使用本 skill 生成 BRD。本 skill 面向产品经理、创业者、产品负责人，输出可直接用于团队评审和立项决策的专业文档。

Write BRD Skill

将一个产品 idea 转化为完整、可直接评审的 BRD（Business Requirements Document）。

---

工作流总览

用户输入 Idea
     ↓
Step 1: 信息补全与假设推演
     ↓
Step 2: 搜索市场背景与竞品（web search）
     ↓
Step 3: 生成配套 SVG 图表（独立文件）
     ↓
Step 4: 生成完整 BRD Markdown 文件
     ↓
输出到 markdown/ 目录

---

Step 1：信息补全与假设推演

拿到用户的 idea 后，不要立刻问问题，而是先做推演：

1. 推断目标用户：谁会用这个产品？什么场景下使用？
2. 推断核心问题：他们现在遇到了什么痛点？
3. 推断商业模式：这个产品怎么盈利？或者它服务于什么更大的商业目标？
4. 推断成功指标：上线后看什么数据来判断成功？
5. 识别需要澄清的关键信息（如果有的话，在生成文档前一次性问完，不超过 3 个问题）

如果用户提供的信息足够（或者可以合理推断），直接进入 Step 2，不要打断流程问问题。

推断优先于询问，在 BRD 中标注"[待确认]"的字段，告知用户哪些是推断。

---

Step 2：搜索市场背景（使用 web_search）

搜索以下信息，用于充实 BRD 背景章节：

1. 该领域的市场规模数据（TAM/SAM）
2. 主要竞品和竞品的核心功能
3. 行业近期趋势（政策、技术、用户行为变化）
4. 参考类似产品的成功/失败案例

搜索关键词格式：[产品领域] market size, [产品类型] competitors, [用户痛点] trends 2024

---

Step 3：生成 SVG 图表

必须生成以下至少 2 个 SVG 图表，保存到 markdown/ 目录：

图表 A：产品功能架构图（必选）

• 展示核心功能模块及其关系
• 文件名：[product-name]-architecture.svg
• 风格：简洁，用色块区分模块，有箭头表示关联

图表 B：用户旅程图 / 核心流程图（必选）

• 展示用户从发现问题到完成目标的完整路径
• 文件名：[product-name]-user-journey.svg
• 风格：横向流程，有状态标注

图表 C（可选，根据产品类型选择）：

• 竞品对比矩阵（有竞品时生成）
• 商业模式画布关键要素（B端产品）
• 数据流图（技术型产品）

SVG 技术规范：

viewBox="0 0 820 [适当高度]"
font-family="'PingFang SC', 'Helvetica Neue', Arial, sans-serif"
使用渐变色增强视觉层次
添加 filter shadow 增强立体感
配色参考：
  主色调：#667eea（科技蓝紫）
  成功色：#43a047（绿）
  警告色：#e65100（橙）
  危险色：#c62828（红）
背景：#f7f8fc 或 white

---

Step 4：BRD Markdown 文件结构

文件命名：[product-name-en]-brd.md（英文小写，连字符分隔）

完整 BRD 模板

# [产品名称] BRD

> [一句话摘要：这个产品为谁解决了什么问题，通过什么方式]

**文档状态**：草稿 / 评审中 / 已批准  
**版本**：v1.0  
**作者**：[PM 姓名]  
**最后更新**：[日期]  
**阅读时长**：约 X 分钟

---

## 一、执行摘要（Executive Summary）

[3-5句话的高管版摘要，包含：问题规模、解决方案、预期商业价值]

---

## 二、问题定义

### 2.1 背景与现状
[市场背景，数据支撑，不超过200字]

### 2.2 用户痛点（JTBD 框架）
当 [目标用户] 在 [使用场景] 时，
他们需要 [完成某个任务/达到某个目标]，
但目前面临 [具体障碍]，
导致 [业务/用户体验影响]。

### 2.3 目标用户
**主要用户群体**：[描述]
**用户画像**：
- 人口属性：[年龄/职业/地域]
- 使用场景：[什么时候、在哪里、为什么]
- 当前行为：[他们现在怎么解决这个问题]
- 痛点优先级：[最痛的3个点]

### 2.4 市场机会
| 指标 | 数值 | 来源 |
|------|------|------|
| TAM（总市场规模） | | |
| SAM（可服务市场） | | |
| SOM（可获取份额） | | |

---

## 三、解决方案

### 3.1 产品定位
[一句话定位：我们是[产品类型]，帮助[目标用户]，[核心价值主张]，不像[竞品]，我们[差异化]。]

### 3.2 功能架构
![功能架构图]([product-name]-architecture.svg)

### 3.3 核心功能（MoSCoW 优先级）

#### Must Have（MVP 必须包含）
| 功能 | 用户故事 | 验收标准 | 优先级 |
|------|---------|---------|--------|
| [功能1] | As a [用户], I want [行为], so that [目的] | Given [场景] When [动作] Then [结果] | P0 |

#### Should Have（重要但可简化）
[同上格式]

#### Could Have（有余力再做）
[列表形式即可]

#### Won't Have（本期明确不做）
[列表，说明原因]

### 3.4 用户旅程
![用户旅程图]([product-name]-user-journey.svg)

### 3.5 非功能需求
| 维度 | 要求 | 验证方式 |
|------|------|---------|
| 性能 | [具体指标，如页面加载<2s] | 压测 |
| 安全 | [如符合 SOC2 / GDPR] | 安全审计 |
| 可用性 | [如支持 99.9% uptime] | 监控告警 |
| 扩展性 | [如支持 X 并发用户] | 架构评审 |

---

## 四、竞品分析

[竞品对比矩阵或文字分析，说明差异化优势]

---

## 五、成功指标

### 5.1 北极星指标（North Star Metric）
[唯一最重要的指标，及其计算方式]

### 5.2 关键指标体系
| 指标 | 基线 | 目标值 | 观测周期 |
|------|------|--------|---------|
| [核心业务指标] | [当前值] | [目标值] | [周/月] |
| [用户行为指标] | | | |
| [技术质量指标] | | | |

### 5.3 实验设计
- A/B 测试方案：[描述]
- 灰度策略：[5% → 20% → 100%]
- 回滚条件：[出现什么情况触发回滚]

---

## 六、执行计划

### 6.1 范围边界
**In Scope（本期包含）**：
- [功能列表]

**Out of Scope（本期不做）**：
- [明确排除的功能，及原因]

### 6.2 里程碑
| 阶段 | 内容 | 时间节点 | 负责人 |
|------|------|---------|--------|
| Discovery 完成 | 用研报告、竞品分析 | [日期] | PM |
| 设计评审 | 高保真原型通过 | [日期] | Design |
| 技术评审 | 架构方案确认 | [日期] | Tech |
| MVP 上线 | 核心功能可用 | [日期] | 全团队 |
| 数据验证 | 关键指标达标 | [日期] | PM |

### 6.3 资源需求
| 角色 | 工作量（人天） | 备注 |
|------|-------------|------|
| 产品经理 | | |
| 设计师 | | |
| 前端工程师 | | |
| 后端工程师 | | |
| 测试工程师 | | |

---

## 七、风险评估

| 风险 | 可能性 | 影响 | 应对方案 |
|------|--------|------|---------|
| [技术风险] | 中 | 高 | [具体措施] |
| [市场风险] | 低 | 高 | [具体措施] |
| [资源风险] | 中 | 中 | [具体措施] |
| [合规风险] | 低 | 极高 | [具体措施] |

---

## 八、干系人与审批

### 8.1 RACI 矩阵
| 事项 | PM | 工程 | 设计 | 运营 | 法务 | 高层 |
|------|----|----|------|------|------|------|
| 需求确认 | R | C | C | I | I | A |
| 技术方案 | C | R | I | | | I |
| 上线决策 | R | C | C | C | C | A |

*R=负责执行 A=最终决策 C=需咨询 I=需知会*

### 8.2 审批记录
| 干系人 | 角色 | 意见 | 签字日期 |
|--------|------|------|---------|
| | | | |

---

## 九、附录

### 9.1 术语表
[项目专有名词解释]

### 9.2 参考文档
- [用研报告链接]
- [竞品分析报告]
- [技术可行性评估]
- [相关数据分析]

### 9.3 修订历史
| 版本 | 日期 | 修改内容 | 修改人 |
|------|------|---------|--------|
| v1.0 | [日期] | 初始版本 | |

---
*本文档由 write-brd skill 生成 · 请在评审完成后删除此行*

---

写作质量标准

问题定义质量检查

• 是否用 JTBD 格式写出用户痛点？
• 是否有具体数字支撑问题规模（用研数据 or 市场数据）？
• 是否明确区分了"用户问题"和"解决方案"？

功能规格质量检查

• 所有 Must Have 功能是否有验收标准（Given/When/Then）？
• 是否明确写了 Out of Scope？
• MoSCoW 优先级是否有明确分层（不全是 Must）？

图表质量检查

• 架构图是否展示了核心模块及其关系？
• 用户旅程图是否有明确的起点、终点、关键决策节点？
• SVG 是否单独保存为文件并在 Markdown 中正确引用？

指标质量检查

• 是否定义了唯一的北极星指标？
• 所有指标是否可量化（有数值目标和时间节点）？
• 是否设计了验证方式（A/B测试 / 对照组）？

文档整体质量

• 执行摘要能否让不懂背景的人在1分钟内理解核心价值？
• 是否有清晰的决策流程和审批链条？
• 风险评估是否覆盖了技术、市场、资源、合规四个维度？

---

输出文件清单

生成完成后，markdown/ 目录应包含：

markdown/
├── [product-name]-brd.md           ← 主文档
├── [product-name]-architecture.svg  ← 功能架构图
├── [product-name]-user-journey.svg  ← 用户旅程图
└── [product-name]-*.svg            ← 其他可选图表

---

特殊场景处理

场景 A：用户只给了一句话 idea

直接推演，用 [待确认] 标注假设字段，生成完整文档后告知用户哪些需要补充。

场景 B：用户给了详细描述

提取关键信息后按模板生成，无需额外搜索即可完成大部分内容。

场景 C：用户要求简版 BRD（1-2页）

只生成核心章节：问题定义 + Must Have 功能 + 成功指标 + 里程碑，省略其余章节。

场景 D：B 端产品 BRD

在竞品分析部分增加"购买决策链分析"，成功指标加入客户成功指标（NPS / Churn Rate）。

场景 E：内部工具 BRD

简化市场分析部分，增加"效率提升量化"章节，指标侧重内部 ROI。

---

触发示例

以下均应触发本 Skill：

• "帮我写一份 BRD，产品是一个帮助设计师管理灵感的 App"
• "我想做一个企业内部的知识库系统，帮我出一份需求文档"
• "有个 idea：给餐厅做一个 AI 点餐助手，帮我写成 BRD"
• "写个 BRD 模板"
• "产品立项需要一份商业需求文档，我们要做 XX"
• "帮我把这个产品想法整理成文档，方便跟团队对齐"