Deliver Release Notes
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.
MCP get_skill({ skillId: "release-notes-6287c154" })Use this skill with your agent
Create a free account and connect via MCP
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 --> # 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 ## When NOT to Use - You are updating internal stakeholders on progress rather than announcing shipped changes -> use `foundation-stakeholder-update` - You need the technical record of changes for developers -> keep the engineering changelog; this skill translates changes into user benefits - You are coordinating launch readiness rather than communicating the ship -> use `deliver-launch-checklist` - Nothing user-visible shipped (a pure internal refactor): release notes that stretch to find a benefit erode trust; skip the cycle or fold it into the next one ## Instructions When asked to create release notes, follow these steps: 1. **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. 2. **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. 3. **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. 4. **Categorize Changes** Group remaining changes into clear categories: New Features, Improvements, and Bug Fixes. Within each category, order by impact (most valuable first). 5. **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. 6. **Acknowledge Known Issues** If there are known limitations or issues, be transparent. Users appreciate honesty, and it reduces support burden. 7. **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. Complete release notes fill the template sections: Highlights; New Features; Improvements; Bug Fixes; Known Issues; Coming Soon (optional); and Feedback. ## Quality Checklist Before finalizing, verify: - [ ] Highlights feature the 1-3 most impactful changes - [ ] Each item leads with user benefit, not technical description - [ ] Language is jargon-free and accessible to all users - [ ] Items are concise (1-2 sentences each) - [ ] Bug fixes mention the problem that was solved - [ ] No internal jargon, ticket IDs, or code names leak through; every line reads as customer-facing ## Examples See `references/EXAMPLE.md` for a completed example.
Related Skills
More skills in Business, Marketing & Sales
Ab Testing
When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program," or "experiment playbook." Use this whenever someone is comparing two approaches and wants to measure which performs better, or when they want to build a systematic experimentation practice. For tracking implementation, see analytics. For page-level conversion optimization, see cro.
Ab Test Setup
When the user wants to plan, design, or implement an A/B test or experiment. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "conversion experiment," "statistical significance," or "test this." For tracking implementation, see analytics-tracking.
Ab Test Setup
Ab Test Setup linked from Corey Haines marketing skills, with the upstream skill instructions available on GitHub.
Ab Test Store Listing
When the user wants to A/B test App Store product page elements to improve conversion rate. Also use when the user mentions "A/B test", "product page optimization", "test my screenshots", "test my icon", "conversion rate optimization", "CPP", or "custom product pages". For screenshot design, see screenshot-optimization. For metadata optimization, see metadata-optimization.
Account Research
Research a company or person and get actionable sales intel. Works standalone with web search, supercharged when you connect enrichment tools or your CRM. Trigger with "research [company]", "look up [person]", "intel on [prospect]", "who is [name] at [company]", or "tell me about [company]".
Account Research
Research a company using Common Room data. Triggers on 'research [company]', 'tell me about [domain]', 'pull up signals for [account]', 'what's going on with [company]', or any account-level question.
Explore Other Categories
Skills from other categories with shared topics
Deliver User Stories
Generates user stories in the standard persona, action, benefit story format from product requirements or feature descriptions. Use when breaking a feature into stories for sprint planning, writing tickets, or communicating scope to engineering. For testable Given/When/Then acceptance criteria on a story, use deliver-acceptance-criteria; for boundary and failure scenarios, use deliver-edge-cases.
Develop Adr
Creates an Architecture Decision Record following the Nygard format to document significant technical decisions, their context, and consequences. Use when making technical choices that affect system architecture, technology selection, or development patterns.
Develop Design Rationale
Documents the reasoning behind design decisions including alternatives considered, trade-offs evaluated, and principles applied. Use when making significant UX decisions, aligning with stakeholders on design direction, or preserving design context for future reference.