Release notes

Skill janellecipriano/pm-skills/skills/release-notes

Open-source Claude skills for Program Management in product development — charters, status reports, RAID logs, roadmaps, launch readiness, retros, postmortems, OKRs & more.

Install

npx -y skills add janellecipriano/pm-skills --skill release-notes

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Write audience-appropriate release notes from a changelog, list of merged PRs, or feature list — grouped by type, in user-benefit language. Use when the user says "write release notes", "changelog", "what's new", "announce this release", or wants to turn a list of changes into customer- or internal-facing notes.

SKILL.md

2.0 KB, as published. Nobody here has run it

Release Notes

Turn a list of changes into release notes written for the reader — what they can now do, not what you merged.

When to use

Announcing a release (customer-facing or internal).
Converting a changelog / PR list into readable notes.

Inputs to gather

Source of truth: changelog, merged PRs, ticket list, or feature summary.
Audience — end users, customers/admins, or internal team (this drives tone and detail).
Version/date and any highlights to feature.

Process

Group changes into: ✨ New / 🔧 Improved / 🐛 Fixed, plus ⚠️ Breaking changes and 🗑️ Deprecated when relevant.
Rewrite each in benefit language — lead with what the user can now do; drop internal jargon, ticket IDs (or move to an appendix), and implementation detail.
Lead with highlights — the 1–3 changes most people care about, optionally with a short intro.
Match tone to audience: warm and benefit-led for customers; precise and complete for internal/technical.
Call out breaking changes prominently with required actions and migration steps.
Be honest and complete on fixes that affected users; don't bury security/data fixes.

Output format

# {{Product}} {{version}} — {{date}}

{{1–2 sentence highlight intro, optional}}

## ✨ New
- **{{Feature}}** — {{what you can now do}}.

## 🔧 Improvements
- {{benefit}}

## 🐛 Fixes
- {{what's fixed, from the user's view}}

## ⚠️ Breaking changes
- **{{change}}** — {{required action / migration}}.

Omit empty sections. Keep entries short and skimmable.