code-review-checklist
GitHub根据语言、变更类型和风险级别，为PR生成定制化的代码审查清单。支持多语言检查项、变更专项验证及风险评估，提供审查深度建议与最终决策推荐。
Trigger Scenarios
Install
npx skills add mohitagw15856/pm-claude-skills --skill code-review-checklist -g -y
SKILL.md
Frontmatter
{
"name": "code-review-checklist",
"description": "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."
}
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
anyin 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]"
Version History
- 54fad50 Current 2026-07-19 12:55
- a38bc30 2026-07-05 11:17
