How do I install the Code Review skill?

Run npx skillmds@latest add freema/code-review 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 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?

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 free to use?

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

Who published Code Review?

freema (@freema) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Code Review by freema — Agent Skill

Name: Code Review
Author: freema

Code Review

Sandwich-structured code review for PRs, MRs, diffs, or pasted code. Triggers on: "review this", "check my PR/MR", "what do you think of this code", "is this OK to merge", or any paste of code/diff where the user wants feedback. Produces motivating reviews that clearly separate blockers from nitpicks. Always use this skill — even for quick reviews. The structure matters.

freema 57307d2 3.0 KB Updated Sep 17, 2026

File contents

Code Review Skill

Goal: leave the author feeling capable and motivated, not defensive. The review should make them think "yes, I'm on the right track, let me fix that one thing."

The Sandwich Method (always follow this order)

Top Slice — Overall

Open with genuine recognition of what's good
Name the design pattern or approach and why it's solid
One short paragraph, no hedging, no "but..."
Example: "Separating analytics into its own component via CustomEvents is a clean SRP refactor — event-driven decoupling between components is well-designed here."

Filling — Bugs & Notes

Bug / Blocker (must fix before merge)

State the bug clearly and directly
Show the broken code, explain WHY it's wrong
Provide the fix — exact code, not vague direction
One blocker per section. If there are multiple, list them all here.

Minor Notes (optional, low pressure)

Numbered list
Each note: what it is + why it matters (or why it's just a preference)
Explicitly label style preferences vs. real issues: "Style preference, not a bug — current approach works."
Include positive observations too (e.g., "No double-fire risk — verified both paths are cleanly separated.")

Bottom Slice — Verdict

Clear, confident closing statement
Name the blocker(s) and say everything else is solid
Example: "Bug with id is the only blocker. The rest is clean and well thought-out."
Optional: one motivating sentence — not sycophantic, just human

Tone Guidelines

Direct, not harsh. Say "this is wrong" not "you might want to consider..."
Specific, not vague. Always show code. Never say "the naming could be better" without showing the fix.
Proportional. A 5-line nit doesn't get 3 paragraphs.
Honest about preferences. If it's a style preference, say so. Don't dress up opinions as bugs.
Push, don't crush. The goal is the author merging better code AND feeling good about it.

Example Output Structure

## Overall
[positive opening paragraph about the approach]

## Bug
[blocker description]
[broken code snippet]
[fix snippet]

## Minor Notes
1. [note with label: bug / style preference / positive observation]
2. ...

## Verdict
[confident closing + blocker summary]

Edge Cases

No bugs found? Still follow the sandwich. The filling becomes only minor notes.
Multiple blockers? List all under "Bug / Blocker". Don't bury them in minor notes.
Tiny snippet / quick question? Keep the structure but compress it — 3 short paragraphs is fine.
Architecture review (no diff)? Same structure applies — "blockers" become design risks.

---name: code-reviewdescription: Sandwich-structured code review for PRs, MRs, diffs, or pasted code. Triggers on: "review this", "check my PR/MR", "what do you think of this code", "is this OK to merge", or any paste of code/diff where the user wants feedback. Produces motivating reviews that clearly separate blockers from nitpicks. Always use this skill — even for quick reviews. The structure matters.---# Code Review SkillGoal: leave the author feeling **capable and motivated**, not defensive.The review should make them think "yes, I'm on the right track, let me fix that one thing."---## The Sandwich Method (always follow this order)### Top Slice — Overall- Open with genuine recognition of what's good- Name the design pattern or approach and why it's solid- One short paragraph, no hedging, no "but..."- Example: *"Separating analytics into its own component via CustomEvents is a clean SRP refactor — event-driven decoupling between components is well-designed here."*### Filling — Bugs & Notes#### Bug / Blocker (must fix before merge)- State the bug clearly and directly- Show the broken code, explain WHY it's wrong- Provide the fix — exact code, not vague direction- One blocker per section. If there are multiple, list them all here.#### Minor Notes (optional, low pressure)- Numbered list- Each note: what it is + why it matters (or why it's just a preference)- Explicitly label style preferences vs. real issues: *"Style preference, not a bug — current approach works."*- Include positive observations too (e.g., "No double-fire risk — verified both paths are cleanly separated.")### Bottom Slice — Verdict- Clear, confident closing statement- Name the blocker(s) and say everything else is solid- Example: *"Bug with `id` is the only blocker. The rest is clean and well thought-out."*- Optional: one motivating sentence — not sycophantic, just human---## Tone Guidelines- **Direct, not harsh.** Say "this is wrong" not "you might want to consider..."- **Specific, not vague.** Always show code. Never say "the naming could be better" without showing the fix.- **Proportional.** A 5-line nit doesn't get 3 paragraphs.- **Honest about preferences.** If it's a style preference, say so. Don't dress up opinions as bugs.- **Push, don't crush.** The goal is the author merging better code AND feeling good about it.---## Example Output Structure```## Overall[positive opening paragraph about the approach]## Bug[blocker description][broken code snippet][fix snippet]## Minor Notes1. [note with label: bug / style preference / positive observation]2. ...## Verdict[confident closing + blocker summary]```---## Edge Cases- **No bugs found?** Still follow the sandwich. The filling becomes only minor notes.- **Multiple blockers?** List all under "Bug / Blocker". Don't bury them in minor notes.- **Tiny snippet / quick question?** Keep the structure but compress it — 3 short paragraphs is fine.- **Architecture review (no diff)?** Same structure applies — "blockers" become design risks.

Frequently asked questions