发布说明生成器

将技术工单、产品需求文档（PRD）或内部变更日志转换为精美、面向用户的发布说明。

背景

您正在为$ARGUMENTS 编写发布说明。

如果用户提供了文件（JIRA 导出、Linear 工单、产品需求文档、Git 日志或内部变更日志），请先阅读这些文件。如果文件中提到了产品网址，请通过网络搜索了解该产品及其受众。

操作指南

收集原始材料：阅读所有提供的工单、变更日志或说明文档。提取：
- 发生了哪些变化（功能、改进或修复）
- 受影响对象（哪些用户群体）
- 为何重要（用户收益）
对变更进行分类：
- 新功能：完全全新的功能
- 改进：对现有功能的增强
- 错误修复：已解决的问题
- 破坏性变更：任何需要用户采取行动的内容（迁移、API 变更）
- 弃用功能：即将停用的功能
请遵循以下原则撰写每条说明：
- 以用户收益为开头，而非技术变更
- 使用通俗易懂的语言——避免使用行话、内部代号或工单编号
- 每条条目控制在 1-3 句话内
- 若用户提供了相关图表或截图，请一并附上
示例转换：
- 技术表述：“为仪表盘 API 端点实现了 Redis 缓存层”
- 面向用户："仪表盘加载速度最高可达原来的3倍，因此您无需再花时间等待，可以有更多时间进行分析。"
- 技术表述：“修复了并发结账流程中的竞争条件”
- 面向用户："修复了高流量期间部分订单可能失败的问题。"

发布说明的结构：

# [产品名称] — [版本 / 日期]

## 新功能
- **[功能名称]**：[1-2句话描述其功能及重要性]

## 改进
- **[领域]**：[哪些方面得到了改进以及如何带来帮助]

## 错误修复
- 修复了 [用用户通俗语言描述的问题]

## 兼容性变更（如有）
- **需要采取的行动**：[用户需要做什么]

调整语气以符合产品风格——B2B 产品采用专业语气，面向消费者的产品采用亲切语气，API 相关内容则侧重开发者视角。

保存为 Markdown 文档。如果用户需要 HTML 或其他格式，请进行相应转换。

在 GitHub 上查看

---
name: release-notes
description: Transform technical tickets, PRDs, or changelogs into polished, user-facing release notes organized by category.
---

## Release Notes Generator

Transform technical tickets, PRDs, or internal changelogs into polished, user-facing release notes.

### Context

You are writing release notes for **$ARGUMENTS**.

If the user provides files (JIRA exports, Linear tickets, PRDs, Git logs, or internal changelogs), read them first. If they mention a product URL, use web search to understand the product and audience.

### Instructions

1. **Gather raw material**: Read all provided tickets, changelogs, or descriptions. Extract:
   - What changed (feature, improvement, or fix)
   - Who it affects (which user segment)
   - Why it matters (the user benefit)

2. **Categorize changes**:
   - **New Features**: Entirely new capabilities
   - **Improvements**: Enhancements to existing features
   - **Bug Fixes**: Issues resolved
   - **Breaking Changes**: Anything that requires user action (migrations, API changes)
   - **Deprecations**: Features being sunset

3. **Write each entry** following these principles:
   - Lead with the user benefit, not the technical change
   - Use plain language — avoid jargon, internal codenames, or ticket numbers
   - Keep each entry to 1-3 sentences
   - Include visuals or screenshots if the user provides them

   **Example transformations**:
   - Technical: "Implemented Redis caching layer for dashboard API endpoints"
   - User-facing: "Dashboards now load up to 3× faster, so you spend less time waiting and more time analyzing."

   - Technical: "Fixed race condition in concurrent checkout flow"
   - User-facing: "Fixed an issue where some orders could fail during high-traffic periods."

4. **Structure the release notes**:

   ```
   # [Product Name] — [Version / Date]

   ## New Features
   - **[Feature name]**: [1-2 sentence description of what it does and why it matters]

   ## Improvements
   - **[Area]**: [What got better and how it helps]

   ## Bug Fixes
   - Fixed [issue description in user terms]

   ## Breaking Changes (if any)
   - **Action required**: [What users need to do]
   ```

5. **Adjust tone** to match the product's voice — professional for B2B, friendly for consumer, developer-focused for APIs.

Save as a markdown document. If the user wants HTML or another format, convert accordingly.

所有文件

1 个文件

release-notes.md 2.5k

查看

安装 release-notes

下载技能文件并将其解压到 .claude/skills/ 目录中。

下载ZIP

克隆仓库并复制技能文件到您的项目中。

git clone https://github.com/phuryn/pm-skills/tree/main/pm-execution/skills/release-notes # Copy SKILL.md to your .claude/skills/ directory

复制

快速设置: 将技能文件夹复制到 .claude/skills/ Claude 会自动检测并使用该技能

仓库 phuryn/pm-skills

release-notes

发布说明生成器

背景

操作指南

所有文件

安装 release-notes

相关技能