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 breakrisk: — 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
- Onboarding context for a new contributor
- When the answer is genuinely "this is fine"
In those cases use a short paragraph, then resume terse for the rest.
Examples
Bad → good
Bad: I would kindly suggest that we might want to potentially consider adding a null check here as it could maybe lead to issues in some scenarios.
Good: L42: bug: \findUser` returns undefined when no match. Guard before `user.email` or early-return 404.`
Bad: Great work on this implementation! However, I think we could potentially enhance readability by considering a refactor of this function.
Good: L88-140: nit: this function does validation, I/O, and mapping. Splitting them would make the happy path easier to follow. Happy to pair on a cut if helpful.
Bad: I noticed that there's no retry logic here which could be problematic.
Good: L23: risk: no retry on 429. Wrap the call in \withBackoff(3)` so we don't drop legitimate requests.`
Bad: This implementation leverages a robust caching strategy.
Good: (delete — empty praise. If the caching is genuinely interesting, explain why specifically.)
Approval
If the change is solid and you have nothing concrete: LGTM on its own line. No boilerplate.
Boundaries
- Comments only. No commits, no
git push, no auto-approve, no linter runs.
- Output is paste-ready: one comment per line, or a clearly separated list.
- Severity must be honest. Don't downgrade a
bug to a nit to soften the message.
1---2name: unslop-review3description: Rewrites code review comments so they read like a human teammate wrote them. Cuts corporate-AI throat-clearing ("I noticed...", "I was wondering if perhaps...", "It might be worth considering..."). Each comment is direct: location, the issue, a concrete fix. Use when user says "humanize review", "de-slop PR comment", "make this feedback sound human", "review this PR", "code review", "/review", "/unslop-review". Auto-triggers when reviewing PRs.4---56# Unslop Review78## Purpose910Rewrite 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.1112## Trigger1314`/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.1516## Format1718Default shape: `L<line>: <severity prefix> <observation>. <fix>.`1920Severity prefixes (optional but use them when severity matters):21- `bug:` — code is broken or will break22- `risk:` — works today, fragile tomorrow (perf, race, missing test)23- `nit:` — style, naming, dead code, "while you're here"24- `q:` — genuine question, not a hidden complaint2526Multi-file: `<file>:L<line>: <severity> <observation>. <fix>.`2728Range: `L88-140: ...` when the issue spans lines.2930## Rules3132### Drop3334- Throat-clearing: "I noticed that...", "It seems like...", "It looks like to me..."35- Stacked hedging: "I was wondering if perhaps we might want to potentially..."36- Polite-padding: "I would kindly suggest...", "just a small suggestion..."37- Per-comment praise: "Nice work on this function but...", "Great pattern, however..."38- Restating the diff: "Here on line 42 you have a function called `getUser` which returns..."39- Bare opinion without a fix: "This is bad" with no suggestion4041### Keep4243- Exact line numbers and ranges44- Identifiers in backticks: `findUser`, `req.body.id`45- Concrete fix or concrete question46- "Why" only when the fix isn't obvious4748### Tone4950Human, 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.5152### Auto-clarity (use full prose, not one-liners)5354- Security findings (CVE-class, auth, secrets)55- Architecture disagreements that need a real discussion56- Onboarding context for a new contributor57- When the answer is genuinely "this is fine"5859In those cases use a short paragraph, then resume terse for the rest.6061## Examples6263### Bad → good6465- Bad: `I would kindly suggest that we might want to potentially consider adding a null check here as it could maybe lead to issues in some scenarios.`66- Good: `L42: bug: \`findUser\` returns undefined when no match. Guard before \`user.email\` or early-return 404.`6768- Bad: `Great work on this implementation! However, I think we could potentially enhance readability by considering a refactor of this function.`69- Good: `L88-140: nit: this function does validation, I/O, and mapping. Splitting them would make the happy path easier to follow. Happy to pair on a cut if helpful.`7071- Bad: `I noticed that there's no retry logic here which could be problematic.`72- Good: `L23: risk: no retry on 429. Wrap the call in \`withBackoff(3)\` so we don't drop legitimate requests.`7374- Bad: `This implementation leverages a robust caching strategy.`75- Good: (delete — empty praise. If the caching is genuinely interesting, explain why specifically.)7677### Approval7879If the change is solid and you have nothing concrete: `LGTM` on its own line. No boilerplate.8081## Boundaries8283- Comments only. No commits, no `git push`, no auto-approve, no linter runs.84- Output is paste-ready: one comment per line, or a clearly separated list.85- Severity must be honest. Don't downgrade a `bug` to a `nit` to soften the message.
ConcertoNotes