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