| name | review |
| description | General-purpose code review checklist. Use when reviewing any code change without a narrower specialization. Complements security-review, pr-review (multi-perspective), and the other review skills — pull this when you need the standard correctness/quality rubric without a specific angle.
|
| allowed-tools | ["Bash","Read","Glob","Grep"] |
Code review procedure
A general-purpose review rubric for any code change. Use as the
"correctness" specialist dimension of a multi-perspective review, or as
a standalone checklist when reviewing a diff without a specialization.
Scope
Review ONLY the assigned diff. Cross-module concerns go to architecture;
security-sensitive code goes to security-review.
Checklist summary (9 sections)
- Correctness — logic, control flow, off-by-one, error handling, invariants, concurrency, numeric
- API contract — backward compatibility, type annotations, error types, return value shape
- Tests — coverage of new paths, edge cases, mock fidelity, flaky risk
- Readability & maintainability — names, function length, nesting, comments, dead code
- Consistency — naming convention, error handling pattern, import ordering, abstraction level
- Docs & changelog — public API changes, behavioral changes, new config options
- Dependencies — necessity, maintenance, license, version constraints, lockfile
- Performance (light-touch) — obvious O(n²) regressions, hot-path allocations, N+1 queries
- Over/under-engineering — premature abstraction, speculative flexibility, too-simple cases
See checklist.md for the full detailed checklist with all sub-items.
Output format
Findings table per finding:
| Severity | Location | Issue | Suggested fix | Confidence |
|---|
| MEDIUM | src/module.py:87 | Off-by-one in range(len(xs)) | Use enumerate(xs) | High |
Verdict line at top: APPROVE | APPROVE-WITH-FIXES | REQUEST CHANGES.
Cite file:line for every finding.
Severity calibration
CRITICAL — will break production on mergeHIGH — correctness bug affecting real use casesMEDIUM — edge case bug, significant maintainability issueLOW — style, naming, minor refactorINFO — future consideration, not blocking
Ground rules
- Describe the bug, propose a fix.
- Don't invent requirements.
- Rank severity honestly.
- Flag assumptions you can't verify from the diff.
- Review against committed HEAD of the PR branch.
