Kill AI Slop: a field guide plus a scanner that strips the machine-made look out of your project

The narrow problem: machine defaults that survive review

Vibe-coded products fail in a consistent way. The README names the pattern directly: indigo gradients, glowing cards, emoji everywhere, a mascot in every corner, ALL-CAPS stat-cards. None of these are bugs. Each one passes a build, a type check and a code review, because there is nothing to fail. They are taste defaults, and defaults are exactly what a model falls back on when it has no opinion about your product.

The audience is therefore narrow and specific. It is people shipping web front ends where a large share of the markup and styling came out of a coding agent: solo builders, small product teams, and anyone who has looked at their own landing page and felt something was off without being able to name it. The project does not try to be a general design system, a linter for accessibility, or a code-quality tool. It targets one aesthetic failure mode and documents it exhaustively.

The claim worth taking seriously is the one about the catalogue itself: every tell is described as one you can find in real, shipped products rather than a strawman. That is the difference between a style guide and a complaint. A complaint says gradients are bad. A catalogue entry has to show the machine-default markup and the clean fix side by side, which forces the author to commit to what the fix actually is.

What is actually in the repository: website, skill, and one shared taxonomy

The repository has two top-level directories and they do different jobs. website/ is an Astro site, described as multilingual, static and zero-JS-by-default, live at killaislop.com. skill/ holds the Agent Skill: SKILL.md, a references directory, and a scanner script.

The design decision that matters is that the taxonomy is not duplicated. website/src/data/catalogue.ts is described as the single source of truth shared with the skill. That means the tells the website explains and the tells the scanner looks for come from the same list, so the two halves cannot drift apart the way a marketing page and a lint rule usually do. If you want to know what the tool can possibly detect, that file is where you look, not the README.

The website is also positioned as an argument rather than a container. The README states the site is itself built as a rebuttal to everything it catalogues, with the design system being paper and ink, one editorial red used like a proofreader's pen, hierarchy from scale and space, hairline rules, and no gradients, emoji, glass or badges. website/src/styles/tokens.css is named as the file holding the rules the site keeps itself to. A field guide that violates its own rules would be worthless, so the tokens file is the load-bearing artifact here, more than any prose page.

How the scanner works, and why it never edits your files

The scanner is a single Node script, skill/scripts/scan.mjs, and the README makes two claims about it that shape everything else. It is dependency-free, and it never edits files. Both are constraints with consequences.

Dependency-free means you can point it at a project without adding it to that project's package.json, without a lockfile change, and without a supply-chain review. It also means the detection has to be pattern-based rather than AST-based, since a real parser would pull in a dependency. That is the trade-off hiding in the design: a regex scanner over markup and styles will produce false positives on strings that merely resemble a tell, and it will miss tells expressed through a build step or a CSS-in-JS runtime. The README does not claim otherwise.

The no-edit rule is the part I would defend hardest. The scanner reports; the skill fixes. In an Agent-Skills host such as Claude Code, the README says invoking the skill makes it scan, triage, report, then fix, following skill/SKILL.md. That split matters because automatic rewriting of visual code is exactly the kind of change nobody reviews carefully. Here the deterministic part is read-only, and the part that touches your files is a model following a written playbook you can read in advance.

Installing the skill and running the scanner on a real project

There are two ways in. The universal installer is a single command that prompts you to pick your coding agents. The README gives it as:

npx skills add yetone/kill-ai-slop

Follow the prompt, and the skill lands in the agents you selected. If you would rather not run an installer, the README offers a paste-to-your-agent route: you give the agent the URL of the skill directory on GitHub, tell it to copy everything in that directory into a kill-ai-slop/ folder inside its own skills directory, and confirm the skill is registered. Manual installation is documented in skill/README.md.

Once installed, the trigger is conversational. The README's example instruction is to tell the agent to kill the AI slop in this project. You do not need the scanner for that path, but running it yourself first is the cheaper way to see what the skill will be reacting to:

node skill/scripts/scan.mjs path/to/project          # grouped report
node skill/scripts/scan.mjs path/to/project --json    # machine-readable

The first form prints hits grouped for reading. The second emits JSON, which is what you want if you plan to diff two runs or wire the output into something else. Expect a list of findings tied to tell ids, not a pass or fail verdict.

If you want to run the field guide locally rather than read it on the site, the website is a normal Astro project:

cd website
npm install
npm run dev        # http://localhost:4321
npm run build      # → dist/  (static, deploy anywhere)

The dev server listens on port 4321, and the build produces a static dist/ directory. There is no server component to deploy.

Filtering, custom rules, and suppressing findings you meant to ship

A scanner that reports everything is a scanner nobody runs twice, so the flag set is where the tool becomes usable on an existing codebase. The README documents --only= and --skip= for filtering by tell id, --exclude= for dropping paths, and --rules=extra.mjs for loading your own language- or stack-specific tells.

The custom rules flag is the most interesting one, because it admits the limit of the built-in catalogue. Thirty-three tells cover the common machine defaults in web UI, but they cannot cover your framework's idioms or your team's own recurring mistakes. extra.mjs is the escape hatch: you keep the shipped taxonomy for the generic cases and encode your local patterns separately, so upgrading the skill does not mean re-merging your additions.

The suppression mechanism is a comment directive called deslop-ignore, which the README says silences hits you have confirmed as intentional. This is the right shape for a taste tool. Some indigo gradient is a brand decision someone made on purpose, and the tool needs a way to record that decision in the code rather than in a config file that drifts. The README points to skill/README.md for the directive's exact syntax, and that file is where you should look before sprinkling it, because a suppression directive that is easy to write is also easy to write wrongly.

Where this is the wrong tool

The scanner reads markup and style signals in a web project. Point it at a backend service, a CLI, a mobile app or a data pipeline and there is nothing for it to find, because the tells it encodes are visual and copy-level. The README describes the target as any web project, and that is the boundary.

The second limit is judgement. The tool detects signals and explains why a pattern reads as machine-made, but the decision to remove a glowing card is yours. A dashboard where glow genuinely encodes state is not slop, and the scanner has no way to know that. Expect to triage every run, which is precisely why deslop-ignore exists.

The third limit is that there are no tagged releases. The skill and scanner are consumed from the main branch, through npx skills add or a manual copy of the skill directory. If you need a pinned, auditable artifact for a regulated environment, that pinning is something you have to do yourself, and the README does not document a versioning scheme to pin against.

Against a general design linter, and against a component library

The obvious comparison is a conventional linter such as stylelint or ESLint with a design-oriented rule set. Those tools answer a different question: is this CSS valid, consistent, and free of known-bad constructs. They operate on syntax and can be wired into CI as a hard gate. Kill AI Slop operates on meaning. A gradient is not invalid CSS, and no rule in a general linter will flag it, because the problem is not the declaration, it is what the declaration signals about who wrote the page and how much they cared.

That difference decides where each belongs. A style linter belongs in CI, blocking merges. This belongs earlier, in the moment an agent is generating a component, which is why it ships as an Agent Skill rather than a plugin. The skill's value is that the correction arrives while the code is still being written.

The other alternative is reaching for a component library or a design system to constrain the output. That works by removing the choice: if the only available button is the system button, the agent cannot invent a glowing one. It is a stronger guarantee than a scanner, and it costs you the ability to make deliberate exceptions. Kill AI Slop sits between the two. It does not prevent the pattern, and it does not remove the choice. It names the pattern so the choice becomes visible.

Licence, maintenance, and what an upgrade actually costs

The project is Apache-2.0, stated in the README and present as a LICENSE file at the repository root. For the scanner that is straightforward: it is dependency-free, so you are copying one script and a references directory rather than pulling a tree of transitive packages. Apache-2.0 also carries an explicit patent grant, which matters more for a tool you might vendor into a commercial product than for one you run locally. As always, the licence text governs, not this summary.

The maintenance picture is concrete. The repository is not archived, and the last push was on 2026-09-15, two days before this writing. There are no tagged releases, so there is no changelog to read before upgrading. That shapes the upgrade cost: because the taxonomy lives in website/src/data/catalogue.ts and the scanner reads from the same list, a catalogue change can change what the scanner reports without any change to scan.mjs. An upgrade can therefore add findings to your report that have nothing to do with your code. Budget for a diff of scan output after pulling, not just a version bump.

The custom rules file and deslop-ignore directives soften that. Your local tells live in extra.mjs, and confirmed-intentional hits live next to the code they annotate, so neither is lost when the shared catalogue grows.

Editorial conclusion

Adopt it if you ship web UI written largely by a coding agent and want the machine defaults named before you argue about them: install the skill with npx skills add yetone/kill-ai-slop, then run node skill/scripts/scan.mjs against the project. Do not adopt it if your product is not a web front end, or if you expect the scanner to make judgement calls, because it reports signals and leaves triage to you. Before trusting a run, read the tell ids in website/src/data/catalogue.ts, check which of them your stack can even express, and confirm the version of skill/scripts/scan.mjs you installed, since there are no tagged releases to pin against.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. yetone/kill-ai-slop on GitHub