anti-slop is a set of lint rules for common AI-written TypeScript patterns

anti-slop is an Oxlint plugin by Dillon Mulroy that rejects what it calls low-evidence and low-signal TypeScript and JavaScript patterns. The repository was created on 12 August 2026 and had 3,929 stars on 31 August, under an MIT licence.

What it actually checks

The rule names describe the problem better than any summary would:

• no-chained-type-assertions
• no-known-value-widening
• no-widen-then-assert
• no-unknown-returns
• no-unknown-parameters
• no-unknown-type-aliases
• no-runtime-typeof
• no-unsafe-dictionary-type
• no-conditional-empty-object-spread
• no-module-mocking

Read that list twice and a pattern appears. Almost every rule is about a moment where the code stops proving something and starts asserting it instead. Widening a value to unknown and then asserting it back. Chaining assertions until the compiler stops reporting errors. Checking a type at runtime because the static type was never trustworthy.

The unusual part

The project says it is meant to be copied into your repository (vendored), not installed as a package. There is no npm package, on purpose. You copy src/ into your repository, read the rules, and change the ones you disagree with.

The author is direct about why: this is the ruleset he uses with his own team, it reflects his taste, and it is not trying to be a universal standard. That is a more honest framing than most linting projects manage.

Installation runs through an agent skill:

npx skills add dmmulroy/anti-slop --skill install-anti-slop

Then you ask your coding agent to install it, and the skill copies the plugin, matches your existing Oxlint version, merges the configuration and validates the result. The default configuration ignores agent directories: .claude, .cursor, .codex, .gemini, .windsurf and several more.

Why this matters more than a normal lint plugin

The patterns in that rule list are exactly what code looks like when whatever wrote it needed the types to pass and did not have the evidence to make them pass honestly. A person under deadline pressure produces them. A model producing a plausible-looking file produces them constantly.

The useful part is that these are all machine-checkable. You do not need a reviewer to notice a chained type assertion at nine in the evening. The rule notices it every time, in the editor, before the pull request exists.

That is the general answer to "how do you keep quality up when a machine writes the code": a check that runs on the exact patterns the machine tends to produce, on every file, every time.

Take the rules, read them, and keep the ones you can justify.

Source

• dmmulroy/anti-slop on GitHub, MIT licence. Star and date figures read from the GitHub API on 31 August 2026