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

- Skill: `shreyt19/quick-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add shreyt19/quick-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shreyt19/quick-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: shreyT19 (https://skillmd.com/u/shreyt19)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/shreyt19/quick-review

---


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