Code Review ChecklistCAUTION

1255 professional Agent Skills for Claude, ChatGPT, Gemini, Cursor & Codex — PRDs, postmortems, leases, medical bills, layoffs, go-bags, new countries. Plain markdown, MIT, in Anthropic's plugin directory. Plus a typed decision layer: which skill, is it safe, ship or slip. Free in-browser or npx pm-

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

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

> **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 st

CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (5)

templates/pm-discovery-agent/skills/assumption-mapper/SKILL.md

templates/pm-discovery-agent/skills/discovery-interview-guide/SKILL.md

templates/pm-discovery-agent/skills/job-story-mapper/SKILL.md

templates/pm-discovery-agent/skills/user-interview-synthesis/SKILL.md

templates/pm-launch-agent/skills/content-calendar/SKILL.md

Gates applied: no_behavioural_pass.