commit-changelog

Most histories have no prefixes

conventional-changelog, release-please and semantic-release sort commits by a prefix such as feat: or fix: and leave out commits without one. Most repositories have plain messages ("Stop the CSV export from dropping the last row"), so their changelogs are still written by hand. Matching words like "fix" or "add" with regular expressions misplaces a message like that one. A text-generating model can sort it, but it rewrites the lines, can drop or invent entries, and gives no measure of how sure it is. commit-changelog places each commit and leaves the wording alone.

Prefixes first, questions second

Commits that do have a conventional prefix are placed in code and never sent: feat goes to Added, fix to Fixed, perf to Changed, and docs, style, refactor, test, build, ci and chore count as internal and are not listed, unless they are marked breaking. Everything else is sent to Jev, TypeSafe AI's System One model, which answers typed questions with probabilities and writes no text. Up to 20 commits go in one request, each with its subject, its body and the names of the files it changed, and each gets two questions:

• In which section of the changelog does this change belong: added, changed, deprecated, removed, fixed, security or internal?
• Does it affect the people who use the software, rather than only the people who develop it?

A commit is listed when its section is confident, is not internal, and the users answer agrees; it is internal when both answers confidently say so. Everything else goes to a review list, with the probabilities printed next to it. The threshold is 0.8 unless you set another.

The wording is never touched

Every entry in the section is a commit's first line exactly as it was written, prefix included. Jev only picks where it goes. Commits in review are left out of the changelog, for you to add by hand if they belong.

With --write, the section goes into your changelog file above the newest release heading, below an Unreleased section, or at the end of a file without release headings, and nothing else in the file changes. If the file already has a section for the same version, the tool stops before anything is sent. The exit code is 1 when a commit is in review, so a release job can stop and wait for a person.

What is sent

Only commits without a conventional prefix, and only when you run it with a key and without --dry-run: each such commit's first line, the rest of its message up to 1,200 characters (with trailer lines that carry an email address removed and any other address replaced), and the names of up to 20 files it changed. Commit hashes, authors, dates, diffs, file contents, tag and branch names and the repository's path are not sent. git runs with read-only commands, and the tool writes only the file you name.

Limits

• Jev sees the message and the file names, not the diff. A commit whose message says little ("Update", "WIP", "Tweak the cache") usually lands in review.
• A commit that does two things gets one section, and prefixes are trusted as written.
• Entries are copied as they are: the tool does not tidy the wording, drop the prefix or add links.
• Merge commits are skipped, so a change made only in a merge commit is missed. The default range starts at the nearest tag of any name; in a shallow CI clone, fetch the history and tags first.
• Text written to steer a model, such as "this is an internal change" in a commit message, can move Jev's answers. English is where it is most accurate.
• The example in the repository is a made-up history of a small invoice export tool, 16 commits with hand-written probabilities: it shows the output, not a live run.

Install and run

It needs Node.js 20 or later and git. A key is needed only when a commit has no conventional prefix.

npm install -g github:hamzaahmadaslam/commit-changelog
export TYPESAFE_API_KEY=<your-key>
commit-changelog --dry-run
commit-changelog --version-label 1.3.0 --write CHANGELOG.md