Review changes

Review the code changes named by $ARGUMENTS and report defects. This is a read-only review: never edit, stage, commit, or push anything.

Resolve the target

Interpret $ARGUMENTS:

• Empty: review the current uncommitted diff (git diff HEAD; if that is empty, git diff --staged).
• pr <n> or a bare number: gh pr view <n> for intent, then gh pr diff <n> for the changes.
• A path ending in .diff/.patch: read the file directly and review it as a patch.
• Any other existing file path: review that file's changes with git diff HEAD -- <path>.
• Otherwise treat it as a git ref/range and run git diff <arg>.

If the target cannot be resolved, say why and stop — do not guess or review a partial target. Report the specific blocker: the argument matches no file, ref, or PR; the directory is not a git repo (git errors with "not a git repository"); gh is missing or unauthenticated (its command errors or prints an auth prompt) when a PR was requested; or the resolved diff is empty (nothing to review).

Understand before judging

1. Establish intent: read the PR/commit description, or infer it from the diff. State it in one line. Every finding is measured against whether the change achieves this.
2. Detect the stack and conventions from the repo itself — language, test framework, lint/format config, error-handling and naming patterns in neighboring files. Follow what the project does, not what you'd prefer.
3. Read enough surrounding code to judge each hunk: the full function, its callers, the types it touches. Never review a hunk in isolation.

Review in this order (stop-the-line issues first)

1. Correctness and edge cases: trace the logic against the intent. Check nulls/empties, off-by-one and boundaries, error/exception paths, await on every promise, resource cleanup, concurrency and re-entrancy, integer/precision, and every early return. Actually follow the values — do not pattern-match.
2. Security: untrusted input reaching SQL/shell/HTML/filesystem/deserialization; authz checks on new endpoints; secrets or tokens in code or logs; injection and path traversal.
3. Tests: does the change carry tests for its new logic and failure modes? Name the specific missing case. Flag tests that assert nothing or only the happy path.
4. Design and readability: duplication that should be reused, dead code, leaky abstractions, misleading names, unhandled states. Only raise these when they impede correctness or future maintenance.

Verify the diff does what it claims and nothing silently extra (unrelated behavior changes, debug code left in).

Output

Group findings under three headings; within each, order by severity. Every finding cites file:line and gives a concrete fix or a specific question — never "consider improving".

• Blocking — bugs, security holes, missing critical tests, or a change that doesn't meet its intent. Must fix before merge.
• Nits — prefix each line with Nit:. Non-blocking improvements.
• Questions — where you need author intent to judge correctness.

If a section is empty, write "None". Close with a one-line verdict: approve, or the count of blocking issues.

Rules

• Never edit files or run mutating git/gh commands. Read and diff only.
• Do not flag formatting, import order, or style owned by the project's formatter/linter.
• No praise, no summary of what the code does — report only problems and open questions.
• Say "I couldn't verify X" rather than guessing; do not invent line numbers or behavior you didn't read.