Code Review

Review real changes for real problems. Report only what you verified.

Step 1 — Collect the diff

Run in order, stop at the first that yields content:

1. git diff (unstaged) and git diff --cached (staged) — review both if both exist
2. If the user named a branch/commit: git diff <base>...HEAD
3. If the user named files instead: review those files in full

If there is no diff and no named files, say so and ask what to review. Do not review the entire repository unprompted.

Step 2 — Read the changed code fully

For every changed file, read the whole file (or at minimum the full enclosing functions/classes), not just the diff hunks. Context outside the hunk is where most false positives die and most real bugs hide. Also read callers of changed functions when a signature or behavior changed (grep for the function name).

Step 3 — Check, in priority order

1. Correctness — logic errors, inverted conditions, off-by-one, wrong variable, broken invariants, changed behavior callers still depend on
2. Security — injection (SQL/command/path), missing auth checks, secrets in code, unsafe deserialization, SSRF, XSS in rendered output
3. Error handling — swallowed exceptions, unchecked return values, missing cleanup on failure paths, error messages leaking internals
4. Edge cases — empty/null input, zero/negative numbers, unicode, concurrency, timezone/DST, very large input, first-run state
5. Data loss — destructive migrations, unguarded deletes/overwrites

Ignore formatting, naming, and style preferences unless the user explicitly asks, or a name is actively misleading (says the opposite of what the code does).

Step 4 — Verify before reporting

For every candidate finding, confirm it before it goes in the report:

• Re-read the code path and trace the actual values — does the bug really occur?
• Check for guards elsewhere (validation upstream, types, framework behavior).
• If a claim depends on library behavior you are not sure about, check the installed version's docs or source in node_modules/site-packages rather than guessing.
• Drop anything you cannot substantiate. A short, correct review beats a long, noisy one.

Step 5 — Report

Output a severity-ranked table, most severe first:

#	Severity	Location	Issue	Why it breaks	Suggested fix
1	Critical	src/auth.ts:42	Token compared with ==	Timing-unsafe comparison enables token forgery via timing attack	Use crypto.timingSafeEqual

Severity levels:

• Critical — exploitable security issue, data loss, or guaranteed crash on a common path
• High — wrong behavior users will hit, or security issue needing specific conditions
• Medium — bug on an edge case, missing error handling that hides failures
• Low — fragile pattern likely to become a bug; mention briefly

After the table add:

• Verdict: one line — "Safe to merge", "Merge after fixing #1-#2", or "Needs rework".
• Not checked: anything you could not verify (e.g. no tests run, external service behavior) — one line each. Never present unverified concerns as findings.

If you find nothing: say the diff looks correct, state what you checked, and name the riskiest spot you examined. Never invent findings to seem thorough.