---
name: code-review-rubric
description: How to produce a prioritized, actionable code review (severity, path:line, concrete fixes).
scenarios: code-review
---
# Code review rubric

Produce a review that an engineer can act on immediately.

## Output shape
1. **Summary** — 2–3 lines: overall health + the single most important thing to fix.
2. **Findings**, grouped by severity:
   - **Blocker** — correctness/security bug, data loss, or a crash path. Must fix before merge.
   - **Major** — likely bug, missing error handling, race, leak, or a design problem.
   - **Minor** — style, naming, small simplification, nit.
3. Each finding: `path:line — what's wrong — concrete fix`. Cite the actual code; reference real symbols.

## What to look for
- **Correctness**: edge cases, off-by-one, race conditions, resource leaks, missing/incorrect error paths, unhandled rejections.
- **Security**: authz/ownership checks, input validation, injection (SQL/command/path), secrets in code/logs, unsafe deserialization, SSRF.
- **Architecture**: module boundaries, coupling, data flow, error propagation, concurrency model, idempotency of side effects.
- **Performance**: hot paths, N+1 queries, unnecessary allocations/copies, blocking IO on the request path, missing caching/pooling.
- **Tests**: are the risky paths covered? Do tests assert behavior, not implementation?

## Discipline
- **Read before you judge.** Use `repo_tree` to map the repo, then `repo_read_file` for the files you assess. Never invent files, lines, or symbols.
- Prefer a few high-signal findings over an exhaustive list of nits.
- When delegating to specialist reviewers, give each a clear scope; merge their findings, de-duplicate, and resolve disagreements.