# Review before the push: why the strongest review window is right before `git commit -m`. > Why CommitBrief defaults to --staged scope. Reviewing a change that hasn't entered history yet is always cheaper than patching it with a force-push. Published May 31, 2026 by CommitBrief (https://commitbrief.com) Canonical URL: https://commitbrief.com/blog/review-before-the-push/ Tags: workflow, pre-commit, git --- 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](/blog/force-multiplier-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. ```sh 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 ` to a specific file). - `commitbrief diff ` — a specific commit, typically `HEAD`. A one-second look back at what you just committed. - `commitbrief diff ` and `commitbrief diff ...` — 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: ```text 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.