How do I install the Quick Review skill?

Run npx skillmds@latest add shreyt19/quick-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 Quick 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 Quick 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 Quick Review free to use?

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

Who published Quick Review?

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

Quick Review by shreyt19 — Agent Skill

Name: Quick Review
Author: shreyT19

Quick Review

Fast plain-English sanity check of a git diff. Read every hunk, spot only obvious breakage (broken imports, dangling refs, signature mismatches, syntax), summarize what changed and why in ~30 seconds. Does NOT run tests, hunt smells, or pull spec. Use when user asks for "quick review", "glance at this", "does this look ok", or a fast diff explanation before committing or requesting deeper review. For thorough review, use `medium-review` or `code-review` (advanced) instead.

shreyT19 b775353 2.8 KB Updated Sep 17, 2026

File contents

Quick review

Fastest of three review tiers. Standalone — does not invoke other skills.

When to use

"quick review", "glance over this", "does this look ok", "eyeball this diff"
Pre-commit sanity check on WIP
User wants to know what changed in plain English, not exhaustive quality audit

When NOT to use

Full PR / branch merge — use medium-review or code-review
Cross-file architectural changes — use code-review
Verifying correctness with tests / typecheck — use principle-prove-it-works

Process

1. Get the diff

Default: git diff (unstaged + staged)
If user names a ref: git diff <ref>...HEAD
Also grab: git log <ref>..HEAD --oneline if reviewing a branch
Empty diff → say "no changes" and stop

2. Read every hunk

Do not sample. All changed hunks in every changed file. If diff is very large (> 500 lines), summarize by file grouping and warn: "diff is large — medium-review or code-review will do better here."

3. Spot obvious breakage only

Surface only things a compiler / linter would flag if the tool ran:

Import removed but still referenced elsewhere in same file
Function / method signature changed but callers untouched in same file
Undefined variable or identifier typo introduced
Obvious syntax error (missing paren, unclosed string, bad indent in Python)
Type mismatch visible from local context

Do NOT speculate about runtime bugs. Do NOT hunt for code smells. Do NOT judge design. Those are for medium-review and code-review.

4. Summarize in plain English

Fixed structure:

What changed — 2 to 4 bullets. Named files. Verb-first ("Added X", "Renamed Y", "Removed Z"). One line each.
Why (guess) — one line if intent is obvious from context. Skip if unclear. Never invent motivation.
Breakage risks — 0 to 3 bullets from step 3. If none: "none spotted".
Skipped — one line if you skipped anything large (generated file, binary, huge migration).

5. Do not run tests or typecheck

Read-only. If user wants execution proof, hand off to principle-prove-it-works after review.

Output style

Terse. Skip headings for tiny diffs. Answer fits on one screen.
Skip praise. Skip disclaimers. Skip "let me know if you need more".
No AI voice — apply unslop conventions if writing more than a few lines.

---name: quick-reviewdescription: Fast plain-English sanity check of a git diff. Read every hunk, spot only obvious breakage (broken imports, dangling refs, signature mismatches, syntax), summarize what changed and why in ~30 seconds. Does NOT run tests, hunt smells, or pull spec. Use when user asks for "quick review", "glance at this", "does this look ok", or a fast diff explanation before committing or requesting deeper review. For thorough review, use `medium-review` or `code-review` (advanced) instead.---# Quick reviewFastest of three review tiers. Standalone — does not invoke other skills.## When to use- "quick review", "glance over this", "does this look ok", "eyeball this diff"- Pre-commit sanity check on WIP- User wants to know *what* changed in plain English, not exhaustive quality audit## When NOT to use- Full PR / branch merge — use `medium-review` or `code-review`- Cross-file architectural changes — use `code-review`- Verifying correctness with tests / typecheck — use `principle-prove-it-works`## Process### 1. Get the diff- Default: `git diff` (unstaged + staged)- If user names a ref: `git diff <ref>...HEAD`- Also grab: `git log <ref>..HEAD --oneline` if reviewing a branch- Empty diff → say "no changes" and stop### 2. Read every hunkDo not sample. All changed hunks in every changed file. If diff is very large (> 500 lines), summarize by file grouping and warn: "diff is large — `medium-review` or `code-review` will do better here."### 3. Spot obvious breakage onlySurface only things a compiler / linter would flag if the tool ran:- Import removed but still referenced elsewhere in same file- Function / method signature changed but callers untouched in same file- Undefined variable or identifier typo introduced- Obvious syntax error (missing paren, unclosed string, bad indent in Python)- Type mismatch visible from local contextDo NOT speculate about runtime bugs. Do NOT hunt for code smells. Do NOT judge design. Those are for `medium-review` and `code-review`.### 4. Summarize in plain EnglishFixed structure:- **What changed** — 2 to 4 bullets. Named files. Verb-first ("Added X", "Renamed Y", "Removed Z"). One line each.- **Why (guess)** — one line if intent is obvious from context. Skip if unclear. Never invent motivation.- **Breakage risks** — 0 to 3 bullets from step 3. If none: "none spotted".- **Skipped** — one line if you skipped anything large (generated file, binary, huge migration).### 5. Do not run tests or typecheckRead-only. If user wants execution proof, hand off to `principle-prove-it-works` after review.## Output style- Terse. Skip headings for tiny diffs. Answer fits on one screen.- Skip praise. Skip disclaimers. Skip "let me know if you need more".- No AI voice — apply `unslop` conventions if writing more than a few lines.

Frequently asked questions