Code Review Checklist

Code Review Checklist

Systematic code review combining quality gates, security audit (OWASP Top 10), and parallel checks for comprehensive validation.

Review Scope

• Review ONLY changed files (check diff, not entire file)
• Check related commits
• Link to related PRs/issues

Automated Quality Checks (Run FIRST)

Before any manual review, run automated checks:

# Python
ruff check src/ --fix && black --check src/ && isort --check-only src/

# TypeScript/JavaScript
eslint src/ --fix && prettier --check src/

Block review if checks fail. Return NEEDS_REVISION with specific violations.

Review Checklist

Correctness

• Logic is correct and complete
• Edge cases handled
• Error handling appropriate
• Performance acceptable

Code Quality

• No duplication (DRY principle)
• Single responsibility functions
• Clear and descriptive naming
• Reasonable complexity (no god functions)
• Proper file sizes (<300 lines)

Testing

• Unit tests written
• Coverage ≥80%
• Integration tests for workflows
• Edge cases tested
• Error conditions tested

Security (OWASP Top 10)

• Input validation present
• No hardcoded secrets/credentials
• No XXE, CSRF, XSS vulnerabilities
• Authentication/authorization proper
• Sensitive data encrypted
• Rate limiting on sensitive endpoints
• Audit logging for security events

Documentation

• Public functions documented
• Comments explain WHY not WHAT
• README/guides accurate
• API documentation complete

Feedback Format

## Verdict: APPROVED | NEEDS_REVISION | FAILED

### Issues
- CRITICAL: X | HIGH: Y | MEDIUM: Z | LOW: W

### Details
- [CRITICAL] file.py:42 — SQL injection risk, use parameterized queries
- [HIGH] component.tsx:15 — Missing input validation
- [MEDIUM] test_utils.py:8 — Edge case not covered

### 🔍 Human Review Focus
1. [Item AI cannot fully validate — e.g., business logic correctness]
2. [Item 2 — e.g., UX flow matches requirements]

Parallel Review Pattern

For comprehensive reviews, run 5 checks simultaneously:

Severity Definitions

SOLID Principles Check

• Single Responsibility: Each class/function does one thing
• Open/Closed: Extensible without modification
• Liskov Substitution: Subtypes behave like base types
• Interface Segregation: Small, focused interfaces
• Dependency Inversion: Depend on abstractions, not concretions

Anti-Patterns

• ❌ Reviewing entire file instead of diff
• ❌ Approving without running tests
• ❌ Ignoring security implications
• ❌ Vague feedback ("looks good", "needs work")
• ❌ Nitpicking style over substance

Source: ils15/pantheon — distributed by TomeVault.