I used to paste git log --oneline straight onto the release page. It is honest, it is complete, and it is almost unreadable to anyone who does not work in the repo. refactor: move parser, chore: bump dep, fix: handle null in retry, feat: add csv export. A developer scanning that list can reconstruct the release. A customer wants to know what got better and whether anything they rely on changed. Those are different documents built from the same input, and I kept shipping the wrong one.
The problem is not effort. It is that translation from a commit list to a release note is a set of small editorial decisions: what to group, what to drop, how formal to sound, and which headings to put on top. I did those decisions in my head every release and got them slightly wrong every time.
Two audiences, one commit list
For a developer-facing GitHub release, the internal detail is useful. A refactor note helps someone rebasing a fork; a dependency bump matters to someone debugging a conflict. For an in-app notice or a customer-facing release page, that same line is noise. What a customer wants is "you can now export your data as CSV", not the three commits and a parser move it took to get there.
Tone presets make that split explicit instead of implicit. Changelog AI converts raw git commits or release notes into clean, grouped changelogs, with tone presets for developers or customers and multiple output formats: Markdown, plain text, and HTML. Auto-grouping by feature, fix, and improvement, plus version labels with clean headings, gives me a structure I can paste into a release page, an in-app notice, or a GitHub release without reformatting it by hand.
Grouping is a drafting decision, not a fact
I want to be careful here, because "auto-groups" sounds more authoritative than it is. Deciding that fix: handle null in retry is a fix and feat: add csv export is a feature is usually obvious, especially if you write conventional commits with feat: and fix: prefixes. But the boundaries are full of judgement. Is a performance improvement a fix or an improvement? Does a config change belong in the notes at all? Should two commits about the same flaky test be merged into one line?
These are editorial calls, and the tool makes a reasonable first pass at them. It is not telling me the ground truth about the release; it is giving me a draft I can correct faster than I can write from scratch. I still merge duplicate lines, drop the chore: noise, and sometimes move a "fix" up to a headline because it changed user-visible behaviour.
The honest limit follows from that. Changelog AI works on the commits or release notes you paste. It does not connect to a repo, does not track commits on its own, and does not know what happened after your paste. If you want automatic tracking, that is a different tool with a different trust model; this one is deliberately paste-first. Grouping and tone are drafting choices, decision-support for writing release notes, not a live audit of the release, a certification that the notes are complete, or a release approval.
What I still check before publishing
A few things never come from a commit message, and I check for them every time. First, leakage: an internal ticket ID, a colleague's name, an unreleased flag name, or a reference to a system customers should not see. A commit can contain all of these and a generated note will happily carry them into public prose.
Second, accuracy of emphasis. A one-line commit can quietly change a default that some users depend on, and the grouped note may render it as a minor "improvement". That sentence has to be rewritten by a person who knows the impact. Third, anything that should not be described in detail, like a security-relevant fix. A changelog is a public document, and brevity there is a decision, not an omission.
If your release notes are still a paste of git log --oneline, feeding the same commits into Changelog AI and picking the customer tone will at least give you a structure to argue with. Then do the part it cannot: decide what the public is allowed to read.
FAQ
Does it connect to my repo or track commits automatically?
No. It is paste-first. You provide raw git commits or release notes; it groups and formats those. There is no repo connection or auto-tracking.
Can I treat the grouping as the final release notes?
No. Grouping and tone are a first draft. It is decision-support, not a release approval, a live audit, or a certification that the notes are complete.
What output formats does it give me?
Markdown, plain text, and HTML, with version labels and clean headings. It does not publish the notes for you.
Top comments (0)