name: deliver-release-notes
description: Creates user-facing release notes that communicate new features, improvements, and fixes in clear, benefit-focused language. Use when shipping updates to communicate changes to users, customers, or stakeholders.
phase: deliver
version: "2.0.0"
updated: 2026-01-26
license: Apache-2.0
metadata:
category: coordination
frameworks: [triple-diamond, lean-startup, design-thinking]
author: product-on-purpose
Release Notes
Release notes communicate product changes to users in a way that highlights value and builds excitement. Unlike changelogs (which document what changed technically), release notes translate changes into user benefits. Good release notes help users discover new capabilities, understand improvements, and trust that issues are being addressed.
When to Use
- Shipping product updates to customers
- Communicating changes to internal stakeholders
- Preparing app store update descriptions
- Writing customer-facing email announcements
- Documenting changes for support and sales teams
Instructions
When asked to create release notes, follow these steps:
Gather the Changelog
Collect all changes included in this release: features, improvements, and bug fixes. Work from engineering changelogs, completed tickets, or pull request descriptions.
Identify the Highlights
Select 1-3 changes that deserve top billing. These should be changes users will notice and care about most. Lead with the most impactful change.
Translate to Benefits
Rewrite each change in terms of user value. Instead of "Added pagination to search results," write "Find what you need faster with improved search that handles large result sets." Focus on what users can now do or what's now better.
Categorize Changes
Group remaining changes into clear categories: New Features, Improvements, and Bug Fixes. Within each category, order by impact (most valuable first).
Write Scannable Descriptions
Each item should be 1-2 sentences. Lead with the benefit, optionally followed by the "how." Users scan release notes — make each line valuable.
Acknowledge Known Issues
If there are known limitations or issues, be transparent. Users appreciate honesty, and it reduces support burden.
Tease Coming Soon (Optional)
If appropriate, hint at what's coming next. This builds anticipation and shows momentum, but don't over-promise.
Output Format
Use the template in references/TEMPLATE.md to structure the output.
Quality Checklist
Before finalizing, verify:
Examples
See references/EXAMPLE.md for a completed example.
1---2name: deliver-release-notes3description: <!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->4---5
6<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
7---
8name: deliver-release-notes
9description: Creates user-facing release notes that communicate new features, improvements, and fixes in clear, benefit-focused language. Use when shipping updates to communicate changes to users, customers, or stakeholders.
10phase: deliver
11version: "2.0.0"
12updated: 2026-01-26
13license: Apache-2.0
14metadata:
15 category: coordination
16 frameworks: [triple-diamond, lean-startup, design-thinking]
17 author: product-on-purpose
18---
19# Release Notes
20
21Release notes communicate product changes to users in a way that highlights value and builds excitement. Unlike changelogs (which document what changed technically), release notes translate changes into user benefits. Good release notes help users discover new capabilities, understand improvements, and trust that issues are being addressed.
22
23## When to Use
24
25- Shipping product updates to customers
26- Communicating changes to internal stakeholders
27- Preparing app store update descriptions
28- Writing customer-facing email announcements
29- Documenting changes for support and sales teams
30
31## Instructions
32
33When asked to create release notes, follow these steps:
34
351. **Gather the Changelog**
36 Collect all changes included in this release: features, improvements, and bug fixes. Work from engineering changelogs, completed tickets, or pull request descriptions.
37
382. **Identify the Highlights**
39 Select 1-3 changes that deserve top billing. These should be changes users will notice and care about most. Lead with the most impactful change.
40
413. **Translate to Benefits**
42 Rewrite each change in terms of user value. Instead of "Added pagination to search results," write "Find what you need faster with improved search that handles large result sets." Focus on what users can now do or what's now better.
43
444. **Categorize Changes**
45 Group remaining changes into clear categories: New Features, Improvements, and Bug Fixes. Within each category, order by impact (most valuable first).
46
475. **Write Scannable Descriptions**
48 Each item should be 1-2 sentences. Lead with the benefit, optionally followed by the "how." Users scan release notes — make each line valuable.
49
506. **Acknowledge Known Issues**
51 If there are known limitations or issues, be transparent. Users appreciate honesty, and it reduces support burden.
52
537. **Tease Coming Soon (Optional)**
54 If appropriate, hint at what's coming next. This builds anticipation and shows momentum, but don't over-promise.
55
56## Output Format
57
58Use the template in `references/TEMPLATE.md` to structure the output.
59
60## Quality Checklist
61
62Before finalizing, verify:
63
64- [ ] Highlights feature the 1-3 most impactful changes
65- [ ] Each item leads with user benefit, not technical description
66- [ ] Language is jargon-free and accessible to all users
67- [ ] Items are concise (1-2 sentences each)
68- [ ] Bug fixes mention the problem that was solved
69- [ ] Tone is positive and professional
70
71## Examples
72
73See `references/EXAMPLE.md` for a completed example.
majiayu000