deliver-release-notes
The deliver-release-notes skill transforms technical product changes into user-focused release notes that highlight benefits and build excitement. Use this skill when shipping product updates to communicate value to customers, internal stakeholders, app stores, or support teams, ensuring changes are presented in scannable, benefit-driven language rather than technical changelog format.
git clone --depth 1 https://github.com/product-on-purpose/pm-skills /tmp/deliver-release-notes && cp -r /tmp/deliver-release-notes/skills/deliver-release-notes ~/.claude/skills/deliver-release-notesSKILL.md
<!-- 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.
Run an ad-hoc ordered chain of pm-skills with shared context (ephemeral; routes to the pm-workflow-orchestrator)
Defines a testable hypothesis with clear success metrics and a validation approach. Use when forming assumptions to test or aligning a team on what success looks like, before any experiment is designed. To design the A/B test or experiment that will validate the hypothesis, use measure-experiment-design.
Creates a Jobs to be Done canvas capturing the functional, emotional, and social dimensions of a customer job. Use when deeply understanding customer motivations, designing for jobs, or reframing product positioning.
Creates an opportunity solution tree connecting a desired outcome to customer opportunities and candidate solutions, preventing solution-first jumps in continuous discovery. Use when structuring scattered feature ideas or communicating how the roadmap traces to outcomes. For ranking an existing flat list of candidates, use define-prioritization-framework instead; this skill discovers the list, it does not score one.
Run applicable prioritization frameworks (RICE, ICE, MoSCoW, Weighted Scoring, Kano) against a list of features or initiatives. Produces a comparison table showing where rankings agree and diverge across frameworks, and an executive summary with recommendation. Framework applicability is filtered by data availability; Kano requires customer research. Refuses to fabricate scores; produces an estimation scaffold when input data is missing.
Creates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.
Generates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.
Documents edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.