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. Stop producing. 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, rewrite the weak parts, add some personality, and inspect the result again.

You can install it with:

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

Its rules look for common AI writing habits:

• puffed-up language that makes an ordinary fact sound historic
• vague claims with no source or concrete detail
• filler and long ways to say simple things
• forced comparisons and groups of three
• repeated sentence structures
• 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.

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.

That last step matters. 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.

The skill proposes the edit. I 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 phrases such as “evolving landscape” and “authentic and engaging.” 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. 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 is useful because it makes one easy-to-forget review repeatable.

It removes obvious AI habits before I inspect the result. That leaves me with a smaller and more useful final review.

That is enough reason for me to use it.