GitHub's auto-generated release notes pull PR titles into a list. That is fine for developers reading a changelog. It is useless for customers, stakeholders, or anyone who wants to know what changed in plain language.
This guide shows you how to use the Release Notes Generator alongside GitHub Releases to produce changelogs that actually communicate value.
The Problem with Auto-Generated Notes
GitHub can generate release notes from merged PRs between two tags. The output looks like this:
- fix: resolve null pointer in user service (#482)
- feat: add batch export endpoint (#471)
- chore: bump dependencies (#479)
Engineers understand this. Product managers, customer success teams, and users do not. You need a translation layer between git history and human-readable release notes.
The Release Notes Workflow
Step 1: Tag your release in GitHub. Follow your existing Git flow. Whether you use semantic versioning, date-based tags, or release branches, the process stays the same.
Step 2: Collect the changes. Pull the list of merged PRs from GitHub. You can use GitHub's "Generate release notes" button as a starting point. Copy the raw list.
Step 3: Generate polished notes. Paste the PR list into the Release Notes Generator. The tool groups changes by category (features, fixes, improvements), rewrites technical titles into user-facing language, and highlights the most impactful changes.
Step 4: Publish to GitHub Releases. Paste the polished notes back into your GitHub Release. You now have both the raw PR list (for engineers) and the polished summary (for everyone else).
Structuring Notes for Different Audiences
Good release notes serve multiple audiences from a single document. Structure them in layers.
Headline: One sentence describing the most important change. "Users can now export reports in bulk, cutting report generation time by 80%."
What's New: 3-5 bullet points covering user-facing features. Write these from the user's perspective, not the engineer's.
Improvements: Bug fixes and performance changes that users will notice. Skip internal refactors.
Technical Details: Link to the full PR list or a detailed changelog for developers who want specifics.
Connecting Releases to Product Documents
Your PRD defines what success looks like before building. Your release notes confirm what shipped. Link the two together.
In each GitHub Release, add a "Related PRDs" section that links back to the requirements document. This creates a paper trail from "why we built it" to "what we shipped."
For teams tracking sprint output, connect your release cadence to your sprint velocity data. If velocity is stable but releases are slowing down, you have a shipping bottleneck, not a building bottleneck.
Automating the Process with GitHub Actions
Create a GitHub Action that triggers on new releases. The action can pull merged PRs, format them into a template, and open a draft release with pre-filled notes. Your PM reviews and polishes the draft rather than starting from scratch.
Teams that prioritize features with RICE can include the original RICE score in release notes to show stakeholders that high-impact items shipped first.