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.

Not quite this? Use code-review-guide when you want to carry out the review itself with senior judgement, not just a checklist.

Required Inputs

Work from what is given. If any of these is missing, still produce the complete output: fill each gap with a reasonable assumption marked (assumed, confirm) and list those assumptions at the end. Ask a question first only when the core subject itself is missing (there is nothing to write about).

• 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.

---

Deeper Materials

This skill ships with support files — use them when they are available:

• references/review-depth-calibration.md — Calibrating Review Depth: Not Every PR Deserves the Same Eyes. Apply it while producing the output; it carries the calibration and judgment calls the method summary above compresses.
• templates/review-record.md — a fill-in version of the deliverable with the quality gates inline. Offer it when the user wants to work the document themselves rather than have it generated.

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]"

Example Trigger Phrases

• "Review code."
• "Check a PR."
• "Review a pull request."
• "Generate a code review checklist."