Review before the push: why the strongest review window is right before `git commit -m`.

Every time you type git push --force-with-lease, that’s a missed review window. The second commit you write to undo the first is direct evidence the first wasn’t properly checked. The combined cost of those two commits — your time, the reviewer’s time, the CI cycles, the muddied blame log — is the bill for doing review at the wrong moment.

CommitBrief defaults to --staged scope. That choice is the architectural expression of the zeroth-reviewer position laid out in the manifesto. A diff that hasn’t been committed, hasn’t touched history, hasn’t crossed anyone else’s machine — that is the cheapest moment review can happen.

Why --staged is the default

Because git add is a statement of intent. You’re saying “I’m going to own this change.” You’re still at a decision point — no --amend yet, no force-push, no apology in the team channel about which commit to ignore. Just you, your terminal, and a diff that hasn’t entered history.

git add internal/auth/session.go
commitbrief

Two lines. The first is ownership, the second is self-review. No reviewer summoned, on your own machine, with your own COMMITBRIEF.md.

This pattern is what we’ve been trying to do with pre-commit hooks for years, with an LLM twist. Pre-commit hooks are excellent at mechanical consistency — they run gofmt, fire the linter, kick off tests. But logic, intent, and design-context checks don’t fit in a hook. commitbrief --staged fills exactly that gap.

The other scopes, and when they matter

The zeroth-reviewer position isn’t bound to the staged diff. CommitBrief gives you two scope flags for the working tree plus a diff subcommand that forwards anything git diff understands:

• --staged (default) — changes not yet committed. Before you open the PR.
• --unstaged — local edits you haven’t git add-ed. Before you decide what’s worth staging.
• commitbrief diff HEAD — working tree vs. HEAD. “Is this file done?” check mid-refactor (narrow with --file <path> to a specific file).
• commitbrief diff <hash> — a specific commit, typically HEAD. A one-second look back at what you just committed.
• commitbrief diff <target> <feature> and commitbrief diff <target>...<feature> — the whole branch or a PR-style three-dot range. When you’re about to open a PR, or before git rebase -i on a tall stack.

All of them run before push. --staged is what you’ll use most often, hence the default; the rest serve the same posture — review the change before it enters history, by the person who wrote it, in their own review flow.

--file and --dir are global path filters that layer on top of any scope: commitbrief --staged --file src/main.go, commitbrief diff HEAD~3 HEAD --dir docs, and so on. Repeatable, applied after the ignore layers.

Rehearse with dry-run

commitbrief dry-run --staged makes no API call. It walks the pipeline: collects the diff, applies the three-layer filter, loads COMMITBRIEF.md, builds the prompt, computes the cache key. The output reports how many files each filter layer dropped:

built-in ignore filtered: 4
.commitbriefignore net filtered: 1
files going to LLM: 3

The cost of seeing what you’re about to send is zero. Especially in your first few weeks — when you’ve just written a new COMMITBRIEF.md or added a .commitbriefignore — dry-run is the rehearsal. Calibrate your filter without spending tokens, then move to the real call.

Post-push review still happens

This post is not saying “don’t do review after the push.” It’s saying that review shouldn’t only happen after the push. When the PR opens, the human reviewer is still on the hook for the things that matter most — design intent, business logic fit, refactor judgment. The zeroth reviewer’s job isn’t to replace any of that; it’s to make room for it.

Before your next PR: run git add, type commitbrief, read the output. You’ll see that a COMMITBRIEF.md you write once keeps working with you for weeks. The next post unpacks the anatomy of that file — what a good rules document looks like, what it shouldn’t contain, why some “obvious” lines are actually noise to the model.

← all posts