Review
Read what the agent changed in the Changes pane, revert or accept single hunks, send comments back to the agent, and run code reviews at four depths.
An agent can change a lot of code quickly. Reviewing it should be just as quick. Nib gives you two tools: the Changes pane, where you read the diff yourself, and code review, where agents read it for you and report findings.
The Changes pane
Open it with Changes in the pane toggles, or ⌘⇧D (Ctrl+Shift+D).
Scopes
Choose what the diff covers:
| Scope | Shows |
|---|---|
| Since last message | What the agent changed in response to your latest message |
| This session | Everything the session changed since it started |
| Working tree | All uncommitted changes in the folder, whoever made them |
| Branch | Everything on the current branch compared with its base. Hidden when there's no base to compare against |
Use j and k to move between files. Each file can be collapsed, and the view can switch between unified and split, show unchanged lines, or soft-wrap.
Hunk by hunk
Every hunk has four actions:
- Ask about hunk quotes the hunk into the composer so you can ask the agent about it.
- Comment on hunk adds a review comment (see below).
- Revert hunk puts that part of the file back the way it was. If the file changed since the diff loaded, Nib refuses rather than overwrite edits it hasn't shown you.
- Accept hunk marks it reviewed. Accepting every hunk in a file stages the file.
Each file shows its state: Pending review, Accepted or Reverted.
Comments to the agent
Use the comment button beside any line to comment on it, or Comment on hunk for the whole hunk. Comments collect in a tray at the bottom of the pane instead of being sent one by one. When you're done, choose Send comments or press ⌘↵ (Ctrl+Enter), and Nib sends them to the agent as a single message with each comment's file and line. The agent then works through them like any other request.
Commit
Below the diff, write a commit message or generate one from the session, then Commit. Pushing from the pane isn't available yet; push from a terminal or ask the agent.
Code review
A review is a read-only run: the reviewing agent can read files and run read-only commands, but it can't edit anything. It reports findings, each with a file and line, a severity, and the reasoning behind it.
Review levels
| Level | What runs | Use it when |
|---|---|---|
Quick (quick) | One pass over the diff with about 20 lines of context around each hunk | Before you commit |
Standard (standard, default) | One reviewer reads the changed files and their direct callers | Before a pull request |
Deep (deep) | Parallel reviewers, one per concern (correctness, security, tests, performance and concurrency, API compatibility, maintainability). Duplicate findings are merged, and each important finding goes to a verifier that tries to build the concrete failure, then marks it confirmed, plausible or refuted | Risky changes, large pull requests |
Ultra (ultra) | Deep, plus each important finding is also checked by the first two models named in --verifiers, and it's confirmed or refuted only when at least two of the three verifiers agree. Optionally writes a failing test in a scratch worktree to reproduce the problem | Security-sensitive code, releases |
Ultra runs only when --verifiers names models from at least two families (for example GPT and Gemini); Nib doesn't pick verifiers for you. Otherwise it runs Deep and tells you so.
Deep and Ultra have a spending cap, $5 and $15 by default. A review that reaches it stops starting new reviewers and shows what it found so far.
Running a review
In the app there are three ways to start one:
- Type
/reviewin the composer. Level chips appear (Quick, Standard, Deep and Ultra, each with an estimate), and Tab and Shift+Tab cycle through them. Whatever you type after/reviewgoes to the reviewers as instructions. - In the Changes pane, Review runs a Standard review. Its menu starts a Quick, Deep or Ultra review, or reviews only the file open in the diff.
- In the Review pane, choose a level and press Start review.
The Review pane shows progress while the review runs and the findings when it finishes. Each finding has Fix, Dismiss and Ask about this, and Post to PR… sends findings to the bound pull request as one review.
Ultra needs --verifiers, and only the message form below takes it. Started from the app or from the CLI's interactive mode, an Ultra review runs Deep and tells you so.
To pick a level from a script, the Agent SDK or an ACP editor, send /review with a level as the message text, for example with nib -p:
nib -p "/review deep"
nib -p "/review ultra --base main --verifiers openai:gpt-6.1-sol,google:gemini-4-argon --reproduce"
nib -p "/review quick --focus security,tests check the new auth middleware"/review [quick|standard|deep|ultra] [--base REF] [--max-cost USD]
[--reviewers provider:model,…] [--verifiers provider:model,…]
[--focus area,…] [--reproduce] [instructions…]| Option | Meaning |
|---|---|
--base REF | Review the branch against REF (git diff REF...HEAD). Without it, Nib reviews uncommitted changes |
--max-cost USD | Spending cap for Deep and Ultra |
--reviewers | Up to three models for the Deep reviewers |
--verifiers | Models for Ultra's extra verifiers; the first two are used. Ultra needs them to come from at least two families |
--focus | Concerns to emphasize, such as security,tests |
--reproduce | Ultra only: try to reproduce important findings with a failing test in a scratch worktree |
Anything after the options is passed to the reviewers as extra instructions. Deep and Ultra skip lock files, dist/ folders and minified files.
In the CLI's interactive mode, /review [quick|standard|deep|ultra] [pr|branch|uncommitted|last-turn] [--post] [focus] starts a review through the daemon. Without a level it runs Standard. Without a target it reviews the bound pull request, else the branch of a session in a worktree, else the uncommitted changes. --post posts the findings to the pull request, which needs one bound to the session. See the CLI reference.
Next
- Race: compare several attempts before you review one.
- Parallel agents: keep several agents' changes apart.
Budgets and receipts
See what each turn used and who paid for it, follow usage over time, and set limits for your plan, credits and your own keys.
Parallel agents
Run several agents on one repository without collisions — worktrees, subagents, workflows, steering and the Board — and what's still in preview.