Biome Anti Slop
Install and configure vendored Biome anti-slop GritQL rules in a local TypeScript or...
Install
npx skills add nightly-labs/openbot --skill biome-anti-slop -g -a claude-code -y- Repository
- nightly-labs/openbot4.5k
- Category
- Engineering
- Updated
- 3d ago
- License
- See repository
- Context cost
- Lightabout 1,397 tokens
- Runs scripts
- Yes, review before use
What it does
Install and configure vendored Biome anti-slop GritQL rules in a local TypeScript or JavaScript repository. Use when a user asks to add, configure, update, or migrate Biome anti-slop lint rules.
Biome anti-slop
Vendor the bundled rules into the current repository and integrate them with its existing Biome setup. Preserve unrelated work and adapt to the repository's package manager and configuration.
Install
-
Inspect the repository before changing it:
- Read applicable agent instructions and check
git status. - Detect the package manager from
packageManagerand lockfiles. - Find
biome.jsonorbiome.jsoncfiles and existing anti-slop rules. - If multiple independent Biome roots exist, ask which one to configure.
- Read applicable agent instructions and check
-
Require
@biomejs/biomeversion>=2.5.9 <3. Preserve an existing dependency in that range. If Biome is absent from a package manifest, install the latest compatible 2.x release using@biomejs/biome@^2.5.9as a development dependency with the repository's package manager. If the repository uses a version outside that range, stop and ask before changing it. -
From the target repository, copy the bundled rules:
node <skill-directory>/scripts/install.jsThe default destination is
tools/biome/anti-slop. Pass another relative destination as the first argument when the repository has an established tooling layout. The installer refuses to replace an existing destination; use--forceonly after reviewing the existing files and the replacement diff. -
Register the installed rules. Do not type the rule names from memory or from this file. The installer prints two lists, read from the
// scope:line each rule declares, so they cannot go stale as rules are added, merged, or removed:- the
globallist goes in the top-levelpluginsarray; - the
testslist goes in apluginsarray on anoverridesentry matching**/*.test.tsand**/*.test.tsx, because those patterns are legitimate in product code and only wrong in a test.
Add them without removing existing plugins.
- the
