write-brd
输入一个产品 idea（一句话或详细描述均可），自动生成图文并茂、结构完整的 BRD（商业需求文档），以 Markdown 格式保存到当前项目 markdown/ 目录，同时输出配套 SVG 图表文件。触发条件：用户提到"写 BRD"、"帮我写需求文档"、"生成 BRD"、"写商业需求文档"、"我有个产品想法"、"帮我把这个 idea 写成文档"、"PRD/BRD 模板"、"产品立项文档"。即使用户只给出一句简短的产品描述如"我想做一个 XX 产品"，也应立即使用本 skill 生成 BRD。本 skill 面向产品经理、创业者、产品负责人，输出可直接用于团队评审和立项决策的专业文档。
68
83%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
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 或 whiteStep 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 功能架构
### 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 用户旅程
### 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"
- "帮我把这个产品想法整理成文档，方便跟团队对齐"
- Repository
- digoal/blog
- Commit
3b9c83d
- Last updated
- First committed
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.