relnotes: Release Notes From Git History, Generated by an Open-Weight Model

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

relnotes — a CLI that turns your git history into user-facing release notes, generated by an open-weight model running on your own machine.

The thing it fixes is small and annoyingly real: every project ships, nobody writes the changelog, and the release goes out with either no notes or "bug fixes and improvements". relnotes reads the git log between two refs and rewrites it into grouped, plain-English bullets — the way a human would have written them if they had twenty minutes they don't have.

Who would pay for it: anyone shipping software on a schedule. Freelancers billing clients for a monthly release, small teams that maintain a public changelog, maintainers of side projects who abandoned theirs six months in. It's the exact "tedious task that someone keeps complaining about" the prompt describes.

Demo

$ relnotes.py --offline

### Added

- initial CLI skeleton with offline template rendering

### Changed

- add README and relnotes agent skill
- cover conventional-commit parsing and CLI end to end

That is the tool's real output on its own repository, run offline — commit
6f795d2 exists
because of it. With a local open-weight model the same command produces the
same shape, only the bullets get rewritten into end-user language. The full
project is at github.com/Mystical89/relnotes.

Code

github.com/Mystical89/relnotes — MIT licensed, Python 3.10+, no dependencies, 5 passing tests.

relnotes.py          # the CLI: git log -> model -> changelog
test_relnotes.py     # parsing, grouping, and end-to-end CLI tests
skills/relnotes/     # agent skill, so an agent can run it for you

How I Built It

The open-source AI part is the core of how it works, not a garnish:

• Open-weight model: any OpenAI-compatible endpoint backed by an open-weight model — Ollama by default (qwen2.5:3b), or LM Studio, llama.cpp, vLLM with one flag.
• A strict system prompt does the rewriting: group under Added / Fixed / Changed, ≤12 words per bullet, no commit hashes, no file names, no "refactor"/"chore" jargon, drop uninformative commits. Temperature 0.3 so two runs of the same release produce the same notes.
• Open-source agent harness integration: it ships as a Hermes skill following the Agent Skill Open Standard, so an agent can be told "write the release notes since v1.2.0" and call it directly.

Conventional Commits drive the section grouping, which is what makes the offline fallback structurally identical to the model output.

Why Does Open Innovation Matter?

Three reasons, all of which change whether the tool is actually viable:

It costs nothing per release. A 3B model on a laptop replaces a hosted API bill for summarising text you already own. At one release a week it's noise, but for the solo dev shipping every other day it's the difference between a tool they use and one they try twice.

Your commit history never leaves the machine. This is the part that made me build it this way rather than as a hosted web app. Commit messages leak internal project names, unreleased features, and occasionally a pasted secret. You cannot safely send that to a third-party API, so a hosted version of this tool either asks you to trust it with your history or strips out everything interesting. Local inference makes the safe version the default version.

No vendor lock-in. The model is a flag, not a decision. Swap qwen2.5:3b for something bigger as hardware allows, or point it at a different server — no code changes.

Not yet — this is day one of the project. The plan is to run it on the next release of this very repo and paste the result in as a comment, which is either a good demo or an honest bug report.

Update, same day: the plan took about ten minutes. relnotes has now been run on its own repository — commit 6f795d2 exists because of it:

$ relnotes.py --offline

### Added

- initial CLI skeleton with offline template rendering

### Changed

- add README and relnotes agent skill
- cover conventional-commit parsing and CLI end to end

Two honest notes on that run. First, there is no model endpoint on this machine yet, so this is the deterministic template path, not the model path — the README says so too. Second, the first attempt was wrong: --since <root> printed nothing under Added, because root..HEAD excludes the root commit itself. I caught it by diffing the output against git log, and it is now the first pitfall in the README. Writing the tool's own release notes found a real bug in the tool, which is either a good sign or a very small sample.

Nobody has paid yet. Next step is qwen2.5:3b through Ollama so the model path gets the same real run.