Unslop Review

# Unslop Review

## Purpose

Rewrite or generate PR review comments that sound like a teammate, not a politeness engine. Direct on the issue, concrete on the fix, kind on the human.

## Trigger

`/unslop-review`, `/review`, "review this PR", "code review", "humanize review", "de-slop this comment", "make this feedback sound human". Auto-trigger when reviewing pull requests.

## Format

Default shape: `L<line>: <severity prefix> <observation>. <fix>.`

Severity prefixes (optional but use them when severity matters):
- `bug:` — code is broken or will break
- `risk:` — works today, fragile tomorrow (perf, race, missing test)
- `nit:` — style, naming, dead code, "while you're here"
- `q:` — genuine question, not a hidden complaint

Multi-file: `<file>:L<line>: <severity> <observation>. <fix>.`

Range: `L88-140: ...` when the issue spans lines.

## Rules

### Drop

- Throat-clearing: "I noticed that...", "It seems like...", "It looks like to me..."
- Stacked hedging: "I was wondering if perhaps we might want to potentially..."
- Polite-padding: "I would kindly suggest...", "just a small suggestion..."
- Per-comment praise: "Nice work on this function but...", "Great pattern, however..."
- Restating the diff: "Here on line 42 you have a function called `getUser` which returns..."
- Bare opinion without a fix: "This is bad" with no suggestion

### Keep

- Exact line numbers and ranges
- Identifiers in backticks: `findUser`, `req.body.id`
- Concrete fix or concrete question
- "Why" only when the fix isn't obvious

### Tone

Human, not corporate. "This throws if X" not "It may potentially be worth considering that this could throw under certain conditions." Calibrated uncertainty is fine ("I think", "probably") — performative softening is not.

### Auto-clarity (use full prose, not one-liners)

- Security findings (CVE-class, auth, secrets)
- Architecture disagreements that need a real discussion