How to Automate Release Notes From GitHub

How do you automate release notes from GitHub?

You automate release notes from GitHub by treating your commits, pull requests, and tags as structured data, then running a tool that collects everything merged since the last tag and turns it into grouped, readable notes. The cleaner your commit and PR conventions, the better the automated output, because the tool has clear signals to categorize and summarize.

There are three common levels of automation: GitHub's built-in auto-generated release notes, convention-driven generators that parse Conventional Commits, and AI tools that rewrite raw history into benefit-first prose. This guide covers all three so you can pick the right level for your team.

Prerequisite: make your history machine-readable

Automation is only as good as its input. Before you wire up any tool, give it clean signals to work from. The two most useful conventions are structured commit messages and labeled pull requests.

• •Adopt Conventional Commits (feat:, fix:, docs:, chore:, etc.) so changes self-classify.
• •Label pull requests by type (feature, bug, breaking) so PR-based tools can group them.
• •Write PR titles as if they were the changelog line, because often they become one.
• •Tag releases with semantic version numbers like v2.4.0 so tools know the range to summarize.

Option 1: GitHub's built-in release notes

GitHub can auto-generate release notes when you create a release. It lists merged pull requests since the previous tag and groups them using a configurable .github/release.yml file based on PR labels. This is free, zero-infrastructure, and good enough for developer-facing repositories.

The limitation is that the output is a list of raw PR titles and contributors. It records what merged, but it does not rewrite anything into user-friendly, benefit-first language, and it lives only on the GitHub releases page.

1. 1

   Add a release.yml config

   Create .github/release.yml and define categories mapped to your PR labels, for example 'Features' to the 'feature' label and 'Bug Fixes' to the 'bug' label.

2. 2

   Label your pull requests

   Apply the matching labels as you merge so each PR lands in the right category automatically.

3. 3

   Create a release and auto-generate

   When tagging a release on GitHub, click 'Generate release notes' to produce the grouped list from merged PRs.

Option 2: convention-driven generators

Tools that parse Conventional Commits, such as release-please or semantic-release style workflows, read your commit history and build a changelog automatically. A 'feat:' commit becomes a feature entry, a 'fix:' commit becomes a bug fix, and a commit marked with a breaking change footer bumps the major version and lands in a Breaking Changes section.

These tools shine when your team is disciplined about commit format. They can also automate the version bump and the Git tag itself, closing the loop from commit to released changelog with no manual editing.

Option 3: AI-generated, reader-friendly notes

The gap in the first two options is voice. They record what changed, but they do not translate 'fix(api): handle null cursor' into 'Fixed an error when paging through large lists.' AI-based tools close that gap by reading the raw commits and PRs and rewriting them into grouped, benefit-first notes for end users.

This is the approach release-notes.dev takes: connect a GitHub repository, and it turns the commits, pull requests, and tags between releases into clean, grouped release notes using AI, then publishes them to a hosted changelog page with a custom domain, themes, and an RSS feed. You keep the speed of automation but get notes that read like a human wrote them.

• •Connect the repo once, then generate notes per tag or on a schedule.
• •AI groups changes and rewrites them benefit-first, while you stay in control of the final edit.
• •Publish to a hosted, SEO-friendly page, export Markdown, or push via webhooks and API.

Which option should you choose?

If your audience is only other developers and you live in GitHub, the built-in generator is the fastest start. If you want a versioned changelog file and automated version bumps, a convention-driven generator fits naturally into CI. If your audience includes non-technical users and you want a polished, hosted, branded changelog, an AI tool that rewrites the history will save the most time.

Many teams combine them: a convention-driven tool maintains the canonical CHANGELOG.md in the repo, while an AI tool produces the customer-facing hosted page from the same history.