Make Your Linter Reject Low-Evidence TypeScript With anti-slop

TypeScript's unknown is honest; the code that shovels values through as chains to escape it is not. anti-slop, a 6k-star Oxlint ruleset, turns that taste into errors enforced mechanically at lint time: rules that reject low-evidence and low-signal patterns — chained type assertions, unknown parameters and returns, module mocking, accumulating reducers.

Why This Skill Matters

The README is upfront that this is one developer's ruleset — "the ruleset I use with my work, projects, and team... my preferences and taste rather than... a universal coding standard" — which is exactly why it ships the way it does: meant to be vendored, not installed as a fixed npm dependency. There is no official npm package. You copy the rules into your repository, read them, and change what your team disagrees with. The bundled agent skill handles the initial copy and configuration; after that the vendored files are yours.

The rule set is 18 generic rules plus 5 Effect-specific rules kept in a separate plugin so projects that do not use Effect never inherit Effect architecture policy. The generic rules cluster around a theme the README states plainly — evidence: no-chained-type-assertions rejects nested as fabrications, no-widen-then-assert rejects widening known values and asserting them back, require-safety-comment-for-type-assertion demands a justification comment for each non-const assertion. Others target readability and performance (require-readable-spacing, no-array-filter-map, no-reduce-accumulator-copy) and test honesty (no-module-mocking rejects Vitest and Jest module mocks in favor of real dependency seams).

Installation

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

Then ask your coding agent to install or configure anti-slop in the current repository. Per the README, the skill copies the plugin, installs compatible Oxlint dependencies — matching an existing Oxlint version when present — merges the plugin into your existing lint configuration, enables every generic rule, and validates the result. In repositories that depend directly on Effect, it also enables the opt-in Effect rule group. To see what the repo offers before installing, use --list:

npx skills add dmmulroy/anti-slop --list

Real Workflow: Vendor It, Then Own It

After the skill runs, your repository has the rules vendored under a path such as the README's documented tools/oxlint/anti-slop/ example, plus a registered entry in oxlint.config.ts. The next step is the one the README insists on: read the rules and tune them. Delete what your team rejects, keep the rest at error.

Day-to-day, the rules surface as ordinary lint errors with opinions attached. no-array-filter-map flags users.filter(u => u.active).map(u => u.email) and asks for a lazy iterator pipeline; require-safety-comment-for-type-assertion flags a bare const userId = value as UserId until a // SAFETY: comment explains the invariant that makes the assertion safe. One catch from the README's own analysis-boundaries section: the rules use Oxlint's ESTree and lexical-scope APIs, not a TypeScript type checker — they resolve same-file aliases but do not infer imported types or cross-file call signatures, so some rules document that enforcement is intentionally local.

Updates follow the same pattern. Ask your agent to update anti-slop while preserving local customizations: the skill stages incoming source separately, uses a three-way merge when the original upstream snapshot is recoverable, and preserves your local rules — asking about conflicting policy rather than force-replacing the vendored directory.

Tips

• Treat the vendored copy as yours: the README invites exactly this, and community forks are explicitly welcome.
• Enable oxc/no-accumulating-spread alongside no-reduce-accumulator-copy — the native rule covers spreads in reducers and supported loops.
• require-readable-spacing autofixes missing blank lines between top-level declarations; run oxlint --fix, then your formatter, then lint again.
• The Effect rules are opt-in by design — register the second plugin only in repositories that actually depend on Effect.

When Not to Use This

If you want a neutral, team-agnostic style guide, this is the opposite: opinionated by the author's own description, and several rules (no-module-mocking, no-runtime-typeof) will fight patterns your codebase may legitimately rely on — the README expects you to change the vendored rules rather than endure them. And because analysis is syntactic, teams wanting type-checker-aware enforcement need a different tool.

See the leaderboard for more skills.