Why I use anti-slop skills

There are now enough anti-slop skills for AI agents to rank them.

I saw a list with ten.

The names are slightly different. unslop, humanizer, stop-slop, deslop. They all start from the same observation: AI agents repeat themselves.

You see it in writing. You also see it in code.

The first result can be correct and useful, yet still contain choices the model makes everywhere. A bloated introduction. A forced group of three. An abstraction with one caller. A comment that repeats the code below it.

An anti-slop skill gives the agent a second job: inspect what it produced and remove the generic habits. That is why I use them.

What an anti-slop skill does

An anti-slop skill is a Markdown file with review instructions for an agent.

For example, the unslop skill tells the agent to scan a piece of writing for AI patterns, then rewrite it while keeping the meaning and the tone.

You can install it with:

npx skills add https://github.com/cursor/plugins --skill unslop

Its rules look for common AI writing habits:

• AI vocabulary like “delve”, “pivotal” and “tapestry”
• vague claims with no source or concrete detail
• filler and long ways to say simple things
• forced comparisons and groups of three
• a subject that gets a new synonym every time it comes up
• too much formatting, including bold text and section headings

This is a focused review. The agent knows which patterns to find and what to do when it finds them.

Most public anti-slop skills target writing. I would not run the same instructions against code. For code, I would create a separate skill with code-specific patterns.

The process is the same. The checklist is different.

unslop, stop-slop, humanizer and deslop: what’s the difference?

These are the four names from the start of this post. Three of them clean up writing, and deslop cleans up code. Each one is a SKILL.md file, so you can read exactly what it tells the agent before you install it.

unslop

unslop is part of pstack, Lauren Tan’s plugin in Cursor’s plugins repository. If you installed pstack, you already have it. It targets writing only.

Its 28 numbered rules include a list of AI words (delve, pivotal, tapestry, underscore), “serves as” where “is” would do, and a ban on em dashes that also forbids parentheses as the replacement. One rule asks whether a sentence could appear unchanged in another project’s docs, and cuts it if so.

In Cursor and Claude Code it only runs when you type /unslop. In Codex, you mention it as $unslop. Install it with pstack (/add-plugin pstack in Cursor) or with the Skills CLI command shown above. The full walkthrough is in how to use the unslop skill. poteto-mode also runs it on every piece of prose it writes.

stop-slop

stop-slop is by Hardik Pandya, and it targets writing. It’s a short SKILL.md plus three reference files: a list of phrases to remove, a list of structures to avoid, and before/after examples.

It’s strict. It removes all adverbs, avoids sentences that start with a Wh- word, and says two items beat three. It also has a scoring step: the agent rates the text from 1 to 10 on directness, rhythm, trust, authenticity and density, and revises it when the total is below 35 out of 50.

Install it with:

npx skills add https://github.com/hardikpandya/stop-slop --skill stop-slop

humanizer

Humanizer is by Siqi Chen (blader on GitHub), and it targets writing. Its 26 patterns come from Wikipedia’s Signs of AI writing guide, ranked by strength. The top five, like “Not X but Y” and one-line closers, justify an edit on a single sighting. The patterns marked “weak alone” only count when other tells show up in the same passage.

You can paste a sample of your own writing, and it matches that voice. When a sentence needs a detail the source doesn’t have, it asks you instead of inventing one.

In Claude Code, install it as a plugin:

/plugin marketplace add blader/humanizer
/plugin install humanizer@humanizer

For Codex, the README uses the Skills CLI. Swap codex for another agent name, or '*' for all of them:

npx skills add blader/humanizer --global --agent codex

deslop

deslop comes from Cursor, and it’s the only one of the four that targets code. It ships in the cursor-team-kit plugin in the same repository.

It checks the branch diff against main and removes what an agent added out of habit: comments that don’t match the local style, defensive checks and try/catch blocks on trusted code paths, casts to any that only silence type errors, and deep nesting that early returns would flatten. Its guardrails tell the agent to keep the behavior unchanged and prefer small, focused edits.

Install it in Cursor with /add-plugin cursor-team-kit, or with:

npx skills add https://github.com/cursor/plugins --skill deslop

Several other skills on skills.sh are also called deslop. This is the one pstack’s PR workflow runs on the diff before each commit.

For READMEs, docs and PR descriptions, start with unslop or stop-slop, since they’re short enough to edit into your own version. Pick Humanizer when you want the rewrite to match a sample of your writing, and add deslop for code.

If you try several and they pile up, Skillscout finds the skills that read alike and can merge two into one.

Why I run it as a separate pass

When an agent writes an article or implements a feature, its main job is to finish the work.

It has to keep track of the request, the source material, the existing project, and the expected result. A final line saying “do not sound like AI” is just one more instruction competing for attention.

I prefer to finish the first draft, then start a separate review.

The anti-slop pass has one narrow job. It can inspect every paragraph or changed file without also trying to invent the next section or complete the feature.

This also gives me a clean diff to review. I can see what the skill removed, what it rewrote, and whether it changed something that should have stayed.

I do not ask it to rewrite everything. I ask it to preserve the meaning and fix the patterns it was designed to catch.

How I use anti-slop skills

First, I give the agent the facts, the sources, and the goal.

If I have a project-specific writing or coding skill, I use that while creating the first version. The anti-slop skill comes later.

My final prompt is close to this:

Review the finished work using the anti-slop skill.

Keep the facts, examples, and intended structure.
Fix only the patterns covered by the skill.
Show me the resulting changes.

Then I inspect the result myself.

I inspect it because an anti-slop skill can make a bad correction. It can remove a sentence I like, flatten an unusual phrase, or replace one repetitive habit with another.

I treat the edit as a proposal and decide whether it stays.

Start with a generic skill, then change it

A public anti-slop skill is a useful starting point. It is not a universal definition of good writing or good code.

Take em dashes. A rule that bans them can make the agent use parentheses or double hyphens everywhere instead. The symbol changed. The repetitive habit did not.

Some writers use em dashes well. The problem is not one punctuation mark. The problem is seeing the same construction five times on one page.

I treat every correction as feedback for the skill.

When it misses the same pattern twice, I add a rule. When a rule keeps producing awkward results, I remove it or make it more precise.

Over time, the generic checklist becomes a review pass for the way I work.

An anti-slop pass for this blog

For this blog, I want the skill to catch generic writing without flattening the way I teach.

I would add rules like these:

## Blog anti-slop pass

- Open with the useful point. Delete generic introductions.
- Keep paragraphs short and explain one idea at a time.
- Replace broad claims with facts, commands, or real examples.
- Introduce code before showing it.
- Remove sections that repeat an earlier point.
- Preserve first-person opinions and deliberately short paragraphs.

An AI draft for this post might begin like this:

In today’s rapidly evolving AI landscape, anti-slop skills are becoming an essential tool for creators who want to produce authentic and engaging content.

The public unslop skill can already catch the abstract “landscape” in that sentence. My blog-specific rules tell it what a better opening looks like here:

There are now enough anti-slop skills for AI agents to rank them.

I saw a list with ten.

The new opening starts with something I noticed. It gets to the subject immediately.

It also keeps the second paragraph short. A generic humanizer might join those lines because the second paragraph looks incomplete. My skill knows the rhythm is deliberate.

An anti-slop pass for Port Pilot code

Code slop is different. It often looks like extra structure added without a current need.

An agent adds a protocol with one implementation. It creates another type that carries the same fields. It wraps an existing helper, adds fallback behavior nobody requested, or catches an error and turns it into an empty result.

For Port Pilot, I would run a code anti-slop pass after the agent finishes a change:

## Port Pilot code anti-slop pass

- Review only the changed code.
- Find new abstractions with one caller or one implementation.
- Search for an existing type or helper before keeping a new one.
- Remove comments that only repeat the code.
- Do not hide errors behind `false`, `nil`, or empty results.
- Remove fallbacks, platform branches, and dependencies not required by the task.
- Preserve behavior. Do not redesign the product during this pass.

The current Swift client delegates a stop action with one small method:

public func stop(port: Int) async throws -> KillResponse {
  try await decode(KillResponse.self, arguments: ["kill", String(port), "--yes", "--json"])
}

A generic refactor could put a protocol, command executor, termination service, and error adapter around that call. The names might sound clean and extensible. Unless the current task needs a second implementation, those layers only make the code harder to follow.

The anti-slop pass should catch that expansion and bring the patch back to the smallest useful change.

Port Pilot also has important rules about confirmation and process termination. Those are product architecture and safety rules. They belong in the project’s agent instructions, not in the anti-slop skill.

The anti-slop skill has a smaller job: remove generic coding habits that slipped into the patch.

What an anti-slop skill cannot do

An anti-slop skill catches patterns, but it cannot supply missing facts, choose the right architecture, or decide what I believe. It also cannot make an unverified article correct or make untested code work.

I still need sources, tests, and judgment. The skill makes one easy-to-forget review repeatable and removes obvious AI habits before I inspect the result. Cleaning habits is not the same as sending unchecked AI output — that is a slop grenade.

That leaves me with a smaller and more useful final review, which is enough reason for me to use it.

Want me to talk about your product? You can sponsor this site.