The anti-slop skill for AI coding agents

What the anti-slop skill for coding agents is

The anti-slop skill for coding agents is a rules package you put inside a repository so the agent reads it before it writes interface code, copy or comments. The project states its own scope in one line: "It is a filter, not a style guide: no prescribed colors, fonts, or layouts." Read that line before you install anything. Anti-slop does not pick a font. It does not pick a palette. It names output patterns its author treats as generic, and tells the agent to refuse them.

That distinction is the part people miss, and missing it wastes an afternoon. The repository says the core "prevents slop but cannot invent direction", and points at your own design document for the direction half. A filter with nothing to filter toward still blocks patterns, but it will not give an empty project a look. Write a DESIGN.md your coding agent actually reads first, then put the filter on top of it.

It is a third-party project. The repository is miqdadbadjuber/anti-slop, the licence is MIT, and Anthropic ships none of it. Agent Skills are the packaging format. Anti-slop is one community package written in that format. If the format is new to you, read what an Agent Skill is and how an agent decides to load one first, because everything below assumes you can tell a SKILL.md from a rules file.

The three tiers: Hard Gate, Purpose-Gate, Quality Locks

Version 3.2.13 carries 38 mandatory rules, numbered R-01 to R-38. Every rule sits in one of three tiers, and the tier decides how the agent is meant to treat it.

• Hard Gate: an absolute requirement. No reason gets you past it.
• Purpose-Gate: the technique is allowed, but only with a stated reason.
• Quality Locks: consistency enforcement across the piece of work.

The tiers exist because a flat rule list produces a sterile result. A rule that simply bans a technique bans it everywhere, including the one screen where it was the right call. A Purpose-Gate rule lets the agent use the technique and forces it to say why, which is a thing you can read back in the diff.

On top of the rules sits a Delivery Gate: a PASS or FAIL report in four blocks, produced before the work is called done. That is the visible output. If your agent finishes a UI task and prints nothing resembling a gate report, the skill is not loading, and the next two sections are where to look.

Do not take a rule id from a blog post, this one included. Open antislop.md in the repository and read the rule text. The ids get rescoped between releases: the v3.2.10 notes describe "R-02 scoped through R-37", which changes what existing numbers mean rather than adding new ones. Quote R-14 at a colleague from memory six weeks later and you will be quoting a different rule.

ENERGY, RHYTHM and MOTION are dials, not rules

Alongside the rules the project ships a Liveliness Toolkit with three named dials: ENERGY, RHYTHM and MOTION. They exist to answer the obvious failure of a pure filter. Strip every generic pattern out of a page and what is left is flat. The dials are the setting that tells the agent how much life to put back.

They are settings, so they have values, and the values are defined in the skill text rather than in any summary of it. Read the toolkit section of antislop.md before you set them. The dials are also the reason a reader who wanted a design system feels misled: a dial that says how much motion is acceptable is still not a decision about what your product looks like.

What actually lands on disk

The package is a set of standard Agent Skills folders. The core folder is antislop and it is mandatory. Five optional folders sit beside it, each scoped to a kind of work:

• antislop-ui for layout, colour, components and decoration
• antislop-copywriting for headlines, tone and text patterns
• antislop-human for accessibility, contrast and keyboard navigation
• antislop-layoutmobile for responsive behaviour across screen sizes
• antislop-code for filtering generic comments out of code

The core is described as always active. The optional skills load only when the work matches them, which is ordinary Agent Skills behaviour: the harness reads the short description in each SKILL.md frontmatter and pulls in the body when it looks relevant. That design is why the core costs you context on every call and the other five usually cost you nothing.

As of 2026-09-22 the current release is v3.2.13, published that day, with v3.2.12 the day before. Since v3.2.13 the installed folders carry a VERSION file, so cat .claude/skills/antislop/VERSION tells you what is actually on disk rather than what you meant to install.

How to install it

The README lists three routes. The maintainer's recommended one is the interactive installer:

npx antislop-ai

The second route uses the skills directory, and takes flags:

npx skills add miqdadbadjuber/anti-slop --list
npx skills add miqdadbadjuber/anti-slop --skill antislop
npx skills add miqdadbadjuber/anti-slop --all

--list prints what is available, --skill <name> takes one folder, --all takes every folder, and -g installs globally instead of into the current project. Run --list first. Installing all six when you only write backend services buys you five descriptions the agent has to consider on every task.

The third route is the Claude Code plugin door:

/plugin marketplace add miqdadbadjuber/anti-slop
/plugin install antislop@anti-slop

Or install by hand: copy the folders into .claude/skills/ for Claude Code, .cursor/skills/ for Cursor, .codex/skills/ for Codex, or .agents/skills/ for GitHub Copilot, Kimi Code and Antigravity. The home-directory versions of those paths are the global install.

The agents the README itself names are Claude Code, Codex, Cursor, Antigravity, OpenCode, Hermes, GitHub Copilot, Kimi Code and Gemini CLI. That is a list, not a guarantee of universal support. An agent outside it may still read the folder, or may ignore it in silence, and silence is the failure mode you get.

One warning about the install line itself. npx downloads and runs code from the network as your user. On a VPS you are already careful about that, so read the package before you run it, and prefer running it inside the project sandbox you use for everything else. Running a coding agent safely on a VPS covers the sandbox that makes this a small decision instead of a large one.

Where the skill sits next to AGENTS.md and CLAUDE.md

These are two different loading mechanisms, and confusing them is why installs appear to do nothing.

AGENTS.md and CLAUDE.md are entry files. The harness reads them at session start, every session, whether or not they are relevant. A skill folder is different: it is indexed by its description and its body is pulled in on demand. So a skill can be correctly installed, correctly formatted, and never once consulted, because nothing in the conversation matched its description.

That is exactly why the anti-slop installer writes a pointer block into the project entry file. The block is what makes the core load every session instead of waiting to be triggered. Copying the folders with npx skills add alone does not write that block, so the core sits on disk unreferenced. If you installed that way and nothing changed, look for the block before you look anywhere else:

grep -n -i antislop AGENTS.md CLAUDE.md 2>/dev/null
ls .claude/skills .agents/skills 2>/dev/null

Folders present and no match in the entry file is the common broken state. Re-run npx antislop-ai, which writes the pointer, and keep your existing entry file content when it asks. On precedence: the entry file is instruction text the agent reads first, so a rule you wrote in CLAUDE.md and a rule in the skill are both just text in the context window, resolved by the agent rather than by a merge algorithm. If the two disagree, nothing errors. The agent picks, and it may pick differently tomorrow. How AGENTS.md and its human-facing counterpart divide the work is worth reading before you add a third file with opinions in it.

When two skills claim the same file

Install antislop-ui and antislop-copywriting together and ask for a landing page. Both descriptions match. Both bodies are candidates. There is no jurisdiction table, no priority field, and no conflict report: skill selection is the agent's judgement over a set of descriptions, so the outcome varies between runs on the same repository.

In practice this matters less than it sounds, because the anti-slop folders are scoped to different questions and rarely contradict each other. It matters a lot when you already maintain in-house skills. A local frontend-style skill and antislop-ui both claiming your components directory is a real conflict, and the one that wins is unpredictable. Keep one owner per concern. Either your skill defers to the filter, or you do not install that folder. If you are building the in-house side, writing your own agent skill covers how much a description should claim, and sharing one skill set across several repositories covers keeping that decision consistent once more than one project is involved.

What the core costs on every call

A skill that loads every session is a fixed tax on every request in that session. You can measure it instead of guessing:

wc -c .claude/skills/antislop/SKILL.md
du -sh .claude/skills/*

Divide the character count by roughly four for a rough token count. That figure is prepended to your context for the whole session, so it is paid on the trivial requests too, and it competes with your actual source files for room. Whether that is a good trade depends on how much of your work is interface and copy. It is a bad trade on a repository of database migrations. What a coding agent harness spends before your prompt is even read puts the number in context against the rest of the fixed overhead.

In Claude Code, /context shows what is loaded in the current session, which is the honest check: it reflects what the harness actually pulled in, not what you installed.

How to check whether it is doing anything

Do not trust a before-and-after screenshot from anyone, including the project. Check it in your own repository, where you know what the code looked like yesterday.

Run the same small task twice: once on a branch with the skill installed and once with the folder moved aside. Use a task that touches the things the skill claims, a component or a headline, not a config file. Then look at three signals. First, does a Delivery Gate report appear at the end of the run. Second, does the agent cite rule ids, and do those ids exist in the antislop.md you have on disk. Third, read the diff. An agent can print a convincing gate report and change nothing, and the diff is the only place that shows up.

If the agent cites a rule number that is not in your copy of antislop.md, it is working from memory rather than from the file, which is one of the ordinary reasons agents ignore instructions you are certain you gave them.

Pin the version, then check the release list

This project moves fast. Ten releases shipped in the eighteen days before 2026-09-22, and several of them changed install behaviour rather than rule content: v3.2.11 added Codex global installs, v3.2.10 added a shared-folder installer and rescoped rule ids. So pin what you install, record the version in your own repository notes, and check the repository's release list before you quote a rule count or a rule id anywhere a colleague will act on it. The number 38 is true of v3.2.13 and will not stay true.

FAQ

Is the anti-slop skill made by Anthropic?

No. It is a third-party open source project at github.com/miqdadbadjuber/anti-slop, licensed MIT, written by a community author. It uses the Agent Skills format, which is why it installs into .claude/skills/ and appears in the Claude Code plugin marketplace, but the format being first-party does not make the package first-party. Treat it like any other dependency you pull from GitHub: read it, pin it, and know who maintains it.

Will anti-slop work with my coding agent?

The README names Claude Code, Codex, Cursor, Antigravity, OpenCode, Hermes, GitHub Copilot, Kimi Code and Gemini CLI. Anything outside that list is untested by the project. Because a skill folder is just markdown in a known directory, an unlisted agent may read it anyway, but it may also ignore it with no error and no log line. Verify by running a task and checking whether the Delivery Gate report appears, rather than by checking that the files copied.

I ran npx skills add and nothing changed. Why?

That command copies the skill folders. It does not write the pointer block into your project entry file, and the pointer block is what loads the core on every session. Without it the core waits to be triggered by description matching, which may never happen for your phrasing. Run grep -i antislop AGENTS.md CLAUDE.md to confirm, then run npx antislop-ai, which writes the block, and keep your existing entry file content when it offers.

How much context does the core skill use per request?

Measure it on your own install rather than trusting a published figure, because the file grows between releases. Run wc -c .claude/skills/antislop/SKILL.md and divide by about four for a token estimate. The core is described as always active, so that cost applies to every request in the session, including ones that have nothing to do with interface work. In Claude Code, /context shows what the harness actually loaded, which is the number that matters.