AI Code Review CLI: Review Uncommitted Changes Before You Push
What a terminal reviewer should inspect, what “local” really means, and how to give Claude Code, Codex, Cursor, or OpenCode an independent finish pass.
An AI code review CLI examines the change in your working tree before a pull request exists. A useful one includes staged, unstaged, deleted, and untracked files; reads nearby code and tests; runs relevant checks; and returns an outcome another agent can consume. “Local” describes where the code state lives. It does not automatically mean the model runs on your hardware.
The useful unit is the working tree
A pull-request reviewer starts after code has been committed, pushed, and packaged for GitHub. A local reviewer can start earlier. That matters when an agent has changed six files, created a regression test, deleted an obsolete helper, and not committed any of it. Reviewing only git diff can miss staged files; reviewing only the branch can miss all uncommitted work. The review boundary should be explicit.
| Check | Best moment | Main limitation |
|---|---|---|
| Author self-review | During implementation | The author chooses the framing and judges its own result. |
| Independent CLI pass | Before commit or push | It can still miss defects and must state its limits. |
| Pull-request review | After push, around team review | Feedback arrives later in the loop. |
| Deterministic CI | On every protected change | It runs only the assertions the repository has encoded. |
Local code is not the same as local inference
A CLI can read a repository on your machine while sending a bounded prompt to a hosted model. Another tool may execute both code and inference locally. Those are different privacy and architecture claims. Ask exactly which files are collected, whether ignored environment files are used, what leaves the machine, how long prompts are retained, and whether source is used for training. Do not infer those answers from the word “local.”
What to compare before you install
A useful comparison starts with the evidence contract, not the model name. Check the working-tree boundary, the default command, the exit codes, the output format, the repair behavior, and the data path. A reviewer that only prints comments may be pleasant in a terminal but difficult for an agent to act on. A reviewer that can edit files without a distinct repair boundary can make diagnosis and accountability harder.
- 1What exactly is in scope?Confirm how it handles staged, unstaged, deleted, untracked, ignored, generated, and binary files.
- 2What does a failure mean?Look for documented exit status, severity, and whether an unavailable check is distinct from a clean result.
- 3Can another process consume the result?Prefer JSON or another stable schema with findings, evidence, limitations, and changed paths.
- 4When can it modify the tree?Review and repair should be separate, explicit operations with a fresh check after repair.
- 5What leaves the machine?Read the provider’s retention, training, redaction, and secret-file handling documentation.
A practical pre-push workflow
Install once, then review the candidate finish
The intent tells the verifier what behavior must exist; JSON gives the calling agent a stable handoff.
npm install --global @critiquedotsh/cli
critique login
critique integrate --agent all- 1Did it capture the whole candidate change?Include staged, unstaged, deleted, and untracked paths. Report exclusions instead of silently ignoring them.
- 2Did it test the claim rather than admire the diff?Reproduce the intended behavior with repository-native tests, type checks, builds, or a small targeted probe.
- 3Is the reviewer independent from the author?Use a fresh role and context so the implementation narrative does not become evidence by repetition.
- 4Can the caller act on the result?Return the outcome, evidence, changed paths, limitations, and a stable exit status—not an essay the agent must scrape.
Where Critique fits
The critique binary is the sidecar for an agent you already use. Claude Code, Codex, Cursor, OpenCode, or a human can author the change; the sidecar receives the candidate finish and returns an independent result. CritiqueCode is different: critique-code is the author agent, and its controller forces the review path before promotion. Pick the binary by who should author the patch.
Start with twenty real changes
Adoption is easier to judge on a small sample than in a feature matrix. Run the tool on a mix of bug fixes, refactors, migrations, tests, and agent-generated changes. Record what it saw, what it missed, how long it took, whether the output was actionable, and which checks still required a human. Those notes become a local baseline for deciding where an independent pass earns its latency.