The anti-slop README makes one distinction up front: it is a filter, not a style guide. It prescribes no colors, fonts or layouts. Its job is to remove what should not be there, such as invented numbers and filler copy, and its code skill decides which AI-slop comments to remove and which to keep. Direction comes from your own DESIGN.md. The README goes as far as making that a rule: a sterile result means the direction was missing, not that the filter failed.
anti-slop, called antislop in its README, is a rulebook for AI coding agents shipped as standard agent skills, one folder per skill with a SKILL.md. It is MIT licensed.
Four builds of the same brief
The README opens with a comparison that makes the filter-versus-direction point visually. The same brief is built four ways. With nothing at all, you get what it calls the usual AI starting point: a sparkle logo, a beta pill and a fake terminal. With antislop alone, the result is honest because the filter removed the invented numbers, and plain because beauty is not its job. With DESIGN.md alone, the direction lands but the slop stays. Only the combination is clean and directed at the same time.
I find that framing useful. The README's argument is that removing bad patterns and supplying direction are two different jobs, and one cannot stand in for the other.
38 rules and a delivery gate
The core contains 38 mandatory rules, numbered R-01 to R-38, in three tiers the README names Hard Gate, Purpose-Gate and Quality Locks. A Liveliness Toolkit adds three dials, ENERGY, RHYTHM and MOTION, plus a Design Read, so the result comes out alive rather than merely clean. A Delivery Gate is a mandatory PASS or FAIL report in four blocks, run before anything ships.
Six skills split the concerns so an agent loads only what a task needs:
-
antislop, the core filter, always loaded. -
antislop-uifor layout, color, components, decoration and motion. -
antislop-copywritingfor headlines, CTAs, tone, fake stats and markdown hygiene. -
antislop-humanfor contrast, keyboard, focus and states. -
antislop-layoutmobilefor reflow, breakpoints, grids and tap targets. -
antislop-codefor deciding which AI-slop comments to remove and which to keep.
The README says skills reference the core rules by number and never duplicate them.
During or after
There are two usage modes. During guides the work as it is built and closes with the Delivery Gate report. After audits existing work: it produces a numbered findings list, you approve which ones to fix, and you get a follow-up report. By default the agent asks which mode at the start of every session. Saving a preference is opt-in with npx antislop-ai --mode during, stored in a shared settings file that covers every agent and project. A mode you ask for in the current chat always wins for that session.
The After mode is the one I would start with. Running an audit over a page or a README you already have gives you a numbered findings list to approve or reject before you let the filter shape new work.
Contrast threshold handling
The roadmap note for version 3.2.21 describes a contrast fix. That version reads the contrast threshold from the unrounded ratio, so a pairing that computes to 4.4983:1 no longer rounds to 4.50 and passes a 4.5:1 check. The README says the boundary is now pinned in the reference table.
Installing it
The recommended route is npx antislop-ai, which asks which skills you want, where to install them and which agents you use. There are plugin installs for Claude Code, Codex, Cursor, Antigravity, Kimi Code, Cline and others, a npx skills add miqdadbadjuber/anti-slop route, and a single antislop.md file you can paste into any chat. The README notes that antislop does not update itself; installer users run npx antislop-ai --update, and skills load at session start, so open a new session afterwards.
GitHub: https://github.com/miqdadbadjuber/anti-slop
Curated by Agent Palisade — practical AI for small and mid-sized businesses.
Top comments (1)
Treating it as a filter rather than taste is the key. The rules should map to observable failure modes—unverified claims, unused abstractions, missing tests, or inconsistent interfaces—so an agent can explain a rejection and a team can tune the policy.