Check the changelog, get the next version, write the release
Paste your CHANGELOG.md. Your browser checks it against Keep a Changelog, fixes what is
mechanical, and when you add the commits since the last tag it reads them as Conventional
Commits and works out the next Semantic Versioning version. Free, before you sign in. Then
the desk reviews the file and rewrites entries for the people upgrading, or
drafts the next release from the commits. Every line it writes is checked
again, and the release goes into the file with its links.
The projects are invented. Each example comes with a saved model reply, so you can see the whole page without signing in or spending a credit.
Reviewing
Findings
Entries rewritten
Applying replaces each rewritten entry in the file above, moves it when the review names another type, and re-runs the free check. An entry you have edited since the review is left alone.
What the file does not say
The release
Inserting puts the section under Unreleased with the page's version and date, moves the Unreleased entries into it if you chose to, updates the compare links, and switches to the check.
Breaking changes and how to upgrade
Left out
What you need to confirm
Checked against your browser
Every finding the check raised had to be answered, the verdict could be no looser than the check's floor, every rewritten or drafted entry went through the same commit-subject detector, every user-facing commit had to be placed or explained, every breaking commit needed a migration note, and no entry could cite a commit, issue number or version the input does not carry. A disagreement means the reply, not your file, is wrong.
Summary
Raw model reply
The reply did not parse as the structured result, so it is shown as it arrived.
Your recent runs
If that did not work
Check that versions sit under their own headings (## [1.2.0] - 2026-05-01), that you are
signed in, and that your balance covers the amount reserved next to the button. The five
examples always work and cost nothing, so they are the quickest way to tell whether the
problem is your paste or the service.
What this does, and what it does not
The check is computed, not guessed. Versions compare by Semantic Versioning 2.0.0
precedence, so 1.10.0 is newer than 1.9.0 and 2.0.0-rc.1 is older than 2.0.0. The next
version follows Conventional Commits 1.0.0: a breaking change (a ! before the colon or a
BREAKING CHANGE footer) is major, feat is minor, fix is patch, and every other type moves
nothing. The increment itself matches node-semver, so 2.0.0-rc.1 with a fix becomes 2.0.0.
Before 1.0.0 the page can bump minor on a breaking change, as release-please's
bump-minor-pre-major option does; that is a convention, not part of the spec.
Keep a Changelog is a convention too, and a clean check does not mean the file is complete:
only you know whether every notable change is in it. The page never runs git and never
reads your repository; it reads what you paste. The sources are listed in
llms.txt. Derived from the agent skill
@wshobson/changelog-automation
(wshobson/agents, MIT; see the notice).