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: "A filter, not a style guide: no prescribed colors, fonts, or layouts, and direction stays yours." 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.26, the current release as of 2026-11-06, carries 40 mandatory rules, numbered R-01 to R-40. 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. Version 3.2.24 keeps R-01 to R-38 and adds R-39 and R-40, and R-14 reads word for word as it did at v3.2.13. What moves is the text behind a number. In v3.2.10, R-02, the em dash ban in the Hard Gate, gained a stated scope: it covers text the agent writes, and a writing sample of yours that uses em dashes goes through R-37's conflict protocol, where the agent names the character, names the rule and asks. Same id, narrower reach, and a summary written before that release would tell you the ban applies to everything.

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 project's README and guide describe the core as always loaded, and the optional skills as loading 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. The installer's source is more precise about the core. It writes a pointer, not the core text, into your entry file, and its own comment says "No @ import: the core should only be read when the task needs it." So what every session pays for is that short pointer plus the descriptions of the folders you installed. The core body costs context once the agent opens it for interface, copy or comment work, and the other five bodies cost context only when opened.

As of 2026-11-06 the current release is v3.2.26, published on 5 November 2026. Version 3.2.23, published on 24 October, and v3.2.22, published on 23 October, change the installer rather than the rules: v3.2.22 made the installer probe all seven plugin doors, and v3.2.23 made those probes report the newest installed copy and stopped npx antislop-ai --update, run from your home directory, from updating global folders twice or writing pointer files into your home directory. Neither touches the rule text. The last release that changed skill behaviour is v3.2.26, published on 5 November 2026. It adds three patterns to antislop-copywriting: temporal runway clichés, theatrical takeaways, and title case in list elements. The core, the other skills and every install route are unchanged in that release. Version 3.2.24, published on 28 October 2026, adds two Hard Gate rules: R-39 Accessible Semantics & Interaction Affordances and R-40 Performance Mechanisms, with reference material in antislop-human and antislop-ui read on demand. Version 3.2.21, published on 16 October, changes the contrast check in antislop-human to decide pass or fail on the unrounded ratio, so a pair that rounds up to 4.50:1 no longer passes a 4.5:1 threshold. Since v3.2.13 the installed core folder carries 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 several routes. The maintainer's recommended one is the interactive installer:

npx antislop-ai

Since v3.2.25, published on 1 November 2026, the interactive installer checks for Node.js 20.12 or newer before loading its prompts. The current skills CLI requires Node.js 22.20 or newer.

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 installs every folder to every agent without prompting, and -g installs globally instead of into the current project. The project's own guide uses --skill '*' when you want every folder. Run --list first. Installing all six when you only write backend services buys you five descriptions the agent has to consider on every task. Larger community packs make the same trade at a bigger scale, and working out which of Matt Pocock's 27 skills to install is the same exercise with more descriptions at stake.

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, Amp and Antigravity. A global install usually uses the home-directory version of the same path, with exceptions. Since v3.2.11 a global Codex install goes to ~/.agents/skills/ instead of ~/.codex/skills/, though the old path still loads. Antigravity's global folder is ~/.gemini/config/skills/, and Amp's is ~/.config/agents/skills/. The project's GUIDE.md lists the folder each agent reads.

As of 2026-10-25 the README names Claude Code, Codex, Antigravity, OpenCode, Cursor, Cline, Amp, Gemini CLI, Hermes, GitHub Copilot, Kimi Code, Pi and Oh My Pi, and says the installer covers twelve of them. 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. Gemini CLI stopped serving consumer requests through Google AI Pro, Ultra and free Code Assist for individuals on 18 June 2026. Standard and Enterprise licences and paid API keys still work; Google directs consumers to Antigravity CLI.

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: CLAUDE.md for Claude Code, GEMINI.md for Gemini CLI, and AGENTS.md for most other agents. The block sits between <!-- antislop:start --> and <!-- antislop:end --> markers, lists the paths of the installed SKILL.md files, and tells the agent to read them directly for UI, copy, people, mobile layout or code comments work. It does not paste the core in and does not use an @ import, so the entry file carries a short pointer every session and the agent opens the core when the task calls for it, instead of relying on description matching alone. Copying the folders with npx skills add alone does not write that block, so nothing in the entry file points at the core, and the project's guide says it then reloads by description alone. 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 GEMINI.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 inside your project, which writes the pointer and preserves your existing entry file content automatically. 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

The fixed tax on every request is the pointer block, because it lives in your entry file and the harness reads that file at session start. The core itself is not prepended: the installer writes a pointer rather than the core text, and its source says why in a comment: "No @ import: the core should only be read when the task needs it." You can measure both halves instead of guessing:

wc -c .claude/skills/antislop/SKILL.md
du -sh .claude/skills/*
sed -n '/antislop:start/,/antislop:end/p' CLAUDE.md | wc -c

Divide each character count by roughly four for a rough token count. The pointer block figure is paid on every request, the trivial ones included. The SKILL.md figure is paid once the agent opens the core for interface, copy or comment work, and it competes with your actual source files for room while it remains in context. The full core is not guaranteed to remain throughout the session. In Claude Code, compaction retains at most the first 5,000 tokens per invoked skill within a combined 25,000-token budget, and older skills can be dropped entirely. Whether that is a good trade depends on how much of your work is interface and copy. On a repository of database migrations the core should rarely be opened, which leaves you carrying a pointer and a set of descriptions for rules you have no use for. 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 seven more followed between 23 and 29 September, then v3.2.21 on 16 October, v3.2.22 on 23 October, v3.2.23 on 24 October, v3.2.24 on 28 October, v3.2.25 on 1 November and v3.2.26 on 5 November. Several of them changed install behaviour rather than rule content: v3.2.14, v3.2.15, v3.2.17 and v3.2.18 added Cline, Amp, Pi and Oh My Pi, v3.2.16 added npx antislop-ai --update, v3.2.22 and v3.2.23 changed how the installer finds plugin copies and how --update treats your home directory, v3.2.11 moved global Codex installs to ~/.agents/skills/, and v3.2.10 added a shared-folder installer and gave R-02 a stated scope. The update command searches the current project and your home directory and replaces every antislop folder it finds without asking, so run it on purpose rather than from a habit script, and start a new agent session afterwards to check the updated copy. Plugin copies need updating through their own marketplace. Claude Code also detects edits to local SKILL.md files during a session; run /reload-skills if the top-level skills directory was created after startup. 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 held from v3.2.13 through v3.2.23; v3.2.24, the latest release on 2026-10-29, raises it to 40, and nothing guarantees it stays there.

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?

As of 2026-10-25 the README names Claude Code, Codex, Antigravity, OpenCode, Cursor, Cline, Amp, Gemini CLI, Hermes, GitHub Copilot, Kimi Code, Pi and Oh My Pi. 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 tells the agent, every session, where the core lives and to read it for interface, copy and comment work. 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 GEMINI.md to confirm, then run npx antislop-ai inside your project, which writes the block and preserves your existing entry file content automatically.

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 project describes the core as always loaded, but the installer only writes a pointer into your entry file, and its source says the core "should only be read when the task needs it". So every request carries the small pointer block, and the core's own cost lands once the agent opens it for interface, copy or comment work. In Claude Code, /context shows what the harness actually loaded, which is the number that matters.