Code review

1---2name: code-review3description: Reviews a diff or pull request for correctness, security, tests and maintainability, and reports findings ranked by severity with concrete fixes. Use when the user asks for a code review, a second opinion on a change, or "is this safe to merge?".4license: MIT5version: 1.1.06allowed-tools: Read, Grep, Glob, Bash(git diff:*), Bash(git log:*)7---8 9# Code review10 11Review like a careful senior colleague: find the problems that matter, explain them, propose a12fix, and do not drown the author in nitpicks.13 14## 1. Understand the change15 16- Read the description or ask what the change is supposed to do.17- Get the diff: `git diff <base>...HEAD` (or the files the user points to).18- Read the surrounding code of every changed function, not only the changed lines.19 20## 2. Check, in this order21 221. **Correctness** — Does it do what it claims? Edge cases: empty input, `null`/`undefined`,23   zero, very large values, unicode, time zones, concurrency, retries, partial failure.242. **Security** — Untrusted input reaching SQL, shell, HTML, file paths or URLs; missing25   authorisation checks; secrets in code or logs; unsafe deserialisation; open redirects.263. **Data** — Migrations that lock or rewrite large tables, missing indexes, lost data on27   rollback, breaking API or schema changes for existing clients.284. **Tests** — Is the new behaviour tested? Would the tests fail without the change? Are29   failure paths covered?305. **Error handling and observability** — Errors swallowed, unclear messages, missing logs for31   operations that can fail in production.326. **Maintainability** — Duplication with existing helpers, unclear names, functions doing too33   much, dead code. Only mention style if the project has no formatter.34 35## 3. Report36 37Group findings by severity and give each one a location, the problem and a fix:38 39```markdown40### Blocking41 42- `src/api/orders.ts:88` — the discount is applied twice when `retry=true`.43  Fix: compute the total once before the retry loop (suggested patch below).44 45### Should fix46 47- …48 49### Optional50 51- …52 53### Looks good54 55- Short note on what is solid, so the author knows what not to change.56```57 58- Verify each finding by tracing a realistic input to the failure. If you are not sure, say so59  and ask a question instead of stating it as fact.60- Prefer a small suggested patch over a long explanation.61- Do not approve or merge on the user's behalf.

Checks a change or a module for common security problems (injection, broken access control, secrets, unsafe dependencies, SSRF, XSS, insecure defaults) and explains each finding with a fix. Use when the user asks for a security review or before merging changes that handle input, authentication or fi