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 后，不要立刻问问题，而是先做推演：

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

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

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

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

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

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

搜索关键词格式：[产品领域] 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"
"帮我把这个产品想法整理成文档，方便跟团队对齐"

write-brd