Unslop Review
When to Use
Use this skill when you need 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...
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.
Limitations
- Use this skill only when the task clearly matches its upstream source and local project context.
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
Source: sickn33/agentic-awesome-skills → skills/unslop-review/SKILL.md
Also appears in: sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills/skills/unslop-review/SKILL.md, sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills-claude/skills/unslop-review/SKILL.md
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...4---5
6
7# Unslop Review
8## When to Use
9
10Use this skill when you need 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...
11
12
13## Purpose
14
15Rewrite 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.
16
17## Trigger
18
19`/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.
20
21## Format
22
23Default shape: `L<line>: <severity prefix> <observation>. <fix>.`
24
25Severity prefixes (optional but use them when severity matters):
26- `bug:` — code is broken or will break
27- `risk:` — works today, fragile tomorrow (perf, race, missing test)
28- `nit:` — style, naming, dead code, "while you're here"
29- `q:` — genuine question, not a hidden complaint
30
31Multi-file: `<file>:L<line>: <severity> <observation>. <fix>.`
32
33Range: `L88-140: ...` when the issue spans lines.
34
35## Rules
36
37### Drop
38
39- Throat-clearing: "I noticed that...", "It seems like...", "It looks like to me..."
40- Stacked hedging: "I was wondering if perhaps we might want to potentially..."
41- Polite-padding: "I would kindly suggest...", "just a small suggestion..."
42- Per-comment praise: "Nice work on this function but...", "Great pattern, however..."
43- Restating the diff: "Here on line 42 you have a function called `getUser` which returns..."
44- Bare opinion without a fix: "This is bad" with no suggestion
45
46### Keep
47
48- Exact line numbers and ranges
49- Identifiers in backticks: `findUser`, `req.body.id`
50- Concrete fix or concrete question
51- "Why" only when the fix isn't obvious
52
53### Tone
54
55Human, 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.
56
57### Auto-clarity (use full prose, not one-liners)
58
59- Security findings (CVE-class, auth, secrets)
60- Architecture disagreements that need a real discussion
61- Onboarding context for a new contributor
62- When the answer is genuinely "this is fine"
63
64In those cases use a short paragraph, then resume terse for the rest.
65
66## Examples
67
68### Bad → good
69
70- 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.`
71- Good: `L42: bug: \`findUser\` returns undefined when no match. Guard before \`user.email\` or early-return 404.`
72
73- Bad: `Great work on this implementation! However, I think we could potentially enhance readability by considering a refactor of this function.`
74- 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.`
75
76- Bad: `I noticed that there's no retry logic here which could be problematic.`
77- Good: `L23: risk: no retry on 429. Wrap the call in \`withBackoff(3)\` so we don't drop legitimate requests.`
78
79- Bad: `This implementation leverages a robust caching strategy.`
80- Good: (delete — empty praise. If the caching is genuinely interesting, explain why specifically.)
81
82### Approval
83
84If the change is solid and you have nothing concrete: `LGTM` on its own line. No boilerplate.
85
86## Boundaries
87
88- Comments only. No commits, no `git push`, no auto-approve, no linter runs.
89- Output is paste-ready: one comment per line, or a clearly separated list.
90- Severity must be honest. Don't downgrade a `bug` to a `nit` to soften the message.
91
92## Limitations
93
94- Use this skill only when the task clearly matches its upstream source and local project context.
95- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
96- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
97
98---
99
100**Source:** [`sickn33/agentic-awesome-skills`](https://github.com/sickn33/agentic-awesome-skills) → `skills/unslop-review/SKILL.md`
101
102**Also appears in:** `sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills/skills/unslop-review/SKILL.md`, `sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills-claude/skills/unslop-review/SKILL.md`
sickn33