Several months ago, I found myself needing to ship code really fast. I was moving so fast, even writing readable commit messages felt like a luxury. Lots of breaking changes were required with a tight deadline.
The Problem
From my past experience, I found it particularly difficult to make good commits when I was dealing with:
- Early-stage code → because I’m unsure of the final implementation.
- Large changes → because describing or summarising large changes succinctly is difficult.
- Rapid prototyping or MVP → because code evolves faster than your thoughts (or the requirements change faster than you can code 🥁).
In these situations, there is a mental conflict in my head saying, I know exactly what I changed 😏, but why is it so hard to describe it? 🤔 I take commit messages seriously as a courtesy for others (or future me) that may review my code so I can run into analysis paralysis in such situations.
That’s when I thought: if LLMs can write code, why not let them handle my commits too?
The Solution
Since LLMs are so good at generating code I thought a good commit message can be generated just from diffs. My solution is kommit. When I started building this tool, which was early March, I wasn’t aware of Claude Code, or any other similar AI-powered CLI tools.

Some good feedback and feature requests from colleagues have led to a few releases so far, currently sitting at v0.3.1.
I’ll guide you through how to install, set up and run it. If you’d like to explore at your own pace, README covers most of what’s discussed below.
Install
Installing is straightforward:
- Using homebrew:
brew install cowboy-bebug/tap/kommit
- From source:
git clone https://github.com/cowboy-bebug/kommit.git cd kommit make install
Setup
To set up, either of these environment variables should be exported with the
KOMMIT_
prefixed one taking precedence:
export OPENAI_API_KEY="sk-..."
export KOMMIT_OPENAI_API_KEY="sk-..."
Then run:
git kommit init
which creates a config file .kommitrc.yaml
that looks like:
llm:
model: gpt-4o-mini
commit:
types:
- feat
- fix
- docs
# ... other conventional commit types
scopes:
- ui
- api
- auth
# ... project-specific scopes
Usage
First, files or diff chunks must be staged. Then simply run:
git kommit
and follow the prompts to either:
- generate a new commit message,
- edit the generated commit message in your editor such as vim (can be selected
by passing
--edit
flag), - proceed to create a commit with the generated commit message (can be selected
by passing
--approve
flag), - or quit.
Relevant context can also be passed with --message
(or -m
for short). For
example, a usage like this:
git kommit -m "performance increased by 10x with these changes"
will create a commit message that looks like:
perf: increase performance by 10x
- Add ...
- Remove ...
[Generated by Kommit]
What I’m particularly happy about is the cost
subcommand:
git kommit cost
which would print something like:
💰 Kommit Financial Therapy Session 💰
Repository Cost ($)
~/github.com/username/project-1 0.00178
~/github.com/username/project-2 0.00064
~/github.com/username/project-3 0.00090
~/github.com/username/project-4 0.00047
~/github.com/username/project-5 0.00968
~/gitlab.com/username/project-6 0.00144
~/gitlab.com/username/project-7 0.00500
~/github.com/username/project-8 0.00058
TOTAL 0.02049
Use ↑/↓ or k/j to navigate
Press Ctrl+c or q to exit
Potential Improvements
Here are a few ideas that come to mind for future improvements:
- Increase diff context: pass more lines of surrounding code to the LLM
using something like
git diff --staged -U10
to help the model understand changes more accurately. - Enrich prompts with metadata: include file types, commit history (relating
to the changes), or project specific-cues.
- Here lies a challenge I come across often, which is evaluation. Without persisting the generated output somewhere, it’s difficult to track regressions for quality.
- Support other commit conventions: allow users to choose from different commit styles such as gitmoji.
What I Learned
I learned that any executable files prefixed with git-
automatically becomes
an extension of git
so building this binary as git-kommit
makes kommit
available as a native Git command.
I also noticed a substantially increased baseline for commit message quality, especially from folks who usually treat them as an afterthought. 😅
Using kommit
shifted my focus more towards logically grouping similar files or
changes together, and letting the tool handle the rest.
I’ve heard great things about
Claude Code, and it
might make kommit
obsolete. But building it was a fun and rewarding weekend
project. One thing I’d like to try with claude
is making a large set of
changes and letting it generate multiple logically flowing commits, effectively
removing the stating step from the kommit
workflow.