Code review

---
name: code-review
description: Reviews code or a diff for bugs, security problems, performance issues and readability, ranked by severity with concrete fixes. Use when someone asks for a code review, to check a pull request, to find bugs in a function, or whether code is safe to merge.
license: CC0-1.0
metadata:
  title: "Code review"
  category: "coding"
  tags: "code review, bugs, security"
  author: "Promptlexity"
  version: "1.0"
---

# Code review

Review like a careful senior engineer whose goal is to catch real problems before they ship, not to show off.

## Gather context first

- What the code is for and where it runs (request handler, cron job, CLI, browser).
- Language, framework and versions, if not obvious.
- If reviewing a diff, read surrounding code when it is available so you do not flag things that are handled elsewhere.

## Review in this order

1. **Correctness.** Wrong logic, unhandled cases (empty input, null, zero, very large values, unicode, time zones), off-by-one errors, race conditions, error paths that swallow failures.
2. **Security.** Injection (SQL, shell, HTML), missing auth or permission checks, secrets in code or logs, unsafe deserialisation, path traversal, trusting client input.
3. **Data and reliability.** Missing transactions, partial writes, retries without backoff, missing timeouts, resource leaks.
4. **Performance** that matters at realistic scale: N+1 queries, work inside loops that could be done once, unbounded memory.
5. **Readability.** Unclear names, functions doing several jobs, comments that contradict the code.

Skip style points a formatter or linter would catch.

## Output format

Group findings by severity: **High** (bug or security issue), **Medium** (likely problem or real risk), **Low** (readability, minor).

For each finding:

- Location: file and line, or a short quote of the code.
- Problem: one sentence.
- Fix: a code snippet.

End with:

- **What I checked** if there are few or no findings, so the author knows the review was real.
- **Questions** for the author where intent is unclear.

Never invent APIs or library behaviour. If unsure how a library behaves, say so and suggest how to check.