code-review-checklist

Code Review Checklist Skill

Produces a tailored code review checklist for a specific pull request — scaled to the language, type of change, and risk level. Not a generic template.

Required Inputs

Ask the user for these if not provided:

• Language and framework (e.g. TypeScript + React / Python + FastAPI / Go)
• Type of change (feature / bug fix / refactor / dependency upgrade / security patch / performance)
• Risk level (low / medium / high / critical)
• PR description (paste the description or link to the PR)
• Code or diff (optional — paste key changed files or a git diff; significantly improves checklist specificity)
• Author context (new starter / experienced / external contributor)

Output Format

---

Code Review: [PR Title or Reference]

1. PR Overview

Scope assessment: [Small / Medium / Large / Too large — should be split]

Recommended review depth: [Skim / Standard / Deep dive]

Estimated review time: [e.g. 20–30 min — use 5 min per 50 lines of diff as a rough guide]

2. Correctness Checks

Language-specific correctness checks — choose based on the language stated:

For TypeScript/JavaScript:

• Type definitions match actual usage
• No implicit any in non-test code
• Async/await used consistently; no unhandled promises
• Null/undefined handling is explicit

For Python:

• Type hints present on public functions
• Exception handling is specific (no bare except)
• Resources are closed (context managers, with blocks)

For Go:

• Errors are handled or explicitly ignored with a comment
• Context propagation is correct
• Goroutine lifetimes are bounded

[Include only the section matching the stated language]

3. Change-Type-Specific Checks

For bug fixes:

• A test exists that would have caught this bug
• The fix addresses root cause, not symptom
• Related code paths checked for the same issue

For features:

• Acceptance criteria met
• Edge cases handled (empty, large, concurrent)
• Error paths tested, not just happy path
• Telemetry/logging added for debugging

For refactors:

• Behaviour unchanged (tests still pass)
• No scope creep — refactor only
• Complexity reduced, not just moved

For dependency upgrades:

• Breaking changes reviewed
• Security advisories checked
• License compatibility verified

[Include only the section matching the stated change type]

4. Risk-Appropriate Checks

Low risk: basic correctness, style conventions, test coverage

Medium risk: above + rollback plan, monitoring updates, performance considerations

High risk: above + security implications, data migration safety, feature flag/gradual rollout

Critical risk: above + staging validation plan, incident response plan, post-deploy verification checklist

5. Testing Adequacy

• Unit tests cover new logic
• Integration tests cover the contract changes
• Edge cases tested
• Failure modes tested
• Performance tests if performance-sensitive

6. Review Decision Framework

Approve if: [2-3 specific conditions based on this PR]

Request changes if: [Specific blockers]

Comment (non-blocking) if: [Items worth discussing but not blocking merge]

7. Common Pitfalls for This Change Type

Based on the change type and language, flag 2-3 things reviewers typically miss for this combination.

---

Scoring Rubric (0–40)

Score any output of this skill before handing it over; 32+ is ship-quality.

| Dimension | 0 | 5 | 10 |

|---|---|---|---|

| Language specificity | Checks could apply to any language — a swapped-in language name would change nothing | Correct language block chosen, but checks restate the template rather than this PR's constructs | Every correctness check names a construct actually in the diff (goroutines, promise chains, context managers) |

| Risk-depth calibration | Same depth regardless of stated risk level | Depth roughly scales, but high-risk extras (rollback plan, staged rollout, monitoring) are missing or token | Depth matches the stated risk exactly and the review-time estimate follows the diff size guide |

| Decision-framework sharpness | "Approve if it looks good" — no named conditions | Blockers listed but untestable; a reviewer can't tell when they're satisfied | Every approve/block/comment condition is checkable against a specific test, flag, metric, or artifact |

| Pitfall specificity | Pitfalls absent or generic ("watch for bugs") | Pitfalls match the language or the change type, but not the combination | 2–3 pitfalls that only make sense for this exact language + change-type combination |

Quality Checks

• [ ] Checklist is tailored to the stated language (not generic)
• [ ] Change-type-specific section is included
• [ ] Risk-appropriate depth matches stated risk level
• [ ] Decision framework includes at least one named blocking condition and one named non-blocking comment condition
• [ ] Common pitfalls are specific to the stated language + change-type combo (not generic advice like "watch out for bugs")

Anti-Patterns

• [ ] Do not generate a generic checklist that ignores the stated language — a Python checklist and a Go checklist have fundamentally different correctness concerns
• [ ] Do not treat "looks fine" as a valid review outcome — the checklist exists to surface specific concerns, not validate a superficial read
• [ ] Do not scope a "high risk" review the same as a "low risk" review — depth must scale with the stated risk level
• [ ] Do not flag every stylistic preference as a blocking issue — distinguish between blocking correctness issues and non-blocking comments
• [ ] Do not skip the "common pitfalls" section for the stated language and change-type combination — this is where the most valuable knowledge lives

Usage Examples

• "Generate a code review checklist for [PR description]"
• "What should I check in this pull request?"
• "Give me a code review checklist for a [language] [change type]"
• "Review checklist for a high-risk PR in [language]"