Code review

Code Review

Review code changes for quality, correctness, style, and potential issues. Provide clear, actionable feedback that helps the author improve their code.

Inputs

• Target: A diff, pull request, set of changed files, or specific code selection
• Context (optional): Project coding standards, language-specific conventions, or reference documents to apply during review

Steps

1. Identify the scope — Determine which files and changes are under review. If reviewing a PR or diff, read all changed files. If reviewing a selection, focus on the highlighted code and its immediate context.

2. Understand intent — Before critiquing, understand what the code is trying to accomplish. Read commit messages, PR descriptions, or surrounding code for context.

3. Review for correctness — Check for:

   • Logic errors and off-by-one mistakes
   • Unhandled edge cases and error conditions
   • Race conditions or concurrency issues
   • Incorrect assumptions about inputs or state

4. Review for security — Check for:

   • Injection vulnerabilities (SQL, XSS, command injection)
   • Improper input validation at system boundaries
   • Hardcoded secrets or credentials
   • Insecure defaults or configurations

5. Review for quality — Check for:

   • Code clarity and readability
   • Unnecessary complexity or over-engineering
   • Duplicated logic that should be consolidated
   • Naming that accurately describes purpose
   • Consistent style with the surrounding codebase

6. Review for performance — Check for:

   • Unnecessary allocations or computations in hot paths
   • N+1 query patterns or unbounded data fetching
   • Missing indexes or inefficient data structures
   • Resource leaks (connections, file handles, memory)

7. Review for maintainability — Check for:

   • Breaking changes to public APIs
   • Missing or outdated tests for changed behavior
   • Tight coupling that will make future changes harder
   • Dead code or unused imports introduced by the change

Output

Provide a structured review with the following sections:

Summary

A 1-3 sentence overview of the changes and overall assessment (approve, request changes, or comment).

Issues

List each issue found, categorized by severity:

• Critical — Must fix before merge. Bugs, security vulnerabilities, data loss risks.
• Important — Should fix before merge. Significant quality or maintainability concerns.
• Suggestion — Optional improvement. Style preferences, minor optimizations, alternative approaches.

For each issue, include:

• The specific file and line reference
• A clear description of the problem
• A concrete suggestion for how to fix it

Positive Feedback

Call out things done well — good patterns, clean abstractions, thorough error handling. Positive reinforcement is part of a constructive review.

Guidelines

• Be specific. "This could be better" is not actionable. "This loop allocates a new array on each iteration — consider pre-allocating" is.
• Be respectful. Review the code, not the person.
• Prioritize. Focus on what matters most. Don't bury critical issues under a pile of nitpicks.
• Respect existing patterns. If the codebase uses a specific convention, follow it — even if you prefer a different one.
• Distinguish opinion from fact. Prefix subjective suggestions with "Consider" or "Optionally" to distinguish them from objective issues.