review

One code-review pass over a diff, PR, commit, or branch — parallel lenses, confidence-gated findings. It reports; it does not fix, commit, or push.

What it does

This is the reviewer implement hands off to at the end, and it works standalone on any change. One pass, real findings only.

Pick the scope

Detect what to review, in order:

1. An explicit target the user named — a PR number, commit hash, or path.
2. Uncommitted work — git diff HEAD (plus git status for new files).
3. Nothing pending → the branch vs its base (git diff <base>...HEAD).

For a PR it pulls the diff with gh pr diff / glab mr diff, and states the scope it settled on before reviewing.

Review (parallel lenses, one pass)

Read the diff, then apply these lenses — in parallel as sub-agents for large diffs, inline otherwise:

• Correctness — logic errors, edge cases, off-by-one, null/empty, error paths, intent vs implementation.
• Simplicity / YAGNI — reinvented stdlib, speculative abstraction, dead flexibility, duplication. What can be deleted.
• Tests — missing coverage on branches/loops/parsers/money-security paths; weak or implementation-coupled assertions.
• Context lens (conditional) — add security when the diff touches auth, input handling, or secrets; performance when it touches hot loops, queries, or I/O. Skip if nothing warrants it.

Gate, dedup, report

A confidence gate drops anything not tied to a concrete failure. High/Critical findings are adversarially refuted before reporting. Output is ranked most-severe first with file:line and a fix — and an empty list is a valid, good result.

When to use it

When you say "review", "code review", or "review this PR/diff/branch" — or automatically when implement finishes a build.