dmmulroy/anti-slop

Opinionated Oxlint rules for rejecting low-evidence TypeScript and JavaScript patterns

View on GitHub ↗Jump to charts ↓Open shareable report

Summary Information

Updated 52 minutes ago
Added to GitGenius on September 15th, 2026
Created on August 12th, 2026
Open Issues & Pull Requests: 4 (+0)
GitHub issues: Enabled
Number of forks: 105
Total Stargazers: 4,667 (+0)
Total Subscribers: 8 (+0)

Repository Insights (GitGenius)

Median issue/PR response: 37.3 hours
Mean response time: 4.5 days
90th percentile: 11.2 days
Tracked items: 33

Most active contributors

Sign in to see contributor activity.

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

Open issues: 2
New in 7 days: 1
Closed in 7 days: 0
Avg open age: 2 days
Stale 30+ days: 0
Stale 90+ days: 0

Recent activity

Opened in 7 days: 1
Closed in 7 days: 0
Comments in 7 days: 0
Events in 7 days: 0

Top labels

  • bug (12)
  • enhancement (5)
  • documentation (2)
  • duplicate (2)
  • question (1)

Most active issues this week

No issue events were indexed in the last 7 days.

Detailed Description

Anti-slop is a linting ruleset for Oxlint that enforces opinionated patterns in TypeScript and JavaScript code.

The tool addresses the problem of low-evidence and low-signal coding patterns by providing a curated set of Oxlint rules designed to catch patterns the maintainer considers problematic. It works by integrating into Oxlint's plugin system, allowing developers to apply these rules to their codebases either through an agent skill that handles installation and configuration, or through manual setup by copying the source into a repository and registering the entry point in an Oxlint configuration file.

Adoption suits teams that want to adopt the maintainer's specific coding preferences rather than seeking a universal standard. The project explicitly positions itself as opinionated and meant to be vendored into repositories rather than consumed as a fixed dependency, allowing teams to copy the rules, review them, and modify them to match their own standards. The tool includes generic rules applicable to any TypeScript or JavaScript project, plus optional Effect-specific rules for repositories using the Effect library. The agent skill automates initial installation, dependency matching, and configuration merging, while also supporting updates that preserve local customizations through three-way merging when possible.

The project maintains clear separation between generic and Effect-specific rules so teams not using Effect do not inherit unrelated architectural policies. Installation can proceed either through the agent skill, which handles dependency resolution and configuration integration automatically, or manually by copying source files and registering entry points. The update mechanism is designed to respect local modifications, staging incoming changes separately and asking about conflicts rather than forcing replacements.

Development activity shows active maintenance of the vendoring workflow, with the agent skill regularly updated to handle installation, configuration merging, and preservation of local customizations. The project includes tooling for three-way merging of updates when upstream snapshots are recoverable, and conservative porting of changes when they are not. Documentation covers both agent-driven and manual installation paths, and the codebase includes infrastructure for managing version alignment between Oxlint and its plugins across different repository states.