prd-writing

Name: prd-writing
Author: echoVic

554stars48forks

How to install prd-writing?

echovic/boss-skill/prd-writing

$npx -y skills add echoVic/boss-skill --skill prd-writing

Installs into the current project.

Summary

产品需求文档(PRD)的标准编写格式和内容要求，确保输出完整、清晰、可执行的产品文档

Files · 1

View on GitHub

SKILL.md

1	# PRD 编写指南
2
3	## 适用场景
4
5	完成需求穿透和调研分析后，需要输出一份完整的产品需求文档(PRD)，供设计师、开发者、测试人员使用。
6
7	## PRD 标准结构
8
9	### 1. 概述
10
11	- 功能名称：[清晰简洁的名称]
12	- 版本：1.0
13	- 日期：[当前日期]
14	- 作者：PM Agent
15
16	### 摘要
17
18	> 下游 Agent 请优先阅读本节，需要细节时再查阅完整文档。
19
20	- 核心目标：[用一句话描述]
21	- 目标用户：[主要用户群体]
22	- 关键功能：[3-5 个最核心功能]
23	- 技术约束：[重要约束或偏好]
24	- 优先级：[MVP 范围说明]
25
26	---
27
28	### 2. 需求穿透分析（核心章节）
29
30	参见 `pm/requirement-penetration` skill 的输出要求。
31
32	---
33
34	### 3. 竞品调研
35
36	#### 3.1 竞品分析
37
38	使用 `WebSearch` 搜索相关竞品：
39
40	\| 竞品 \| 核心功能 \| 用户体验亮点 \| 用户痛点 \| 我们的机会 \|
41	\|------\|----------\|--------------\|----------\|------------\|
42	\| [竞品 1] \| [功能] \| [亮点] \| [痛点] \| [机会] \|
43	\| [竞品 2] \| [功能] \| [亮点] \| [痛点] \| [机会] \|
44	\| [竞品 3] \| [功能] \| [亮点] \| [痛点] \| [机会] \|
45
46	#### 3.2 差异化策略
47
48	\| 维度 \| 竞品做法 \| 我们的做法 \| 差异化价值 \|
49	\|------\|----------\|------------\|------------\|
50	\| [维度 1] \| [做法] \| [做法] \| [价值] \|
51	\| [维度 2] \| [做法] \| [做法] \| [价值] \|
52
53	---
54
55	### 4. 目标用户
56
57	#### 用户画像 1：[名称]
58
59	- 基本特征：[年龄、职业、收入等]
60	- 行为特征：[使用习惯、偏好等]
61	- 核心需求：[最想解决的问题]
62	- 痛点场景：[具体的痛苦场景描述]
63	- 期望体验：[理想的体验是什么样]
64
65	#### 用户旅程图
66
67	```mermaid
68	journey
69	title 用户完成核心任务的旅程
70	section 发现阶段
71	了解产品: 3: 用户
72	产生兴趣: 4: 用户
73	section 使用阶段
74	首次使用: 3: 用户
75	完成任务: 5: 用户
76	section 留存阶段
77	持续使用: 4: 用户
78	推荐他人: 5: 用户
79	```
80
81	---
82
83	### 5. 功能需求
84
85	#### FR-001：[需求标题]
86
87	- 需求描述：[清晰的需求描述]
88	- 用户价值：[这个功能给用户带来什么价值]
89	- 优先级：P0/P1/P2
90	- 需求来源：显性/隐性/潜在/惊喜
91	- 验收标准：
92	- [ ] AC-1：[可测试的标准 1]
93	- [ ] AC-2：[可测试的标准 2]
94	- 边界情况：
95	- [边界情况 1 及处理方式]
96	- [边界情况 2 及处理方式]
97
98	#### FR-002：[需求标题]
99
100	- 需求描述：[描述]
101	- 用户价值：[价值]
102	- 优先级：P1
103	- 需求来源：[来源]
104	- 验收标准：
105	- [ ] AC-1：[标准]
106
107	---
108
109	### 6. 非功能需求
110
111	#### NFR-001：性能需求
112
113	- 页面加载：首屏加载 < 2s，完整加载 < 3s
114	- 交互响应：用户操作响应 < 100ms
115	- API 响应：接口响应 < 200ms
116
117	#### NFR-002：体验需求
118
119	- 易用性：新用户无需教程即可完成核心任务
120	- 一致性：交互模式和视觉风格保持一致
121	- 容错性：操作可撤销，错误可恢复
122
123	#### NFR-003：安全需求
124
125	- 数据安全：敏感数据加密存储和传输
126	- 隐私保护：符合相关隐私法规
127
128	---
129
130	### 7. 用户故事
131
132	#### US-001：[故事标题]
133
134	- 作为 [用户类型]
135	- 我想要 [目标行为]
136	- 以便 [预期价值]
137	- 验收标准：
138	- [ ] [标准 1]
139	- [ ] [标准 2]
140	- 优先级：P0
141
142	#### US-002：[故事标题]
143
144	- 作为 [用户类型]
145	- 我想要 [目标行为]
146	- 以便 [预期价值]
147	- 验收标准：
148	- [ ] [标准]
149	- 优先级：P1
150
151	---
152
153	### 8. 成功指标
154
155	\| 指标类型 \| 指标 \| 目标值 \| 衡量方式 \|
156	\|----------\|------\|--------\|----------\|
157	\| 核心指标 \| [指标] \| [目标] \| [方式] \|
158	\| 体验指标 \| [指标] \| [目标] \| [方式] \|
159	\| 业务指标 \| [指标] \| [目标] \| [方式] \|
160
161	---
162
163	### 9. 范围定义
164
165	#### 本期范围（In Scope）
166
167	- [功能 1]
168	- [功能 2]
169
170	#### 范围外（Out of Scope）
171
172	- [排除项 1]：[排除原因]
173	- [排除项 2]：[排除原因]
174
175	---
176
177	### 10. 风险与依赖
178
179	#### 风险登记
180
181	\| 风险 \| 可能性 \| 影响 \| 缓解措施 \|
182	\|------\|--------\|------\|----------\|
183	\| [风险] \| 高/中/低 \| 高/中/低 \| [措施] \|
184
185	#### 依赖项
186
187	\| 依赖 \| 类型 \| 状态 \| 负责人 \|
188	\|------\|------\|------\|--------\|
189	\| [依赖项] \| 技术/业务/外部 \| 已就绪/待定 \| [负责人] \|
190
191	---
192
193	### 11. 里程碑
194
195	\| 里程碑 \| 内容 \| 目标日期 \|
196	\|--------\|------\|----------\|
197	\| MVP \| [核心功能] \| - \|
198	\| V1.0 \| [完整功能] \| - \|
199	\| V1.1 \| [优化迭代] \| - \|
200
201	---
202
203	## 编写原则
204
205	### 清晰性
206	- 使用简单直接的语言
207	- 避免模糊词汇（"可能"、"大概"、"尽量"）
208	- 每个需求都有明确的验收标准
209
210	### 完整性
211	- 覆盖所有必要章节
212	- 功能需求和非功能需求都要考虑
213	- 边界情况和异常处理要说明
214
215	### 可执行性
216	- 设计师能根据PRD设计界面
217	- 开发者能根据PRD编写代码
218	- 测试人员能根据PRD编写测试用例
219
220	### 用户导向
221	- 每个功能都说明用户价值
222	- 从用户视角描述需求
223	- 关注用户体验细节
224
225	## 输出要求
226
227	1. 文件命名：`prd-{功能名称}-{日期}.md`
228	2. 文件位置：项目根目录或 `docs/` 目录
229	3. 格式：Markdown格式，使用标准的章节结构
230	4. 长度：根据功能复杂度，通常5-20页
231
232	## 质量检查清单
233
234	在输出PRD前，检查以下项目：
235
236	- [ ] 摘要部分是否清晰，能让读者快速理解核心内容
237	- [ ] 需求穿透分析是否完整（显性、隐性、潜在、惊喜四层）
238	- [ ] 每个功能需求是否有明确的验收标准
239	- [ ] 非功能需求是否考虑（性能、体验、安全）
240	- [ ] 用户故事是否符合 "作为-我想要-以便" 格式
241	- [ ] 范围定义是否明确（In Scope 和 Out of Scope）
242	- [ ] 风险和依赖是否识别
243	- [ ] 文档格式是否规范，易于阅读
244
245	---
246
247	记住：好的PRD不是功能的堆砌，而是对用户需求的精准洞察和优雅满足。

People who liked this also viewed

6 picks

Type

prd-writing

554stars48forks

View on GitHub

How to install prd-writing?

echovic/boss-skill/prd-writing

$npx -y skills add echoVic/boss-skill --skill prd-writing

Installs into the current project.

Summary

产品需求文档(PRD)的标准编写格式和内容要求，确保输出完整、清晰、可执行的产品文档

Files · 1

View on GitHub

SKILL.md

1	# PRD 编写指南
2
3	## 适用场景
4
5	完成需求穿透和调研分析后，需要输出一份完整的产品需求文档(PRD)，供设计师、开发者、测试人员使用。
6
7	## PRD 标准结构
8
9	### 1. 概述
10
11	- 功能名称：[清晰简洁的名称]
12	- 版本：1.0
13	- 日期：[当前日期]
14	- 作者：PM Agent
15
16	### 摘要
17
18	> 下游 Agent 请优先阅读本节，需要细节时再查阅完整文档。
19
20	- 核心目标：[用一句话描述]
21	- 目标用户：[主要用户群体]
22	- 关键功能：[3-5 个最核心功能]
23	- 技术约束：[重要约束或偏好]
24	- 优先级：[MVP 范围说明]
25
26	---
27
28	### 2. 需求穿透分析（核心章节）
29
30	参见 `pm/requirement-penetration` skill 的输出要求。
31
32	---
33
34	### 3. 竞品调研
35
36	#### 3.1 竞品分析
37
38	使用 `WebSearch` 搜索相关竞品：
39
40	\| 竞品 \| 核心功能 \| 用户体验亮点 \| 用户痛点 \| 我们的机会 \|
41	\|------\|----------\|--------------\|----------\|------------\|
42	\| [竞品 1] \| [功能] \| [亮点] \| [痛点] \| [机会] \|
43	\| [竞品 2] \| [功能] \| [亮点] \| [痛点] \| [机会] \|
44	\| [竞品 3] \| [功能] \| [亮点] \| [痛点] \| [机会] \|
45
46	#### 3.2 差异化策略
47
48	\| 维度 \| 竞品做法 \| 我们的做法 \| 差异化价值 \|
49	\|------\|----------\|------------\|------------\|
50	\| [维度 1] \| [做法] \| [做法] \| [价值] \|
51	\| [维度 2] \| [做法] \| [做法] \| [价值] \|
52
53	---
54
55	### 4. 目标用户
56
57	#### 用户画像 1：[名称]
58
59	- 基本特征：[年龄、职业、收入等]
60	- 行为特征：[使用习惯、偏好等]
61	- 核心需求：[最想解决的问题]
62	- 痛点场景：[具体的痛苦场景描述]
63	- 期望体验：[理想的体验是什么样]
64
65	#### 用户旅程图
66
67	```mermaid
68	journey
69	title 用户完成核心任务的旅程
70	section 发现阶段
71	了解产品: 3: 用户
72	产生兴趣: 4: 用户
73	section 使用阶段
74	首次使用: 3: 用户
75	完成任务: 5: 用户
76	section 留存阶段
77	持续使用: 4: 用户
78	推荐他人: 5: 用户
79	```
80
81	---
82
83	### 5. 功能需求
84
85	#### FR-001：[需求标题]
86
87	- 需求描述：[清晰的需求描述]
88	- 用户价值：[这个功能给用户带来什么价值]
89	- 优先级：P0/P1/P2
90	- 需求来源：显性/隐性/潜在/惊喜
91	- 验收标准：
92	- [ ] AC-1：[可测试的标准 1]
93	- [ ] AC-2：[可测试的标准 2]
94	- 边界情况：
95	- [边界情况 1 及处理方式]
96	- [边界情况 2 及处理方式]
97
98	#### FR-002：[需求标题]
99
100	- 需求描述：[描述]
101	- 用户价值：[价值]
102	- 优先级：P1
103	- 需求来源：[来源]
104	- 验收标准：
105	- [ ] AC-1：[标准]
106
107	---
108
109	### 6. 非功能需求
110
111	#### NFR-001：性能需求
112
113	- 页面加载：首屏加载 < 2s，完整加载 < 3s
114	- 交互响应：用户操作响应 < 100ms
115	- API 响应：接口响应 < 200ms
116
117	#### NFR-002：体验需求
118
119	- 易用性：新用户无需教程即可完成核心任务
120	- 一致性：交互模式和视觉风格保持一致
121	- 容错性：操作可撤销，错误可恢复
122
123	#### NFR-003：安全需求
124
125	- 数据安全：敏感数据加密存储和传输
126	- 隐私保护：符合相关隐私法规
127
128	---
129
130	### 7. 用户故事
131
132	#### US-001：[故事标题]
133
134	- 作为 [用户类型]
135	- 我想要 [目标行为]
136	- 以便 [预期价值]
137	- 验收标准：
138	- [ ] [标准 1]
139	- [ ] [标准 2]
140	- 优先级：P0
141
142	#### US-002：[故事标题]
143
144	- 作为 [用户类型]
145	- 我想要 [目标行为]
146	- 以便 [预期价值]
147	- 验收标准：
148	- [ ] [标准]
149	- 优先级：P1
150
151	---
152
153	### 8. 成功指标
154
155	\| 指标类型 \| 指标 \| 目标值 \| 衡量方式 \|
156	\|----------\|------\|--------\|----------\|
157	\| 核心指标 \| [指标] \| [目标] \| [方式] \|
158	\| 体验指标 \| [指标] \| [目标] \| [方式] \|
159	\| 业务指标 \| [指标] \| [目标] \| [方式] \|
160
161	---
162
163	### 9. 范围定义
164
165	#### 本期范围（In Scope）
166
167	- [功能 1]
168	- [功能 2]
169
170	#### 范围外（Out of Scope）
171
172	- [排除项 1]：[排除原因]
173	- [排除项 2]：[排除原因]
174
175	---
176
177	### 10. 风险与依赖
178
179	#### 风险登记
180
181	\| 风险 \| 可能性 \| 影响 \| 缓解措施 \|
182	\|------\|--------\|------\|----------\|
183	\| [风险] \| 高/中/低 \| 高/中/低 \| [措施] \|
184
185	#### 依赖项
186
187	\| 依赖 \| 类型 \| 状态 \| 负责人 \|
188	\|------\|------\|------\|--------\|
189	\| [依赖项] \| 技术/业务/外部 \| 已就绪/待定 \| [负责人] \|
190
191	---
192
193	### 11. 里程碑
194
195	\| 里程碑 \| 内容 \| 目标日期 \|
196	\|--------\|------\|----------\|
197	\| MVP \| [核心功能] \| - \|
198	\| V1.0 \| [完整功能] \| - \|
199	\| V1.1 \| [优化迭代] \| - \|
200
201	---
202
203	## 编写原则
204
205	### 清晰性
206	- 使用简单直接的语言
207	- 避免模糊词汇（"可能"、"大概"、"尽量"）
208	- 每个需求都有明确的验收标准
209
210	### 完整性
211	- 覆盖所有必要章节
212	- 功能需求和非功能需求都要考虑
213	- 边界情况和异常处理要说明
214
215	### 可执行性
216	- 设计师能根据PRD设计界面
217	- 开发者能根据PRD编写代码
218	- 测试人员能根据PRD编写测试用例
219
220	### 用户导向
221	- 每个功能都说明用户价值
222	- 从用户视角描述需求
223	- 关注用户体验细节
224
225	## 输出要求
226
227	1. 文件命名：`prd-{功能名称}-{日期}.md`
228	2. 文件位置：项目根目录或 `docs/` 目录
229	3. 格式：Markdown格式，使用标准的章节结构
230	4. 长度：根据功能复杂度，通常5-20页
231
232	## 质量检查清单
233
234	在输出PRD前，检查以下项目：
235
236	- [ ] 摘要部分是否清晰，能让读者快速理解核心内容
237	- [ ] 需求穿透分析是否完整（显性、隐性、潜在、惊喜四层）
238	- [ ] 每个功能需求是否有明确的验收标准
239	- [ ] 非功能需求是否考虑（性能、体验、安全）
240	- [ ] 用户故事是否符合 "作为-我想要-以便" 格式
241	- [ ] 范围定义是否明确（In Scope 和 Out of Scope）
242	- [ ] 风险和依赖是否识别
243	- [ ] 文档格式是否规范，易于阅读
244
245	---
246
247	记住：好的PRD不是功能的堆砌，而是对用户需求的精准洞察和优雅满足。

People who liked this also viewed

6 picks

Type