Auto Generate Release Notes from Pull Requests (2026 Guide)

If you have ever tried to generate release notes from individual commits, you know the result is messy. Commits like "fix typo," "address review feedback," and "WIP" tell you nothing about what actually shipped. Pull requests solve this problem because they represent complete units of work with titles, descriptions, linked issues, and reviewer context.

PRs are the natural building block for release notes. Each PR typically maps to one feature, one fix, or one improvement. The title summarizes the change, the description explains why it was made, and the labels categorize it. That is exactly the structure you need for a changelog.

This guide covers how to auto-generate release notes from pull requests using four different approaches, from AI-powered platforms to lightweight GitHub Actions.

#Why Pull Requests Beat Commits for Release Notes

A single feature might involve fifteen commits: initial implementation, lint fixes, test additions, review responses, and a final cleanup. Listing all fifteen in a changelog is noise. The pull request wraps all of that into one entry with meaningful context.

Here is what PRs give you that commits do not:

• A human-written title that summarizes the change in plain language
• A description explaining the motivation, approach, and any trade-offs
• Labels that categorize the change (feature, bug fix, breaking change)
• Linked issues connecting the change to user-reported problems or feature requests
• Review history showing that the change was vetted by teammates
• A single merge point making it easy to trace what went into each release

When you generate release notes from PRs instead of commits, you start with better raw material. The tools below make that generation automatic.

#PR-Based Release Notes Tools Compared

#Tool Breakdown

#1. ShipTell: AI That Reads Your PRs and Writes Release Notes

ShipTell connects to your repositories through a GitHub App and reads the full context of your pull requests: titles, descriptions, labels, linked issues, and commit messages. The AI does not just list PR titles. It analyzes intent, groups related PRs together, and rewrites everything into clear, user-friendly language.

For example, if you merged three PRs about improving your onboarding flow, ShipTell might combine them into a single entry: "Redesigned the onboarding experience with a guided setup wizard, progress indicators, and contextual help tooltips." That reads better than three separate PR titles dumped into a list.

The key advantage over label-based tools is that ShipTell does not require labeling discipline. It reads PR descriptions and commit messages to understand what changed, even if you never added a single label. This is a meaningful difference for small teams and solo developers who do not have time for process overhead.

Once generated, your release notes are available on a public changelog page. You can also embed them in your product using a sidebar drawer, embeddable widget, or modal popup, so users see updates without leaving your app.

Setup: Sign up at shiptell.com, install the GitHub App on your repos, and generate your first changelog. About three minutes total.

Pricing: Free tier includes 5 changelogs per month. Pro is $19/month or $190/year.

Limitation: GitHub-only. Teams using GitLab, Bitbucket, or Azure DevOps will need to wait for future support.

#2. Release Drafter: Automatic Draft Releases from Labeled PRs

Release Drafter is a GitHub Action that watches for merged pull requests and adds them to a draft release on GitHub. It sorts PRs into categories based on their labels, so a PR labeled feature appears under "New Features" and one labeled bugfix appears under "Bug Fixes."

How it handles PRs:

Every time a PR is merged into your main branch, Release Drafter:

1. Checks the PR's labels against your configuration
2. Adds the PR title to the appropriate category in the draft release
3. Updates the version number based on label-based version resolution

Configuration for PR-based notes (.github/release-drafter.yml):

 1name-template: 'v$RESOLVED_VERSION'
 2tag-template: 'v$RESOLVED_VERSION'
 3categories:
 4  - title: 'New Features'
 5    labels: ['feature', 'enhancement']
 6  - title: 'Bug Fixes'
 7    labels: ['fix', 'bugfix']
 8  - title: 'Performance'
 9    labels: ['performance']
10  - title: 'Breaking Changes'
11    labels: ['breaking']
12change-template: '- $TITLE (#$NUMBER) @$AUTHOR'
13version-resolver:
14  major:
15    labels: ['breaking']
16  minor:
17    labels: ['feature', 'enhancement']
18  patch:
19    labels: ['fix', 'bugfix', 'performance']

Workflow file:

 1name: Release Drafter
 2on:
 3  push:
 4    branches: [main]
 5  pull_request:
 6    types: [opened, reopened, synchronize]
 7permissions:
 8  contents: read
 9  pull-requests: write
10jobs:
11  update_release_draft:
12    runs-on: ubuntu-latest
13    steps:
14      - uses: release-drafter/release-drafter@v6
15        env:
16          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Best for: Teams with established PR labeling habits who want hands-off release draft management.

Downside: PRs without labels land in an "uncategorized" bucket. The output is raw PR titles with no rewriting, so "Fix the thing that broke when users click fast" is exactly what appears in your release notes.

#3. GitHub Built-in Auto-Generated Release Notes

GitHub ships a native feature for generating release notes from PRs. When you create a new release, you click "Generate release notes" and GitHub pulls in all PRs merged since the last tag.

Optional configuration (.github/release.yml):

 1changelog:
 2  exclude:
 3    labels:
 4      - ignore-for-release
 5    authors:
 6      - dependabot
 7  categories:
 8    - title: New Features
 9      labels: ['enhancement', 'feature']
10    - title: Bug Fixes
11      labels: ['bug', 'fix']
12    - title: Documentation
13      labels: ['documentation']
14    - title: Other Changes
15      labels: ['*']

Without this file, GitHub lists all PRs in a flat list. With it, PRs are grouped by category based on labels.

How to use it:

1. Go to your repository on GitHub
2. Click "Releases" in the sidebar
3. Click "Draft a new release"
4. Select your tag
5. Click "Generate release notes"
6. Review, edit, and publish

Best for: Teams that want something immediate with zero tooling. If you already create GitHub Releases manually, this adds structure with minimal effort.

Downside: No AI processing. No distribution beyond GitHub. The output is functional but not polished enough for customer-facing changelogs.

#4. Manual Approach: Curating PRs by Hand

Some teams prefer to manually review merged PRs and write release notes from scratch. This gives you maximum control over tone and content but scales poorly.

A practical manual workflow:

 1# List PRs merged since the last tag
 2gh pr list --state merged --base main --search "merged:>=2026-02-15" --json title,number,labels --template '{{range .}}#{{.number}} {{.title}} [{{range .labels}}{{.name}}, {{end}}]{{"\n"}}{{end}}'

This gives you a list of merged PRs with their titles, numbers, and labels. You then write release notes manually based on this list.

Best for: Teams with very few releases who want complete editorial control.

Downside: Does not scale. Gets skipped when deadlines are tight. Inconsistent quality across different authors.

#Step-by-Step: PR-Based Release Notes with ShipTell

1. Go to shiptell.com and create an account
2. Install the ShipTell GitHub App and grant access to the repositories you want to track
3. Select a repository from your dashboard
4. Click Generate — ShipTell reads all recent PRs, including titles, descriptions, labels, and linked issues
5. Review the AI draft — Changes are grouped by intent (features, fixes, improvements) with user-friendly language
6. Edit any entries you want to adjust, then publish
7. Share or embed — Use the public changelog URL, or add the sidebar drawer, widget, or modal popup to your app

#Best Practices for PR-Based Release Notes

Regardless of which tool you choose, these habits improve output quality:

Write descriptive PR titles. "Add dark mode" is better than "UI changes." Your PR title becomes the release note entry in most tools.

Use PR descriptions. Explain the "why" not just the "what." AI tools like ShipTell use descriptions to generate richer release notes. Label-based tools ignore descriptions, but your future self will thank you during manual reviews.

Label consistently. If you use Release Drafter or GitHub auto-generate, labels are your categorization mechanism. Establish a minimal set (feature, fix, breaking) and use them on every PR.

Exclude noise. Configure your tool to skip PRs from bots (like Dependabot) or PRs labeled internal or chore that users do not care about.

#Decision Framework

Choose ShipTell if you want release notes that sound human-written, do not want to enforce labeling discipline, and need distribution beyond GitHub (public page, widget, embedded popup).

Choose Release Drafter if your team already labels PRs and you want a continuously updated draft release inside GitHub.

Choose GitHub auto-generate if you want the simplest possible approach with zero tools to install.

Choose the manual approach if you release infrequently and want total control over every word.

#Start Generating Release Notes from Your PRs

Your pull requests already contain everything needed for great release notes. The question is whether you extract that information manually or let a tool do it for you.

If you want AI that reads your PRs, understands intent, and writes release notes your users will actually read, try ShipTell free. Five changelogs per month, no credit card required.