Loading page
About this tool
Parse Conventional Commits into Keep a Changelog sections and a SemVer bump, then build the writing prompt.
A changelog prompt builder reads your merged commit titles, classifies each one under Conventional Commits 1.0.0, maps it to a Keep a Changelog 1.1.0 section, and works out the Semantic Versioning 2.0.0 bump the set implies before writing the prompt. Breaking changes marked with an exclamation mark or a BREAKING CHANGE footer force a major bump and get pulled to the top with a migration note. The result is a prompt that turns commit shorthand into release notes a user can act on, without inventing changes that were never shipped.
Open Changelog Prompt Builder on AltFTool — it loads instantly in your browser.
Paste your code or data sample into the workspace.
Pick the format, conversion, or analysis you need.
Copy the polished result straight back into your project.
Breaking beats feature, feature beats fix — the same precedence Semantic Versioning 2.0.0 defines.
Added, Changed, Deprecated, Removed, Fixed, Security, with empty sections dropped, exactly as Keep a Changelog specifies.
Lines that are not in Conventional Commits format are still listed, defaulted to Changed and flagged for a human to re-classify.
Semantic Versioning 2.0.0 is explicit: increment MAJOR for backwards-incompatible API changes, MINOR for backwards-compatible new functionality, and PATCH for backwards-compatible bug fixes. One breaking change anywhere in the set forces MAJOR, no matter how many small fixes ship with it.
Conventional Commits 1.0.0 gives you two ways: put an exclamation mark before the colon, as in feat(api)!: drop v1 endpoints, or add a BREAKING CHANGE: footer describing the break. Either one signals a MAJOR bump, and the footer is the better choice when the explanation needs more than a subject line.
Keep a Changelog defines six: Added, Changed, Deprecated, Removed, Fixed and Security. Show only the ones with entries, keep them in that order, and put the newest release at the top of the file so a reader lands on what just shipped.
No, unless they change observable behaviour. Dependency bumps, formatting, test and CI commits belong in the commit history, not the release notes. The exception is a dependency bump that fixes a known vulnerability — that goes under Security with the advisory referenced.