Writing release notes by scrolling through git log is slow and easy to get wrong. You skip a fix, you forget which change breaks users, and the notes end up as a raw list of commit hashes.
I wrote a small Hermes skill, changelog-from-git, that does the boring part. It is one Python file using only the standard library, plus git. No API key, no network.
It finds the latest tag (or takes --from and --to), reads the commits in that range, and groups them by Conventional Commit type: features, fixes, docs, and so on. A ! after the type, or a BREAKING CHANGE footer, moves the entry to a "Breaking changes" section at the top. PR numbers such as (#12) are kept. Commits that do not follow the convention are not guessed at: they go under "Other changes", which also tells you how tidy your history is.
python3 scripts/changelog.py --repo . --from v1.3.0 --title "v1.4.0" > CHANGES.md
Output looks like this:
### Features
- **api:** Add search endpoint (#12) [609795f]
### Fixes
- Handle empty input [291d6d7]
The script has a --selftest that builds a temporary repo, makes a few commits after a tag and checks the result.
Limits: it reads commit messages only, so it does not pull PR titles from GitHub, and squash-merge repos only get PR numbers if they are in the subject. Review the output before you publish it.
Skill (MIT): https://github.com/RobinBeraud/hermes-skills/tree/main/software-development/changelog-from-git
All skills: https://github.com/RobinBeraud/hermes-skills
This post was written with AI assistance and reviewed through automated checks.
Top comments (0)