GitHub’s own generator produces a list of merged pull request titles for a tag. A conventional-commit tool like release-please sorts those into categories. A language model reads the pull requests and writes prose a customer can understand. The third is the only one that gets you something close to publishable, and it’s already sitting in your terminal.

So the useful question isn’t how to generate release notes. It’s what to do about everything generation leaves behind.

You can already do this in your terminal

Open the agent you use for everything else and ask it to read the merged pull requests since last Tuesday and write release notes. It will. The output will be decent.

Pretending otherwise would be silly, so start there. Generation is free now. What you get back is a block of text on your screen, produced by a prompt you have to remember to write every time.

Everything difficult about release notes survives that prompt intact.

What the terminal version does not know

Where the last one stopped. The unglamorous one, and probably the first to break. You ask for last week’s changes, and it gives you last week’s changes. But your previous update went out three weeks ago and only covered work merged up to that point. The fortnight in between is now unannounced, and nothing in the prompt knows that. Either you repeat yourself or quietly drop two weeks, and the only thing standing between you and both is a date you’re holding in your head.

Which changes count. It will happily write you a paragraph about a dependency bump if the pull request was verbose enough, and agent-written pull requests are always verbose enough.

Who is reading. Without that context, every draft is written for a generic software buyer, and every product’s update starts to sound the same.

Where it goes next. Text in a terminal isn’t an update. Somebody still has to put it on a page, in the product, and in front of people who aren’t looking for it.

The input stopped being the problem

All the advice from a few years ago said the same thing: write better pull request descriptions and the generated notes improve.

That advice is finished.

Agents write the descriptions now, and they write more than any human bothered to. What changed, what it touched, why, the edge cases, often a test plan. The raw material is richer than it has ever been.

What didn’t change is who it’s written for. All of that detail exists to help a reviewer approve a merge. None of it exists to help a customer decide whether they care.

A description can be thorough, accurate, four paragraphs long, and contain no sentence you could publish.

So the bottleneck moved. It used to be thin input. Now it’s volume. Forty well-documented pull requests are harder to sort than forty terse ones, because every one of them looks substantial.

Not every change is an update

Two filters, and most people only think about one.

The first is mechanical. Anything matching chore, ci, bump, deps, refactor, typo, wip, or merge is not an update. Deciding that takes no judgment. It’s a pattern list, so it should run before anything reads the changes properly, and it removes most of the pile on its own.

The second is editorial and can’t be patterned.

Would this change what a user does tomorrow?

If the answer is no, it stays in the repo. Leaving it there costs you nothing.

Six of forty going out is the system working. It isn’t a sign the week was thin.

The audience is the part everyone skips

A model that doesn’t know who your users are writes for a generic software buyer, which is nobody.

The same merged pull request isn’t the same update twice. A latency fix is real news for a developer tool and invisible to a scheduling app whose users never noticed the old latency. Write both the same way and one of them is wrong.

Your audience is already written down on your own homepage. Your positioning, who you say you sell to, the words you use for your own features. That context and your release notes are about the same product, but almost nobody connects them.

Generic output is the result, and it reads generic no matter how good the model is.

What still needs you

A generated draft is roughly eighty percent right. The remaining twenty percent is the expensive part: the thing you merged but are holding back for a launch, the security fix you don’t want described in public, the change to your own admin tooling that has no business in a customer update.

You also decide what leads.

The model can tell you the export pipeline changed. It can’t know that three of your largest accounts have been complaining about exports for a month, and that this is the entry that goes at the top.

Eighty percent is an enormous amount of work removed. It is not a hundred, and treating it as a hundred is how a product announces something that doesn’t exist.

A setup that works at one to five people

1. Track where the last published update stopped, so the window picks up exactly there.
2. Cut the internal changes by pattern before anything reads them properly.
3. Generate a draft from what survives, with your audience as context.
4. Read it. Reorder so the thing that matters most is first. Cut what shouldn’t be public.
5. Publish to a page users can reach, then send it where your users already are.

Step 4 is the only one that needs you, and it is the only one that should.

The gap between ten minutes and an hour isn’t about efficiency. It decides whether this happens at all.

A ten-minute task survives a bad week, a launch, a sick day. An hour-long one gets pushed to Friday, then to next week. After a few rounds of that, you’re not postponing a task anymore. You’re avoiding a backlog.

That’s how the six-week silence starts. Not with a decision. Just an hour you never had.

ReleasesHQ does this end to end. It remembers where your last update stopped, strips the chore and refactor noise before anything reads the changes, and drafts the rest in plain language using your own site to work out who your users are and what they call things. You get the six that matter, not the forty, on your page and in your channels in one action. Review is on by default, and automatic publishing is a setting you turn on deliberately.

The obvious move is to build one. A route, a table, some markdown, a bit of styling. Two hours, maybe three. It’s genuinely not hard, which is kind of the problem. Because it’s not hard, it never gets prioritized. Six months later, the link in your footer still goes nowhere.

There are a few ways around this. They all have tradeoffs.

Option 1: a markdown file in your repo

Create CHANGELOG.md, write entries newest first, commit it.

Cost: zero. You already have the repo.

Where it breaks: it’s for developers. The people reading a file in your repository are usually developers, and your users probably aren’t. It also doesn’t live on your marketing site, and the format naturally pushes you toward commit-level detail because that’s what a changelog file looks like.

You end up with a list of changes instead of a list of things a user would care about.

Keep it if you’re building a library. If you’re building software with a login screen, I’d look elsewhere.

Option 2: a blog category

Tag posts as “updates” and point your footer at the tag page.

Cost: near zero if you already have a blog.

Where it breaks: blog posts feel like work. A blog post feels like it needs an intro, some structure, and a point. A release note might need two sentences.

Once the two get mixed together, every update starts feeling like a writing assignment. And writing assignments get skipped.

There’s another problem too. Your actual blog posts now sit next to things like “fixed a bug in exports.” Neither one gets the attention it deserves.

This can work if you ship rarely. For a product that’s shipping every week, I’d keep the two separate.

Option 3: a hosted doc

Make a public page in a document tool, update it as you go, and link to it.

Cost: ten minutes.

Where it breaks: it doesn’t really feel like part of your product. It’s someone else’s domain, someone else’s design, and someone else’s branding. That’s probably fine for an internal document. It feels a little strange as the page you’re sending a prospect to.

It’s also easy to forget about. Anything that lives outside your normal working path tends to disappear from the routine.

Still, if you need something today, this is perfectly reasonable.

Option 4: build the page yourself

Add a route to your site. Store the entries in a database or markdown. Render them using your existing design system.

Cost: a few hours to build. Then ongoing.

Where it breaks: mostly after you’ve finished building it.

Someone has to add an editor, or you keep writing raw markdown. Someone has to deal with RSS when a user asks for it. Someone eventually has to fix the parser because a code block broke the page.

None of these things are particularly difficult. They’re just things you now have to maintain.

Build it yourself if the changelog is important enough to be part of your product experience. Otherwise, you’re probably spending time building infrastructure for something that isn’t your product.

Option 5: a hosted page plus an embed

Write the update once. It gets published to a hosted page, and the same content can appear inside your site through an embed.

Cost: minutes to set up.

Where it breaks: you depend on another service, and you may end up with a subdomain unless you configure your own.

Those are real tradeoffs. But for a small team, they’re usually less important than whether you’ll actually keep publishing.

The bigger advantage is that the same update can live in multiple places without being written multiple times.

Which one should you pick?

I’d start with one question: is the page the destination, or is it the source?

If it’s just a destination (a URL you send someone when they ask what’s new), pick whatever you’ll actually maintain. A simple page that’s updated every week is more useful than a beautiful one that’s been untouched for six months.

If the changelog is also supposed to reach existing users, things change. Now you need the same update to show up in more than one place. That’s where a hosted page plus an embed starts making more sense.

The embed is the part people underrate

A changelog page gets read by people who go looking for it. That’s mostly prospects doing some research or existing users who already know the page exists.

Most users aren’t going to visit your changelog on their own. They’re inside your product trying to get something done. If you want them to see what’s new, the update needs to reach them there.

So think of the two as separate jobs: the page is the record, and the embed is the delivery. You want both if communication with existing users is part of the goal.

Three things to get right on day one

Whatever you choose, there are a few things that are annoying to change later.

Pick a stable URL. /changelog is simple, memorable, and easy to share. Don’t put it behind a login or bury it three levels deep.

Link to it from the right places. Put it in the footer for prospects. Put it somewhere inside the product for users.

Set a minimum, not a maximum. Decide what the smallest acceptable update looks like. Two sentences and a date is enough.

The goal isn’t to create the world’s best changelog. It’s to still have one six months from now.

ReleasesHQ gives you the hosted page and the embed from one publish, plus drafts generated from your merged pull requests. The script tag is one line and mounts itself.

For most teams shipping right now, those two timelines are not close. The repo is full of things that shipped. The user-facing side is probably one post from six weeks ago about a feature that has already changed twice.

That gap is not new. What is new is how quickly it is widening, because writing code is getting faster.

The merge rate went up and nothing else did

Small teams can ship a lot more code today than they could a year or two ago. A solo founder with an agent working in one window and a review queue in another can get through a pretty ridiculous amount of work.

But everything after the merge is still basically the same.

Writing the update is still manual. Figuring out what actually matters to a user is still a judgment call. Posting it in four places is still four separate things to remember.

The product gets faster. The communication around it doesn’t.

The result is a product that improves every week but still feels static from the outside.

A fast product with no signal looks abandoned

A product that ships slowly but communicates consistently feels like it’s moving. You see updates, you see what the team is working on, and you assume there’s more coming.

A product that ships constantly but says nothing feels very different.

You visit the website, see the same thing you saw last time, and start wondering if anyone is still working on it.

You end up paying for the same feature twice. Once when you build it, and again when someone emails six months later asking if the product can do something you shipped months ago.

Sometimes churn works the same way. People don’t necessarily leave because the product is bad. Sometimes it just stops feeling alive.

The problem is not writing, it is deciding

Most people can explain what they built in a couple of sentences.

The annoying part is figuring out which things are actually worth mentioning.

You might have forty PRs from the last month. Maybe six of them matter to a user. The rest are dependency updates, refactors, tests, migrations, and fixes that make the product better without meaning much to the person using it.

Someone has to sort through all of that.

And that’s exactly the kind of task that gets pushed to next week.

Then next week becomes next month.

Suddenly you’re looking at six weeks of changes and thinking, “Okay, I guess I need to figure out what happened.”

Nobody wants to do that.

This is why release notes pages die. Not because teams don’t care. Because starting again after a long silence is much harder than writing the update when you actually ship.

What actually closes the gap

Three things.

Shorten the loop to one release. Write the update close to the merge, not at the end of the month. One change is easy to understand. Twenty changes from the last six weeks are not.

Let the machine do the sorting, not the deciding. Going through forty pull requests and figuring out which ones might matter to users is exactly the kind of work software can help with.

But deciding whether something is actually worth telling users? I’d keep that part human.

Otherwise you end up with a changelog that’s basically a Git log wearing nicer clothes.

Publish before it is polished. An update that explains what changed and why it matters, posted the day it shipped, is more useful than a beautifully written one that never gets published.

That’s really the trick.

What good looks like at your size

You don’t need a complicated release process.

If you’re one to five people, after a merge that a user would actually notice, write two sentences:

What changed?

Why should I care?

Put it somewhere permanent. Send it wherever your users already are. Move on.

The important part is doing it consistently instead of trying to reconstruct everything at the end of the month.

That permanent page becomes useful over time. It’s what you send when someone asks what’s new. It’s something a potential customer can look at before signing up. And eventually, it’s a record that the product has actually been moving.

One update doesn’t say much.

Fifty updates over a year says quite a lot.

The part nobody mentions

Writing the update changes how you build, too.

When you know you have to explain what you shipped this week, you start noticing which changes actually matter to users. It forces you to separate the work that made the product better from the work that just made the codebase better.

And that makes the next update a little easier.

ReleasesHQ reads your merged pull requests and drafts the release notes, so the decision of what to include takes minutes instead of an afternoon. Review, publish, and it goes to your release notes page, your site, and the channels your users are already in.