release-notes

Name: release-notes
Author: killvxk

108stars16forks

How to install release-notes?

killvxk/pm-skills-zh/release-notes

$npx -y skills add killvxk/pm-skills-zh --skill release-notes

Installs into the current project.

Summary

根据工单、PRD（产品需求文档）或变更日志生成面向用户的发布说明，按类别（新功能、改进、修复）整理清晰、有吸引力的摘要。适用于编写发布说明、创建变更日志、发布产品更新公告，或总结本次发布内容。

Files · 1

View on GitHub

SKILL.md

1	## 发布说明生成器
2
3	将技术工单、PRD（产品需求文档）或内部变更日志转化为精致的面向用户发布说明。
4
5	### Context（背景）
6
7	你正在为 $ARGUMENTS 编写发布说明。
8
9	如果用户提供了文件（JIRA 导出、Linear 工单、PRD、Git 日志或内部变更日志），请先阅读。如果他们提到产品 URL，可使用网络搜索了解产品和受众。
10
11	### Instructions（操作指南）
12
13	1. 收集原始素材：阅读所有提供的工单、变更日志或描述，提取：
14	- 变更了什么（功能、改进或修复）
15	- 影响了哪些用户（哪个用户群体）
16	- 为什么重要（用户收益）
17
18	2. 对变更进行分类：
19	- 新功能：全新的能力
20	- 改进：对现有功能的增强
21	- 缺陷修复：已解决的问题
22	- 破坏性变更：任何需要用户采取行动的内容（迁移、API 变更）
23	- 废弃说明：即将下线的功能
24
25	3. 遵循以下原则撰写每个条目：
26	- 以用户收益为先，而非技术变更
27	- 使用通俗语言——避免行话、内部代号或工单编号
28	- 每个条目控制在 1-3 句话
29	- 如果用户提供了视觉稿或截图，附上
30
31	转化示例：
32	- 技术描述："为仪表板 API 端点实现 Redis 缓存层"
33	- 用户版本："仪表板加载速度提升最高 3 倍，让你花更少时间等待，更多时间分析数据。"
34
35	- 技术描述："修复并发结账流程中的竞态条件"
36	- 用户版本："修复了在高流量期间部分订单可能失败的问题。"
37
38	4. 结构化发布说明：
39
40	```
41	# [产品名称] — [版本 / 日期]
42
43	## 新功能
44	- [功能名称]：[1-2 句话描述功能内容及重要性]
45
46	## 改进
47	- [改进方向]：[什么变得更好了，以及如何帮助用户]
48
49	## 缺陷修复
50	- 修复了 [用户语言描述的问题]
51
52	## 破坏性变更（如有）
53	- 需要操作：[用户需要做什么]
54	```
55
56	5. 调整语气以匹配产品的声音——B2B 产品专业严谨，消费者产品亲切友好，API 产品以开发者为中心。
57
58	保存为 Markdown 文档。如果用户需要 HTML 或其他格式，相应转换。

People who liked this also viewed

6 picks

Type

release-notes

108stars16forks

View on GitHub

How to install release-notes?

killvxk/pm-skills-zh/release-notes

$npx -y skills add killvxk/pm-skills-zh --skill release-notes

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## 发布说明生成器
2
3	将技术工单、PRD（产品需求文档）或内部变更日志转化为精致的面向用户发布说明。
4
5	### Context（背景）
6
7	你正在为 $ARGUMENTS 编写发布说明。
8
9	如果用户提供了文件（JIRA 导出、Linear 工单、PRD、Git 日志或内部变更日志），请先阅读。如果他们提到产品 URL，可使用网络搜索了解产品和受众。
10
11	### Instructions（操作指南）
12
13	1. 收集原始素材：阅读所有提供的工单、变更日志或描述，提取：
14	- 变更了什么（功能、改进或修复）
15	- 影响了哪些用户（哪个用户群体）
16	- 为什么重要（用户收益）
17
18	2. 对变更进行分类：
19	- 新功能：全新的能力
20	- 改进：对现有功能的增强
21	- 缺陷修复：已解决的问题
22	- 破坏性变更：任何需要用户采取行动的内容（迁移、API 变更）
23	- 废弃说明：即将下线的功能
24
25	3. 遵循以下原则撰写每个条目：
26	- 以用户收益为先，而非技术变更
27	- 使用通俗语言——避免行话、内部代号或工单编号
28	- 每个条目控制在 1-3 句话
29	- 如果用户提供了视觉稿或截图，附上
30
31	转化示例：
32	- 技术描述："为仪表板 API 端点实现 Redis 缓存层"
33	- 用户版本："仪表板加载速度提升最高 3 倍，让你花更少时间等待，更多时间分析数据。"
34
35	- 技术描述："修复并发结账流程中的竞态条件"
36	- 用户版本："修复了在高流量期间部分订单可能失败的问题。"
37
38	4. 结构化发布说明：
39
40	```
41	# [产品名称] — [版本 / 日期]
42
43	## 新功能
44	- [功能名称]：[1-2 句话描述功能内容及重要性]
45
46	## 改进
47	- [改进方向]：[什么变得更好了，以及如何帮助用户]
48
49	## 缺陷修复
50	- 修复了 [用户语言描述的问题]
51
52	## 破坏性变更（如有）
53	- 需要操作：[用户需要做什么]
54	```
55
56	5. 调整语气以匹配产品的声音——B2B 产品专业严谨，消费者产品亲切友好，API 产品以开发者为中心。
57
58	保存为 Markdown 文档。如果用户需要 HTML 或其他格式，相应转换。

People who liked this also viewed

6 picks

Type