Code Review

Review code like a senior engineer - thorough but practical. Focus on things that actually matter. Don't waste time on style nitpicks a linter should catch.

Review Checklist

Use this checklist to guide your review. Need examples of what to look for? Check out references/common-issues.md for code patterns.

Security (Critical)

• Input validation and sanitization

• SQL injection, XSS, command injection risks

• Auth checks in place and correct

• Sensitive data handling (passwords, tokens, PII)

• Dependency vulnerabilities

Bugs & Logic (Critical)

• Null/undefined handling

• Edge cases (empty arrays, null values, boundaries)

• Error handling in place

• Race conditions or concurrency issues

• State management issues

Performance (Important)

• Algorithm complexity (watch for O(n²) where O(n) exists)

• N+1 query problems

• Memory leaks (listeners, subscriptions, closures)

• Blocking operations that should be async

Testing (Important)

• Changes covered by tests

• Tests verify actual behavior

• Edge cases tested

• Error conditions tested

Code Quality

• Code is understandable

• No unnecessary complexity or clever code

• Duplication worth extracting

• Names match what they do

Architecture

• Fits existing patterns (or has good reason not to)

• No breaking changes without migration

• Avoids unnecessary coupling

Output Format

Structure your review like this (see references/review-template.md for detailed examples):

• Summary: One line verdict (Good to merge / Has issues / Needs work)

• Critical: Security, data loss, crashes - must fix before merge

• Important: Bugs, performance, missing tests - should fix

• Minor: Quality improvements - nice to have

• Questions: Things to clarify with the author

• Prevent This: Suggest tooling/config to catch these issues automatically in the future

• Positive Notes: Briefly acknowledge what's done well

Guidelines

• Be specific: file:line, what's wrong, why it matters, how to fix

• Skip style issues that linters catch

• Explain impact, not just "this is wrong"

• Consider trade-offs - sometimes simple is better than perfect

• Briefly note if something is done well, but keep it short

Suggesting Future Mitigations

Only suggest mitigations for recurring patterns or critical issues. Don't suggest tools for one-off mistakes. Focus on automatable checks, not process changes.

TypeScript configuration:

• Type safety issues (any , implicit types) → Suggest strict: true , noImplicitAny , strictNullChecks in tsconfig.json

• Missing null checks → Suggest strictNullChecks: true

Linting rules:

• Code quality patterns ESLint could catch → Suggest specific ESLint rules

• Framework-specific issues → Suggest framework ESLint plugins (react-hooks, vue, etc.)

• Formatting inconsistencies → Suggest Prettier in pre-commit hook

Pre-commit hooks:

• Secrets/credentials committed → Suggest trufflehog or git-secrets

• Test failures → Suggest running tests before commit

• Type errors → Suggest tsc --noEmit check

CI/CD checks:

• Security vulnerabilities → Suggest npm audit / dependency scanning

• Missing tests → Suggest coverage thresholds

• Build errors → Ensure build runs in CI

References

Need more guidance? Check these out:

• Review Template - What your review output should look like, with severity categories and example issues

• Common Issues - Quick reference of problems that come up often in reviews, with good/bad code examples