Generate a tailored code review checklist for any pull request based on the language, type of change, and risk level. Use when asked to review code, check a PR, review a pull request, or generate a code review checklist. Produces a focused checklist with language-specific checks, risk-level-appropriate depth, and a clear approve/request-changes recommendation.
SKILL.md
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]
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]"
