code-review

name	code-review
description	Reviews code changes for quality, correctness, style, and potential issues.

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.