B — Some risk signals Graded October 16, 2026Minor concerns worth a quick check.Based on public adoption and transparency signals as of October 16, 2026. Our opinion, not a code audit or security guarantee.
AI agent skill · Developer tools
anti-slop
Opinionated Oxlint rules for rejecting low-evidence TypeScript and JavaScript patterns
Bottom line: Signal-based grade (4/7 points): very widely starred on GitHub, public source code. This reflects adoption and transparency, not a code review.
- Popularity score
- 42/100
- Rank
- #264 of 500
- GitHub stars
- 5.6k
What it does
Anti-slop provides opinionated Oxlint rules that catch low-evidence TypeScript and JavaScript patterns—like loose comparisons, missing error handling, and other footguns—to improve code quality. It acts as a linter configuration that helps teams enforce stricter coding standards and reduce common mistakes.
Who it’s for
TypeScript and JavaScript developers, platform teams, and engineering leads who want to enforce higher code standards and reduce technical debt. Best suited for teams already using Oxlint and willing to adopt stricter linting practices.
Copy-paste setup
Check these steps against the project’s own instructions before running anything.
Follow the setup steps in the project’s official README: https://github.com/dmmulroy/anti-slop (opens external site)
Risks
- False positives: Opinionated rules may flag valid patterns, slowing development if misconfigured for your codebase
- Maintenance lag: Low weekly adoption (0 npm downloads recorded) may indicate slower issue response and rule updates
- Supply-chain trust: Single maintainer with no obvious governance model; review rule logic before enforcing on critical paths
- No data exfiltration vector: Runs locally as a linter; does not phone home or collect telemetry (verify in source)
How to stay secure
Least-privilege permissions
- Restrict rule enforcement scope: Apply anti-slop only to specific project folders or file types rather than your entire codebase; this prevents overly strict checks from blocking legitimate work
- Control who can modify rules: Only senior developers or architects should be able to change which code patterns are flagged; others can run checks but not adjust them
- Limit CI/CD integration: If using in automated testing pipelines, make anti-slop warnings only in early stages and blocking errors only for critical systems; this balances security without halting all deployments
Network isolation
- Run locally only: Verify anti-slop executes entirely on your developers' machines or build servers with no outbound network calls; check project documentation or source code to confirm no data leaves your network
- Disable any telemetry: If a configuration option exists for usage tracking or error reporting, explicitly disable it
- Air-gap critical builds: For highly sensitive projects, run the linter on machines without internet access to eliminate any theoretical phone-home risk
Monitoring
- Track false positives: Log when developers override or ignore anti-slop warnings; frequent bypasses indicate rules are too aggressive and need adjustment
- Watch for version changes: Since the tool has low usage, subscribe to release notifications and manually review what each update changes; don't auto-update silently
- Audit rule modifications: Keep a record of who changed which code-pattern rules and when, since a single maintainer means less peer review before your team adopts updates
Red flags to watch for
- Unexplained dependency additions: If anti-slop suddenly adds new npm package dependencies, investigate before updating; this could indicate maintainer compromise
- Rules that are too vague: If a rule flags "bad patterns" without clear documentation of why, disable it until the logic is understood
- Unresponsive maintainer: If bug reports or rule requests go unanswered for 2+ months, treat the tool as unsupported and plan a transition to an alternative before critical issues arise
Alternatives
- ESLint + stricter presets (e.g., Airbnb, Standard) – more mature ecosystem, broader community rules
- Biome – unified linter and formatter with opinionated defaults, similar philosophy
- TypeScript strict mode + compiler flags – built-in type safety without external linter
- Knip – specialized for dead-code and unused exports, complements but does not replace anti-slop