Anti-Slop: Low-Evidence Pattern Rules for Oxlint
Oxlint rules that reject low-evidence, low-signal TypeScript/JavaScript patterns, packaged as an Agent Skill you vendor into your repository.
Install copies files locally, refuses to overwrite existing destinations, pins exact versions, and records provenance via UPSTREAM.md; no exfiltration, no dangerous defaults, least privilege. Deducted: user confirmation depends on agent execution, install.mjs source not shown in evidence, publisher unverified.
SKILL.md steps are self-consistent with explicit completion conditions and controlled failure handling (overwrite refusal, diagnostics reporting); repo includes RuleTester suites and CI. Deducted: the core install.mjs is not shown in evidence, nothing was executed, and tests cover rules rather than the install key path.
Audience (TS/JS repos) and trigger phrases (install/update/upgrade/migrate) are explicit; Effect opt-in gating and rule analysis limits are thoroughly disclosed. Deducted: trigger precision relies on agent judgment, no Chinese-language support stated; npm/oxlint reachability from mainland China assumed but unverified.
Well-layered docs (SKILL.md→README→vendored LICENSE/UPSTREAM.md), MIT license, version 0.1.2, CI skill-asset drift check, clear update path. Deducted: no formal changelog; update flow partly depends on agent reading repo state; versioning rests on package. alone.
The task (install/configure vendored Oxlint rules) is well defined with directly usable config snippets, exhaustive rule lists and examples, and clear marginal value over manual setup. Deducted: static review cannot verify executed results or install script behavior.
README gives violation examples and boundary statements; the repo contains a real CI workflow and 23 test entry points, providing auditable primary material. Deducted: test file contents not shown, rule behavior not independently reproducible in a static read, capped at 5.
- install.mjs source was not shown in this evidence; review it manually before use;
- Rules are syntactic (ESTree/lexical scope), not type-aware, and cannot claim exhaustive violation coverage;
- All rules default to error severity and will flag legacy code heavily; assess impact before first install;
- No Chinese-language support declared; depends on npm/oxlint ecosystem with unverified mainland-China reachability.
What does this skill do, and when should you use it?
Anti-slop is an opinionated Oxlint ruleset by dmmulroy that blocks common low-evidence TypeScript and JavaScript patterns such as chained as assertions, unknown parameters and returns, accumulating copies in reducers, and ad hoc runtime typeof narrowing. It is designed to be vendored rather than installed as an npm dependency: rule sources, licenses, and provenance are copied into your repository and become yours to maintain. A bundled agent skill copies the plugin, installs version-matched @oxlint/plugins dependencies, merges lint configuration, and enables every generic rule. Repositories that depend directly on Effect can also opt in to a separate Effect rule group.
Reads the target repository's agent instructions and git status to detect package manager and existing lint configuration; runs node <skill>/scripts/install.mjs to copy the plugin to tools/oxlint/anti-slop/ (alternate destinations supported, refuses to overwrite existing copies); installs @oxlint/plugins pinned exactly to the repository's oxlint version; merges ignorePatterns, jsPlugins, and 18 generic rules (plus native oxc/no-accumulating-spread) into oxlint.config.ts / .oxlintrc. or Vite+ lint/fmt config; enables 5 anti-slop-effect rules for Effect repositories; then runs lint and typecheck, applies authorized whitespace fixes, and records provenance (source commit, deviations) in UPSTREAM.md. Updates use a three-way merge to preserve local customizations.
- TypeScript teams that want a defensive lint policy vendored into the repo and evolving with the code
- Maintainers wary of AI-generated slop who want lint enforcement against low-evidence patterns
- Effect projects seeking uniform tagged-error, Match, and Layer conventions
- Repositories with an existing anti-slop installation upgrading to upstream rules while keeping local changes
- Vite+ teams wanting vp check to cover both lint and formatting of installed agent assets
What are this skill's strengths and limitations?
- Specific, thoroughly documented rules with violation examples and stated exemption boundaries
- Vendor model: rules are owned by the repository and free to modify for team standards
- Update flow uses three-way merge, never force-replaces the vendored directory
- Supports both Vite+ (vp check) and oxlint.config.ts / .oxlintrc. configuration
- Effect rules live in a separate opt-in plugin; non-Effect projects inherit no Effect policy
- Rules use ESTree and lexical-scope APIs, not a type checker; no cross-file or imported-type inference, and several checks are explicitly local-only
- The author states this reflects personal taste, not a universal coding standard — fit varies by team
- No official npm package; community forks and packages are maintained independently
- no-array-filter-map's preferred iterator-helper pipelines require runtime support that TypeScript declarations do not polyfill
- Strong-opinion rules like no-module-mocking (rejecting vi.mock/jest.mock) may spark team debate
How do you install this skill?
Run: npx skills add dmmulroy/anti-slop --skill install-anti-slop (use --list to inspect available skills first). Then ask your coding agent to install anti-slop in the target repository. Manual alternative: copy src/ to tools/oxlint/anti-slop/ and register jsPlugins and rules per the README example.
How do you use this skill?
After installing the skill, prompt your agent with "Install anti-slop in this repository" or "Update anti-slop while preserving local customizations" (optionally naming an upstream revision). The skill copies files, installs dependencies, merges config, runs checks, and reports findings. Rule details and violation examples are in the README.
How does this skill compare with similar options?
Complements Oxlint's native oxc/no-accumulating-spread: the custom no-reduce-accumulator-copy catches non-spread accumulator copies (Object.assign, Array.from, concat/slice) that the native rule misses, and the docs require enabling both. The comment-aware engine behind require-readable-spacing is vendored from ESLint Stylistic.