Release notes your customers can actually read

The changelog nobody reads

Release notes are one of the first things teams hand to a model, because the input already exists: the commits between two tags. Paste them in, ask for a summary, publish.

The result is usually a list of lines like "refactored the payment handler" and "bumped dependencies". Accurate, and useless to a customer. Commit messages are written for engineers, about the code. Customers want to know what changed for them.

Summarising is the wrong job

A model asked to summarise commits will faithfully summarise what the commits say. The problem is upstream: most commits describe changes a customer cannot observe, and the ones that matter are often described in terms of files and functions.

So the job is not summarising. It is three smaller jobs, in order.

Drop what customers cannot see. Chores, merges, reverts and dependency bumps can be filtered out by rule, with no model involved. Removing them first means the model never has a chance to dress them up as features.

Classify each remaining change by its effect. For every change, ask a narrow question with a structured answer: is this a new capability, a fix the customer would notice, a behaviour change they need to know about, or internal? Structured output makes the classification checkable, and "internal" is a valid answer that removes the line.

Write from the observable change. Only then generate text, grouped by what it means for the reader, and written about the behaviour rather than the code. The pull request description, when it exists, is usually a better source than the commit title.

Keep a human before publishing

Even a good pipeline will sometimes describe a change wrongly, and a release note is public. The last step should be an approval, not a post: someone reads the draft, corrects it, and releases it. That review is quick when the draft is already grouped and phrased for customers, which is the point of doing the first three steps well.

Putting it into practice

The AI Release Notes Workflow is this pipeline as an importable n8n workflow: it resolves the previous tag, fetches commits and merged pull requests, filters chores without a model, classifies each change with structured output, writes per section, and stops at an approval step. It ships with its two prompts, a setup guide, a worked example and the failures you are likely to hit first.

The same "review before anything is public" rule is applied to marketing content in one source error should not become six public posts.