code-review-checklist
This skill generates a customized code review checklist tailored to the specific pull request's programming language, change type, and risk level. Use it when reviewing code or a pull request to receive language-specific correctness checks, change-type-appropriate validation steps, risk-scaled review depth guidance, and a structured approve or request-changes recommendation based on provided PR details, code diffs, and author context.
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/code-review-checklist && cp -r /tmp/code-review-checklist/plugins/pm-engineering/skills/code-review-checklist ~/.claude/skills/code-review-checklistSKILL.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] ### 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. --- ## 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]"
Design a 360-degree feedback survey or write a structured 360 feedback report. Use when asked to build a 360 feedback process, write 360 feedback for a colleague, design a feedback survey, or produce a feedback report. Produces either a complete survey instrument with rating scales and open-ended questions, or a structured narrative feedback report with themes, strengths, and development areas.
Decode a 401k or workplace retirement plan — the real cost of its funds, the match's fine print, vesting math, and the plan features worth using or avoiding. Use when someone asks 'is my 401k any good', 'decode my 401k plan', 'which funds should I look at', or 'what fees am I paying'. Produces a fee decode in dollars-over-time, match and vesting math, a fund-lineup triage by cost, and the questions for HR or the plan administrator.
Design statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide.
Analyse a finished A/B test and write the readout — the result, whether it's statistically and practically significant, what it means, and the ship/no-ship call. Use when asked to analyse experiment results, write an A/B test readout, interpret test data, or decide whether to ship a variant. Produces a clear verdict with the lift and confidence, segment cuts, the risks (peeking, novelty, sample), and a recommendation. Distinct from planning a test — this reads results.
Generate a WCAG 2.2 accessibility audit checklist and remediation suggestions for any UI or design. Use when asked to audit for accessibility, check WCAG compliance, review a design for a11y issues, or create an accessibility remediation plan. Produces a prioritised checklist with pass/fail assessments and specific fixes.
Plan a trip that actually works with a disability or access need — confirm real accessibility (not just 'accessible' labels), book the assistance in advance, plan for equipment and medication, and build in the contingencies for when access breaks down. Use when someone says 'plan an accessible trip', 'travelling with a wheelchair/disability', 'book assistance for my flight', or 'will this hotel actually work for me'. Produces an access-verified itinerary, an assistance-booking checklist, an equipment/medication plan, and contingency scripts. Verify specifics with providers.
Request a reasonable accommodation at work or in education — frame it around the barrier and the adjustment (not your diagnosis), cite the right process, and navigate the back-and-forth constructively. Use when someone says 'I need a workplace accommodation', 'request reasonable adjustments', 'ADA/Equality Act accommodation', or 'how do I ask for accommodations for my disability/condition'. Produces the request letter, a barriers-and-adjustments map, disclosure guidance, and a plan for the interactive process. Not legal advice — routes to the formal process and to advocacy where needed.
Build a structured account plan for any key customer or target account. Use when asked to create an account plan, key account strategy, strategic account review, or territory plan. Produces a complete account plan with relationship map, growth opportunities, risks, and 90-day action plan.