Part 1: Why Automate Release Notes

Release notes are the most consistently neglected documentation in software engineering. Every team knows they matter. Every team deprioritizes them. The pattern is universal: a release ships, the engineers move immediately to the next sprint, and the release notes get written by whoever draws the short straw, usually from memory, usually incomplete, usually days after the release.

The result is release notes that are either missing entirely, technically accurate but incomprehensible to non-engineers, or so delayed they are irrelevant by the time they are published.

This matters more than most engineering teams realize. Release notes are read by customers, customer success teams, sales engineers, support staff, and enterprise procurement teams evaluating whether to renew. They are a trust signal. Consistent, clear, timely release notes signal a professional engineering operation. Absent or poor release notes signal the opposite.

The documented cost of poor release notes:

A Salesforce study of enterprise software buyers found that 67% consult release notes before approving major upgrades. A PagerDuty internal analysis found that support ticket volume increases 23% in the two weeks following a release when release notes are absent or incomplete, customers encountering changes they were not warned about contact support to understand what happened.

The second number is the one engineering leaders should care about. Poor release notes create support load. Support load consumes customer success capacity. Customer success capacity reduction increases churn risk.

What AI-generated release notes actually look like:

The automation pulls every merged pull request from the release period, reads the PR title, description, and diff summary, and generates a structured release note in your chosen format. The output is organized by category: new features, improvements, bug fixes, deprecations, and breaking changes. Each item is written for the appropriate audience, technical enough to be accurate, plain enough to be readable by a non-engineer.

The generation happens within 60 seconds of the release tag being pushed. By the time the engineer who pushed the tag has closed their laptop, the release notes are drafted, formatted, and posted to Slack for review.

Why AI does this better than humans:

First, completeness. Humans writing release notes from memory omit things. AI reading the full set of merged PRs omits nothing that was described in a PR.

Second, consistency. Every release follows the same format. The release from six months ago looks like the release from today. Customers know what to expect.

Third, speed. AI-generated release notes are available within minutes of the release. Human-written release notes are available when someone gets around to it.

Fourth, appropriate audience calibration. A single PR might generate two release note entries: a technical entry for the developer changelog and a plain-English entry for the customer-facing release notes. AI handles both simultaneously from the same source.

Part 2: How to Build the Release Notes Automation

This pipeline triggers on a GitHub release tag, pulls all merged PRs since the previous release, generates structured release notes using Claude, and posts the draft to Slack for engineering review before publishing.

The pipeline:

GitHub release tag pushed
→ Workflow triggered
→ Pull all merged PRs since previous release tag
→ For each PR: extract title, description, labels, and diff summary
→ Categorize PRs by type (feature, fix, improvement, deprecation, breaking)
→ Send categorized PR data to Claude
→ Claude generates: customer-facing release notes + technical changelog
→ Post draft to #releases Slack channel for review
→ On approval: publish to changelog page and email list
→ Archive in release notes Google Sheet

The GitHub Actions workflow:

Create `.github/workflows/release-notes.yml` triggered on release publication. The workflow uses the GitHub API to fetch all merged PRs between the current and previous release tags, then calls the Claude API to generate the release notes.

The workflow runs automatically every time a new release is published. No manual trigger required.

The PR categorization system:

The automation uses PR labels to categorize changes. Before deploying the automation, establish a consistent labeling system in your repository:

If your team does not consistently apply labels, the automation can infer category from PR title keywords. The prompt includes a classification step that reads the PR title and description and assigns a category if no label is present.

The Claude prompt structure:

The prompt provides Claude with the categorized PR list and instructs it to generate two outputs:

Customer-facing release notes: Written for technical users who are not the engineers who built the feature. Plain English. Benefits-focused. "You can now [do thing]" rather than "Implemented [technical approach] to enable [thing]." Maximum 2 sentences per item.

Technical changelog: Written for engineers and integration partners. Precise. Includes API changes, parameter changes, deprecation timelines, and migration instructions where relevant. Can be longer and more technical.

The prompt also includes your product name, the release version number, and any context about the release theme if provided (the workflow can accept a release description as input).

The Slack review workflow:

The draft is posted to your `#releases` Slack channel with three reaction options:

✅ Approve and publish

✏️ Edit before publishing

🔄 Regenerate with different instructions

If approved, the workflow automatically publishes to your changelog. If edit is selected, the draft is posted to a shared document for editing. If regenerate is selected, a thread is opened for instructions and the workflow regenerates.

The review step adds approximately 10 minutes to the release process. Without it, the release notes publish immediately, appropriate for teams with high confidence in the automation output.

The changelog page:

The automation maintains a running changelog page. Each release adds a new entry at the top. The page is generated as a static HTML file deployed to your docs site, or posted to a Notion page, Confluence page, or your existing documentation platform.

Format: release version number, release date, brief release summary, categorized changes, and a link to the full technical changelog.

Publishing to your email list:

For teams with a developer newsletter or customer email list, the automation can trigger an email campaign through your email platform of choice. The customer-facing release notes become the email body. Subject line: "[Product] [Version], [Number] improvements including [most significant feature]."

Part 3: Get the Automation

The WorkplaceAI Release Notes Automation generates customer-facing release notes and a technical changelog from your merged PRs within 60 seconds of every GitHub release tag.

What's included:

Template workflow requires configuration. Technical familiarity with GitHub Actions assumed. Setup guide included. Questions: support@workplaceai.ai

Read the full implementation guide: workplaceai.ai

No pre-built automation for this guide yet.

We build custom automations for exactly this kind of workflow.

Request Custom Automation →

Before choosing your tools, read the independent comparison at Unvarnished Reviews: GitHub Copilot vs. Cursor vs. Windsurf →