Code review

Skill freema/ai-skills/skills/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.From its SKILL.md

Install

npx -y skills add freema/ai-skills --skill code-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.0 KB, as published. Nobody here has run it

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.