The idea
A command-line tool that takes two git refs (tags, SHAs, or branch names) and turns the commits between them into a structured release notes document. It groups commits by type (features, fixes, breaking changes, chores), rewrites terse commit messages into plain sentences, and outputs Markdown ready to paste into GitHub Releases or a CHANGELOG.md. One command, no config required for a basic run.
Why build this
Writing release notes is one of those tasks every project needs but almost nobody does well. The raw commit log is machine-readable but human-hostile. Conventional Commits help, but many teams don't follow them consistently, and even those that do still end up with notes like "fix: update dep" that tell users nothing. AI models are now good enough to read a noisy commit log and infer what actually changed — which is the part that used to require human judgment and therefore always got skipped.
Tools like auto and semantic-release exist, but they're framework-heavy and opinionated about your whole release pipeline. A focused CLI that does exactly one thing — "read commits, produce notes" — fits into any workflow without buy-in.
Stack sketch
- Runtime: Go, single static binary, zero install friction.
- Git data:
go-gitlibrary to read local repos without shelling out togit. - AI summarization: Claude Haiku 4.5 via the Anthropic SDK — fast, cheap, accurate enough for this task. Each commit message is a ~10-token input; a 200-commit release costs fractions of a cent.
- Output templates: Go
text/templatefor Markdown and JSON output formats. - Config (optional): A
.releasenotes.ymlin the repo root to customize section headings, scope filters, or exclude bots/merge commits.
Scope for v1
In:
- releasenotes v1.2.0 v1.3.0 syntax to specify the range.
- Auto-detect conventional commit prefixes (feat:, fix:, chore:, etc.) and fall back to AI classification when the prefix is missing or inconsistent.
- Three output sections: Features, Bug Fixes, Other Changes.
- Plain Markdown output to stdout (redirect to file or pipe to pbcopy).
- Skip merge commits and commits from configured bot usernames automatically.
Out: - GitHub/GitLab API integration (paste notes yourself — keep the scope tight). - Semver bumping or tag creation. - Multi-repo monorepo support (scope to a path prefix in v2).
Where it could go
The obvious next step is a --push flag that opens or updates a GitHub Release draft via the API, turning the two-step "generate then paste" into a single command. Alongside that, a --pr-summary mode that summarizes commits on the current branch against main and posts them as a PR description — which gets developers writing better release notes without ever thinking about release notes.
Longer term, the tool could learn your project's tone and terminology by reading your last 10 releases and using them as few-shot examples, so the output sounds like your team wrote it rather than a generic summarizer.
Watch out for
The quality of the output depends entirely on commit message quality — a repo full of wip and misc commits will produce mediocre notes no matter how good the model is. Set user expectations early: this tool amplifies good commit hygiene, it does not replace it. Also watch API latency on large releases; batching commits into chunks of 30–50 per request keeps p95 under two seconds even for 200-commit spans.