| name | code-review-checklist |
| description | 📋 Systematic code review checklists covering correctness, security, design, performance, and maintainability. Activate for any PR review, self-review, quality assessment, or when establishing review standards for a team. |
Code Review Checklist
Structured code review methodology that catches bugs, security issues, and design problems systematically rather than by intuition.
Review Priority Order
Review in this order -- earlier items block later ones:
1. Correctness
- Does the code do what it claims to do?
- Are edge cases handled (empty input, null, overflow, concurrent access)?
- Do error paths return sensible results or propagate correctly?
- Are there off-by-one errors in loops or slices?
2. Security
- Is user input validated before use?
- Are SQL queries parameterized (no string concatenation)?
- Are secrets hardcoded anywhere?
- Are auth/authz checks in place for protected operations?
- Could this introduce XSS, CSRF, or injection vulnerabilities?
3. Design
- Does this follow existing patterns in the codebase?
- Is the abstraction level right (not too generic, not too specific)?
- Are responsibilities clearly separated?
- Would a new team member understand this code?
4. Performance
- Are there N+1 query patterns?
- Are expensive operations inside loops?
- Is there unnecessary memory allocation?
- Could this cause timeouts under load?
5. Maintainability
- Are names descriptive and consistent with the codebase?
- Is the code testable (dependencies injectable, side effects isolated)?
- Are there sufficient tests for the changed behavior?
- Is the commit message clear about what and why?
Review Comments Guide
Good Review Comments
- Explain why something is a problem, not just that it is
- Suggest a specific alternative when possible
- Distinguish between must fix (blocking) and nit (suggestion)
- Ask questions when you don't understand intent ("Is this intentional?")
Comment Prefixes
| Prefix | Meaning |
|---|
blocker: | Must fix before merge |
concern: | Potential issue, needs discussion |
nit: | Style/preference, non-blocking |
question: | Need clarification to continue review |
praise: | Something done well (important for morale) |
Quick Checklist
### Correctness
- [ ] Logic handles happy path correctly
- [ ] Edge cases covered (empty, null, boundary values)
- [ ] Error handling is appropriate (not swallowed, not over-broad)
### Security
- [ ] No hardcoded secrets or credentials
- [ ] User input validated and sanitized
- [ ] Auth checks present on protected paths
- [ ] No SQL injection vectors
### Design
- [ ] Follows existing codebase patterns
- [ ] Reasonable abstraction level
- [ ] No unnecessary complexity added
### Tests
- [ ] New behavior has test coverage
- [ ] Tests verify behavior, not implementation
- [ ] Edge cases tested
### Operations
- [ ] No breaking changes without migration path
- [ ] Logging sufficient for debugging
- [ ] Performance impact considered
AI/LLM-Specific Review Patterns
When reviewing code that integrates AI/LLM services:
Anti-Patterns in Code Review
- Bikeshedding on style while missing logic bugs
- Reviewing only the diff without understanding the surrounding code
- Approving without actually reading the changes
- Blocking on personal preference when the code is correct
- Reviewing 1000+ line PRs in one sitting (request the author split it)
