How do I install the Deliver Release Notes skill?

Run npx skillmds add product-on-purpose/deliver-release-notes in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Deliver Release Notes safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: makes network calls. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Deliver Release Notes?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Deliver Release Notes free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under Apache-2.

Who published Deliver Release Notes?

product-on-purpose (@product-on-purpose) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Deliver Release Notes by product-on-purpose

Name: Deliver Release Notes
Rating: 4.5 (4 reviews)
Author: product-on-purpose

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.

product-on-purpose 8b6e296 7 files · 18.7 KB Updated Sep 9, 2026

File contents

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:

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. 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.

---name: deliver-release-notesdescription: 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.license: 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.

Frequently asked questions