How do I install the Code Review Checklist skill?

Run npx skillmds@latest add mine-fnl/code-review-checklist in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Code Review Checklist safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Code Review Checklist?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Code Review Checklist free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Code Review Checklist?

Mine-FNL (@mine-fnl) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Code Review Checklist by mine-fnl — Agent Skill

Name: Code Review Checklist
Author: Mine-FNL

Code Review Checklist

Use when reviewing a pull request, merge request, or diff for any nontrivial change. Applies when the user asks for "review this PR", "checklist for code review", or "what to look at when reviewing". Do not use for reviewing marketing copy, design mockups, or non-code artifacts; use a domain-appropriate review skill instead.

Mine-FNL Updated Sep 21, 2026

File contents

When to use

Use when the agent (human or AI) is asked to give a structured review of a change set rather than an opinion. A good review answers four questions in order, and stops when each is satisfied:

Is it correct? Does the change do what the PR description claims? Read the diff against the linked ticket before reading the surrounding code.
Is it tested? Are the new branches covered? Are the boundary conditions covered? Are failure modes covered?
Is it safe to ship? Does it roll back cleanly? Does it move any locks? Does it depend on data that may not exist yet?
Is it readable? Six months from now, will the next on-caller understand the change without a Slack thread?

Skim for the blockers first (correctness, safety), then re-read for the polish items (style, naming). Reviewers who start with style never reach correctness.

Examples

For example, a checklist applied to a 200-line PR that adds a new background job processor:

[✓] Ticket linked and matches the diff
[✓] New job is idempotent — re-running produces the same DB state
[ ] Backoff policy defined; no infinite-retry loops on poison messages
[✓] Cancellation handled — context propagation checked
[✓] Metric emitted on each terminal state (success, failure, retry)
[ ] Migration is expand-only; the contract migration is in a follow-up PR
[✓] Tests cover the happy path AND the poison-message path
[ ] Changelog entry present

A minimal review comment template:

**What**
One-sentence description of what the change does.

**Why**
Why the change is needed (link the ticket).

**Risk**
What could go wrong, and how the change is rolled back.

Pitfalls to avoid

Do not request stylistic changes that the linter should enforce; point the author at prettier, ruff, or whatever the repo uses, not at the line.
Do not approve a change because the tests pass; tests can be tautological. Read the assertions and ask whether they would fail on a regression.
Do not block on nits in a final-round review; ship the polish items in a follow-up PR so the primary change can land.
Do not merge a change with a console.log, a stray debugger, or a commented-out block left in the diff.
Do not skip the rollback section; every PR needs an answer to "if this breaks in prod at 03:00, what do you do?".

---name: code-review-checklistdescription: Use when reviewing a pull request, merge request, or diff for any nontrivial change. Applies when the user asks for "review this PR", "checklist for code review", or "what to look at when reviewing". Do not use for reviewing marketing copy, design mockups, or non-code artifacts; use a domain-appropriate review skill instead.---## When to useUse when the agent (human or AI) is asked to give a structured review of achange set rather than an opinion. A good review answers four questionsin order, and stops when each is satisfied:1. **Is it correct?** Does the change do what the PR description claims? Read the diff against the linked ticket before reading the surrounding code.2. **Is it tested?** Are the new branches covered? Are the boundary conditions covered? Are failure modes covered?3. **Is it safe to ship?** Does it roll back cleanly? Does it move any locks? Does it depend on data that may not exist yet?4. **Is it readable?** Six months from now, will the next on-caller understand the change without a Slack thread?Skim for the blockers first (correctness, safety), then re-read for thepolish items (style, naming). Reviewers who start with style never reachcorrectness.## ExamplesFor example, a checklist applied to a 200-line PR that adds a newbackground job processor:```text[✓] Ticket linked and matches the diff[✓] New job is idempotent — re-running produces the same DB state[ ] Backoff policy defined; no infinite-retry loops on poison messages[✓] Cancellation handled — context propagation checked[✓] Metric emitted on each terminal state (success, failure, retry)[ ] Migration is expand-only; the contract migration is in a follow-up PR[✓] Tests cover the happy path AND the poison-message path[ ] Changelog entry present```A minimal review comment template:```markdown**What**One-sentence description of what the change does.**Why**Why the change is needed (link the ticket).**Risk**What could go wrong, and how the change is rolled back.```## Pitfalls to avoid- Do not request stylistic changes that the linter should enforce; point the author at `prettier`, `ruff`, or whatever the repo uses, not at the line.- Do not approve a change because the tests pass; tests can be tautological. Read the assertions and ask whether they would fail on a regression.- Do not block on nits in a final-round review; ship the polish items in a follow-up PR so the primary change can land.- Do not merge a change with a `console.log`, a stray debugger, or a commented-out block left in the diff.- Do not skip the rollback section; every PR needs an answer to "if this breaks in prod at 03:00, what do you do?".

Frequently asked questions