--- name: unslop-review description: > 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. --- # 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: . .` 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: `:L: . .` 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.