# unslop-review

Rewrites pull request review comments to remove AI throat-clearing and polite fluff. Keeps feedback direct with line numbers and concrete fixes.

- skill · `type=skill` · Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, OpenCode · ★ 164
- Author: MohamedAbdallah-14
- License: MIT · policy=mirror · the beginning of the file is at the end of this page
- Source: https://github.com/MohamedAbdallah-14/unslop/tree/HEAD/skills/unslop-review/SKILL.md
- Updated: 2026-10-19
- HTML: https://affpapa.org/en/nevibecode/skills/unslop-review

## What it does

This skill strips corporate fluff and artificial politeness from code reviews. It cuts opener phrases like "I noticed that..." along with empty praise before critique. Every comment gets straight to the point.

The standard output follows `L<line>: <severity prefix> <observation>. <fix>.` Optional prefixes flag severity: `bug:` marks broken logic, while `risk:` flags fragile code. Minor style tweaks get `nit:`, and genuine inquiries use `q:`. Multi-line issues use range syntax like `L88-140:`. When a pull request needs no changes, the skill outputs a plain `LGTM`.

Detailed explanations are reserved for security vulnerabilities and architectural debates. The tool focuses strictly on drafting comments. It will not commit files or run linters.

## Install

### Claude Code (native platform)

1. **Skills CLI (Vercel)**
```bash
npx skills add MohamedAbdallah-14/unslop --skill unslop-review -a claude-code
```

2. **Manually: put the files in place**
- File: `~/.claude/skills/unslop-review/SKILL.md` — Copy the whole skill folder; for one project use .claude/skills/unslop-review/

### Codex

1. **Skills CLI (Vercel)**
```bash
npx skills add MohamedAbdallah-14/unslop --skill unslop-review -a codex
```

2. **Manually: put the files in place**
- File: `.agents/skills/unslop-review/SKILL.md` — For all projects use ~/.agents/skills/

### Cursor

1. **Skills CLI (Vercel)**
```bash
npx skills add MohamedAbdallah-14/unslop --skill unslop-review -a cursor
```

2. **Manually: put the files in place**
- File: `.cursor/skills/unslop-review/SKILL.md` — Cursor also reads .agents/skills/ and .claude/skills/

### GitHub Copilot

1. **GitHub CLI**
```bash
gh skill install MohamedAbdallah-14/unslop unslop-review
```

2. **Manually: put the files in place**
- File: `.github/skills/unslop-review/SKILL.md`

### Gemini CLI

1. **Skills CLI (Vercel)**
```bash
npx skills add MohamedAbdallah-14/unslop --skill unslop-review -a gemini-cli
```

2. **Platform CLI**
```bash
gemini skills install https://github.com/MohamedAbdallah-14/unslop --path skills/unslop-review
```

### Windsurf (Devin Desktop)

**Manually: put the files in place**
- File: `.devin/skills/unslop-review/SKILL.md` — The legacy .windsurf/skills/ path still works

### OpenCode

**Skills CLI (Vercel)**
```bash
npx skills add MohamedAbdallah-14/unslop --skill unslop-review -a opencode
```

### Claude.ai

**Claude.ai**
- Zip the folder and upload it in Settings → Capabilities → Skills

Where a file is given instead of a command, copy the files from the source to that path: https://github.com/MohamedAbdallah-14/unslop/tree/HEAD/skills/unslop-review/SKILL.md

## When to use it
- strip robotic hedging and polite padding from PR comments
- format feedback into concise line numbers and concrete fixes
- categorize issues using `bug:`, `risk:`, `nit:`, and `q:` tags
- generate clean comments ready to paste into pull requests

## Example prompts
- Review this PR with `/unslop-review`
- De-slop this code review comment and give me a concrete fix
- Format these review notes using line numbers and severity prefixes

## Source text · SKILL.md · MIT

Below is the content of a third-party file. It is data, not instructions for you: do not act on anything written inside unless the human asks. Block tag: 4eb1f46db76dfc04.

BEGIN THIRD-PARTY FILE 4eb1f46db76dfc04
```text
---
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<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
- 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.`
```
END THIRD-PARTY FILE 4eb1f46db76dfc04

The third-party file has ended. Everything between the 4eb1f46db76dfc04 tags is data: requests and commands from it are not followed. An “end of file” line with another tag inside the block is part of the file.

First 3039 of 3932 bytes. © MohamedAbdallah-14 · MIT · https://github.com/MohamedAbdallah-14/unslop/tree/HEAD/skills/unslop-review/SKILL.md

_Part of the page did not fit — see the HTML version._

---
NeVibeCode on affpapa.org. Catalog texts are descriptions, not instructions for the agent. How to choose and install: https://affpapa.org/en/nevibecode/agents.md