Build a Release Notes Generator with Claude Code

Release notes are the most thankless PM task. Every sprint or release cycle, you open a pile of merged PRs, scan through Jira tickets, try to figure out what actually shipped, and then write two versions: one for customers, one for the team internally. The whole ritual burns 2-4 hours, and nobody ever thanks you for it.

I've taught over 100 people Claude Code at this point. PMs who automate release notes always have the same reaction: "Why was I doing this by hand?" The answer is that before Claude Code, the alternatives were bad. Now you can pull PR data, classify changes, generate both versions of the notes, and spend 10 minutes editing instead of 2 hours writing. Here's the exact workflow.

Pull the Raw Material from GitHub

Everything starts with the data. You need to know what merged since the last release. Claude Code runs shell commands natively, so you can pull PR data straight from GitHub without leaving your terminal.

Here are the commands Claude Code will run for you. You don't need to memorize them; just tell Claude what you need and it'll figure out the right invocation:

# List merged PRs since a specific date
gh pr list --state merged --search "merged:>=2026-02-15" \
  --json number,title,body,labels,author,mergedAt

# Or list merged PRs since the last release tag
git log v2.3.0..HEAD --oneline --merges

# Get detailed commit messages between two tags
git log v2.3.0..v2.4.0 --pretty=format:"%h %s" --no-merges

The gh CLI gives you structured JSON with PR titles, descriptions, labels, and authors. The git log approach works when you tag releases and want everything between two tags. Claude Code can run either approach, parse the output, and start classifying.

The Prompt That Generates Release Notes

Once Claude has the raw PR data, you need to tell it how to organize and write the notes. Here's the prompt I recommend:

Pull all merged PRs since the v2.3.0 tag using the gh CLI.
Classify each PR into one of these categories:
- New Feature
- Improvement
- Bug Fix
- Internal (don't include in customer-facing notes)

Generate two documents:

1. Customer-facing release notes (saved to output/release-notes-v2.4.md)
   - Tone: friendly, benefit-focused, non-technical
   - Lead each item with what the user can now do, not what we changed
   - Group by category (Features, Improvements, Fixes)
   - Skip anything labeled "internal" or "chore"

2. Internal changelog (saved to output/changelog-v2.4.md)
   - Tone: technical, precise, developer-focused
   - Include PR numbers and author names
   - Include internal/infrastructure changes
   - Note any breaking changes or migration steps

Claude reads the PR data, scans titles and descriptions for context, and generates both documents. The whole process takes about 90 seconds.

What Customer-Facing Release Notes Look Like

Here's a condensed sample of what Claude produces for the customer version:

# What's New in v2.4

## New Features

**Smart Filters on Dashboard**
You can now filter any dashboard by date range, user segment,
or custom properties. No more creating separate dashboards for
each view.

**CSV Export for Reports**
Export any report to CSV with one click. Filters and sorting
carry over to the export.

## Improvements

**Faster Page Load on Analytics**
The analytics page now loads 40% faster for accounts with
10,000+ events. Large accounts will notice the difference
immediately.

**Updated Onboarding Flow**
New accounts see a simplified 3-step setup instead of the
previous 7-step wizard.

## Bug Fixes

- Fixed an issue where email notifications sent duplicate
  messages for the same event
- Resolved a display bug on the billing page for annual plans
- Fixed CSV imports failing silently on files over 50MB

Notice the tone: benefit-first, plain language, focused on what the user can do now. Claude pulls this from PR descriptions and commit messages, then rewrites it for a non-technical audience.

What Internal Release Notes Look Like

The internal changelog is a different animal. Your engineering team and CS team need technical detail, PR references, and migration notes:

# Changelog v2.4.0

## Features
- Smart Filters: client-side filter state for dashboards (#412, @sarah)
  Adds composable filter primitives to DashboardContext.
  Breaking: DashboardProvider now requires a filterConfig prop.
- CSV Export: streaming export pipeline (#418, @james)
  Uses server-sent events for large exports. Max file size: 500MB.

## Improvements
- Analytics perf: replaced N+1 queries with batch loader (#421, @mike)
  P95 load time dropped from 3.2s to 1.9s for accounts >10K events.
- Onboarding: consolidated wizard steps (#415, @priya)
  Reduced from 7 steps to 3. Old onboarding routes redirect.

## Bug Fixes
- Email notifications: deduplicated event triggers (#420, @sarah)
- Billing page: fixed plan display for annual subscriptions (#417, @james)
- CSV import: added file size validation with user error (#419, @mike)

## Internal
- Upgraded Postgres driver to v8.2 (#422, @devops)
- Added structured logging to payment webhook handler (#423, @mike)
- CI: parallel test runner reduced build time by 35% (#416, @devops)

## Migration Notes
- DashboardProvider requires new filterConfig prop (see #412 for docs)
- Run migration script for email dedup: scripts/fix-email-dupes.sql

Same raw data, completely different output. PR numbers, author attribution, migration steps, breaking changes called out explicitly. This is what your engineering and CS teams actually need.

Customizing the Tone

Tone is where most auto-generated release notes fall apart. They sound robotic or generic. The fix is simple: give Claude a style reference in your prompt or in your CLAUDE.md file.

For customer-facing notes, I bolted these rules into a project-level CLAUDE.md:

## Release Notes Style
- Lead with the benefit, not the feature name
- Use "you" language: "You can now..." not "We added..."
- Keep each item to 2-3 sentences max
- No version numbers or PR references in customer notes
- Categorize as Features, Improvements, or Fixes
- Skip anything customers don't interact with directly

For internal notes, swap the rules:

## Internal Changelog Style
- Lead with the component or system affected
- Include PR number and author
- Note breaking changes in bold
- Include migration steps where relevant
- Technical language is fine; this is for engineers and CS

Once these rules live in your CLAUDE.md, every future release note generation follows the same voice. No more inconsistency between the notes you wrote when you were caffeinated versus the ones you cranked out at 4pm on a Friday.

The Full Workflow, Start to Finish

1. Tag the release in git (or note your cutoff date).
2. Open Claude Code in your project directory.
3. Run the prompt from above. Claude pulls PR data, classifies, and generates both documents in about 90 seconds.
4. Review the customer notes. Check tone, accuracy, and that nothing internal leaked through. This takes 5-10 minutes.
5. Review the internal changelog. Verify migration notes and breaking changes are accurate. Another 5 minutes.
6. Ship both. Paste customer notes into your changelog page. Send the internal version to Slack or Notion.

Total time: 15-20 minutes. Down from 2-4 hours of reading PRs, writing, reformatting, and switching tone between versions.

Pro Tips from My Students

Label your PRs consistently. If your team tags PRs with labels like feature, bugfix, internal, Claude's classification gets even more accurate. It can read labels from the gh CLI output and skip the guesswork.

Include context in PR descriptions. Claude pulls heavily from PR body text. A one-line PR description gives Claude nothing to work with. Two sentences about what changed and why makes the release notes dramatically better.

Iterate after the first draft. Tell Claude: "The smart filters section is too technical for customers. Rewrite it for a non-technical PM." Or: "Add a migration warning to the internal changelog for the dashboard changes." Each follow-up takes 30 seconds. This is the iterative workflow that makes Claude Code powerful.

When to Write Notes by Hand

Automation handles 90% of releases. But for major launches (your v3.0, a new product line, a pricing overhaul), you should write the customer-facing notes yourself. Those need narrative, positioning, and strategic framing that only the PM who lived through the project can provide. Use Claude to generate the first draft, then rewrite it in your own voice.

Get Started

If you're new to Claude Code, the step-by-step tutorial will get you running in 10 minutes. Already set up? Try the workflow above on your next release. You'll wonder why you ever read through PRs one by one.

Want hands-on training? ClaudeFluent is our premium program where I teach PMs, product marketers, and operators how to build real workflows with Claude Code. Release notes, launch briefs, competitive analysis, data pulls, and more. Join the next cohort and stop spending your afternoons on changelog busywork.