Code review checklist
A severity-ranked review checklist for humans and AI reviewers covering correctness, security, data, performance, tests and maintainability.
Fill in your details
Values are inserted into every prompt below. Nothing you type leaves your browser.
3 field(s) left — unfilled variables stay as {{placeholders}}.
1Correctness and data
☐ Does the change do what the PR description says, and nothing else? ☐ Edge cases: empty, null, very large, duplicate, concurrent, unicode, time zones. ☐ Error handling: failures are surfaced, not swallowed; retries are idempotent. ☐ Database: migrations are reversible or have a rollback plan; no unbounded queries; indexes for new filters. ☐ Backwards compatibility of APIs, events and stored data.
2Security
☐ Input validated at trust boundaries. ☐ Authorisation checked for every new endpoint or action, not just authentication. ☐ No secrets in code, logs or error messages. ☐ Queries parameterised; output encoded (XSS). ☐ File paths, URLs and redirects can't be controlled to reach unintended targets. ☐ New dependencies are maintained and appropriately licensed.
3Performance, tests and maintainability
☐ No N+1 queries or work inside hot loops that could be hoisted. ☐ Tests cover the behaviour change, including at least one failure case; tests fail without the change. ☐ Names explain intent; no dead code or commented-out blocks. ☐ Logging and metrics adequate to debug this in production. ☐ Docs or changelog updated if behaviour changed.
4AI-assisted review pass
Paste the diff (or let your coding agent read the branch). Treat findings as suggestions to verify; ask the reviewer to point at exact lines.
Review this change as a senior engineer. Context: {{change_context}} Areas I'm most worried about: {{risk_areas}} Diff: {{diff}} Report findings grouped by severity: Blocker (bug, security issue or data loss), Should fix, Nit. For each: file and line, what's wrong, why it matters, and a concrete fix. Check correctness and edge cases, security (authorisation, input validation, secrets, injection), data and migrations, performance, and whether tests actually cover the change. Do not comment on formatting that a linter would catch. If you are not sure something is a bug, say so and explain what would confirm it. End with: the single most important thing to fix, and whether you would approve.
Example input
Diff adding DELETE /api/admin/projects?ids=... in a multi-tenant app.
Example output
Blocker — api/admin/projects.ts:42 The query deletes by id only: where: { id: { in: ids } }. An admin from tenant A can delete tenant B's projects by passing their IDs. Fix: add tenantId: session.tenantId to the where clause and a test that cross-tenant IDs are ignored. Should fix — api/admin/projects.ts:30 No upper bound on ids length; a request with 100k IDs will build a huge query. Cap at, say, 500 and return 400 above it. Most important: the tenant scoping. Would not approve yet.
Troubleshooting
- Too many nits: say 'Only Blockers and Should fix' and set a maximum of 10 findings.
- Reviewer lacks context: include the files the diff calls into, or let an agent read the repository.
Known limitations
- AI reviewers miss issues and sometimes report false positives; a human must own the approval.
- Don't paste proprietary code into tools your organisation hasn't approved.