Cocogitto
The conventional commits toolbox. From your commits to a changelog and a tagged release, automatically.
init · commit · check · changelog · bump
Meet Cocogitto: one command, cog, that makes conventional commits effortless, and then turns them into a changelog and a versioned release for you. From an empty repo to a tagged release in a handful of commands.
One small binary for the whole job
- Written in Rust · one binary, only needs libgit2.
- Writes + checks commits · conventional by construction.
- Changelog + version · generated from those commits.
- MIT · open source, no runtime to install.
So what is it? Cocogitto is one small binary. It is written in Rust, and the only thing it needs on your system is libgit2. No Node, no Python, no runtime. It writes conventional commit messages for you, and it validates that your whole history follows the spec. And from those commits it generates a changelog and a semantic version bump. It is MIT licensed and open source.
Set up in one command
mkdir my_app && cd my_app
cog init
Like git init, but conventional-aware: drops a
template cog.toml and an initial
chore: initial commit.
Start in an empty folder and run cog init. Like git init, but conventional aware: it drops a template config file and makes your first commit, a chore, initial commit. You are set up in one command.
Write commits without memorizing the format
cog commit feat "add awesome feature"
cog commit fix "correct a login bug" auth
cog commit feat -B "drop the legacy API"
Type is positional · scope is the trailing word
(fix(auth):) · -B marks a breaking
change (feat!:).
Instead of memorizing the exact conventional commit format, you describe the change and cog writes a compliant message. The type is a positional argument. Add a scope as the trailing word, and it is folded into the message. The breaking flag adds the exclamation mark the spec uses for a major release. Typo a type and cog rejects it, so you can not write a non compliant message by accident.
Validate every commit, the way CI does
cog check # the whole history vs. the spec
cog check -l # only since the latest tagThe same check the Cocogitto GitHub Action and pull request bot run for you on every change.
Run cog check and it validates your whole history against the conventional commits spec, and points at any commit that does not comply. You can also check only since your latest tag. This is exactly what runs in CI: the Cocogitto GitHub Action and the pull request bot run cog check for you on every change.
A changelog, generated from your commits
## 1.1.0 - 2026-06-29
#### Features
- add awesome feature - (a1b2c3d)
#### Bug Fixes
- correct a login bug - (e4f5c6d)
cog changelog · grouped by type, never hand-written.
Now cog changelog reads those commits and prints a clean changelog, grouped by type: Features, Bug Fixes, Breaking Changes. It is generated from your history, not maintained by hand.
One command for the whole release
cog bump --auto-
fix→PATCH -
feat→MINOR - a breaking change→MAJOR
Then it regenerates the changelog, makes the version commit, and tags it.
Here is the payoff: the auto bump. It looks at your commits since the last tag. A fix bumps the patch version. A feat bumps the minor version. And a breaking change bumps the major version. Then it regenerates the changelog, makes the version commit, and tags it. One command, your whole release.
From an empty repo to a tagged release
No format to memorize. No changelog by hand. No version math.
Enforce it on every pull request with the GitHub Action and bot.
docs.cocogitto.io
So that is the whole arc: from an empty repo to a tagged release, with a generated changelog and zero manual version math. Nothing to memorize, nothing to maintain by hand. And you can enforce all of it on every pull request with the Cocogitto GitHub Action and bot. Read the docs at docs dot cocogitto dot io, and star it on GitHub.
