Code Review Checklist

Goal

Produce a structured code review covering correctness, security vulnerabilities, and maintainability issues with actionable inline feedback.

Trigger

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

Steps

1. 1

   Analyze the pull request diff below and identify its purpose, scope, and the files/components changed: $pr_diff

   • □Diff is fully pasted and readable
   • □Changed files and functions are identified

   Analyze the pull request diff below and identify its purpose, scope, and the files/components changed:
   
   $pr_diff

2. 2

   Check for correctness issues: logic errors, off-by-one errors, unhandled edge cases, incorrect conditionals, broken error handling, and missing null/undefined checks.

   • □Edge cases and null checks reviewed
   • □Logic flow and conditionals verified
   • □Error handling paths checked
3. 3

   Audit the diff for security vulnerabilities: injection risks (SQL, XSS, command), insecure deserialization, hardcoded secrets, improper authentication/authorization checks, and unsafe use of user-supplied input.

   • □User input sanitization verified
   • □No hardcoded secrets or credentials
   • □Auth/authz logic reviewed
4. 4

   Evaluate maintainability: flag overly complex functions, poor naming, missing or misleading comments, duplicated logic, lack of test coverage, and violations of SOLID or DRY principles.

   • □Function complexity and naming assessed
   • □Code duplication identified
   • □Test coverage gaps flagged
5. 5

   Summarize all findings into a structured review report with three labeled sections — Correctness, Security, and Maintainability — each containing numbered issues with file/line references, severity (Critical / Major / Minor), and a concrete suggested fix.

   • □Every issue includes a severity rating
   • □Each issue has a specific suggested fix
   • □File and line references are included where possible
6. 6

   Provide an overall verdict: Approve, Request Changes, or Needs Discussion. Include a one-paragraph executive summary suitable for a non-technical stakeholder, and a prioritized list of the top 3 must-fix items before merging.

   • □Verdict is clearly stated
   • □Top 3 blockers are listed
   • □Executive summary is jargon-free

Output format

Structure the response with clearly labeled H2 sections: 'Summary', 'Correctness Issues', 'Security Issues', 'Maintainability Issues', 'Top 3 Must-Fix Items', and 'Overall Verdict'. Use numbered lists for issues. Each issue should follow the pattern: [Severity] File/line — Description — Suggested Fix.