quick-reviewlisted

# 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