Code Review Checklist

Goal

Produce a thorough, structured code review covering correctness, security vulnerabilities, and maintainability issues from a pull request diff.

Trigger

When a developer submits a pull request and needs a comprehensive review before merging.

Steps

1. 1

   Analyze the pull request diff below and identify the scope of changes — which files, modules, or systems are affected and what the PR is trying to accomplish: $pr_diff

   • □Diff is fully read and understood
   • □Purpose of the PR is clearly identified
2. 2

   Check for correctness: verify the logic is sound, edge cases are handled, error handling is present, and the code does what it claims. Flag any bugs, off-by-one errors, null dereferences, or incorrect assumptions.

   • □Logic and control flow verified
   • □Edge cases and error paths identified
   • □No obvious bugs or incorrect behavior
3. 3

   Audit the diff for security issues: look for injection vulnerabilities (SQL, XSS, command), hardcoded secrets or credentials, insecure deserialization, improper authentication/authorization checks, and unsafe use of external input.

   • □No hardcoded secrets or tokens
   • □All external inputs are validated or sanitized
   • □Auth and permission checks are correct
4. 4

   Evaluate maintainability: assess code readability, naming clarity, function/class size, duplication, test coverage, and whether the changes follow the existing patterns and conventions of the codebase.

   • □Code is readable and well-named
   • □No unnecessary duplication introduced
   • □Tests are present and meaningful
5. 5

   Compile all findings into a structured review report. Categorize each issue as Blocker, Major, or Minor. Include a short explanation and a suggested fix or improvement for each item. End with an overall recommendation: Approve, Request Changes, or Needs Discussion.

   • □All issues are categorized by severity
   • □Each issue includes a suggested fix
   • □Overall recommendation is clearly stated

Output format

Return a structured report with four sections: 1) PR Summary (1–3 sentences on scope and intent), 2) Correctness Issues, 3) Security Issues, 4) Maintainability Issues. Each issue entry should include: severity label (Blocker / Major / Minor), file and line reference if applicable, description of the problem, and a suggested fix. Close with a final recommendation line: Approve / Request Changes / Needs Discussion, with a one-sentence rationale.