From mateonunez-skills
Enforces 'one tool per job' policy in JS/TS projects: Biome for lint/format over ESLint/Prettier, tsc for types, node:test for tests, pnpm for packages. Activates when adding dev tooling or mentioning Biome/ESLint/Prettier.
npx claudepluginhub mateonunez/skillsThis skill uses the workspace's default tool permissions.
> Music on; nonsense off.
Guides Next.js Cache Components and Partial Prerendering (PPR): 'use cache' directives, cacheLife(), cacheTag(), revalidateTag() for caching, invalidation, static/dynamic optimization. Auto-activates on cacheComponents: true.
Processes PDFs: extracts text/tables/images, merges/splits/rotates pages, adds watermarks, creates/fills forms, encrypts/decrypts, OCRs scans. Activates on PDF mentions or output requests.
Share bugs, ideas, or general feedback.
Music on; nonsense off.
Tooling sprawl is debt. ESLint + Prettier + import-sort plugin + sort-keys plugin is four tools doing what Biome does in one — four config files, four peer-dependency trees, four editor extensions, four CI steps, four ways to break.
I don't pay that tax. Biome is enough.
You are about to:
package.jsonIn my repos, Biome is the linter and the formatter. Both jobs. Together. There is no "Biome alongside ESLint", no "Biome but Prettier for Markdown". If eslint, prettier, eslint-*, or prettier-* shows up in a pnpm add you're proposing, the answer is no.
If a repo I'm in already has ESLint or Prettier (legacy work, third-party fork), the migration is its own task — surface it, propose it, but don't run two linters at once "for safety". Two linters at once is the worst of both worlds: contradictory autofixes and double the CI time.
This is the one place in single-tool-per-job where the rule isn't "prefer the existing tool" — it's "Biome wins".
| Job | My tool | Don't add |
|---|---|---|
| Lint + format + import sort | Biome | ESLint, Prettier, eslint-*, prettier-*, simple-import-sort |
| Types | tsc | Babel for type-stripping, Flow |
| Tests | node:test + borp + c8 | Jest, Vitest, Mocha, Chai, Sinon, @types/jest, nyc |
| Packages + workspaces | pnpm (via corepack) | npm, yarn, lerna, nx for workspace orchestration alone |
| Pre-commit | biome check --staged | husky + lint-staged + prettier + eslint chain |
| Build (TS lib) | tsdown or tsc --build | rollup + plugins + tsup + babel |
| Run TS scripts | node --experimental-strip-types (22.6+) or tsx | ts-node + @types/node + esbuild-register |
For tools other than ESLint/Prettier, the principle is "don't migrate unprompted" — see result-not-throw. New additions to the repo follow this table; existing Jest/Mocha setups don't get rewritten as a side effect.
biome lint . # lint only
biome format . # format only
biome check . # lint + format + organize imports
biome check --write . # auto-fix safe transforms
biome check --write --unsafe # auto-fix including unsafe
biome ci . # CI-optimised output
biome check --staged # pre-commit
// package.json
{
"scripts": {
"lint": "biome check .",
"lint:fix": "biome check --write ."
}
}
For the full biome.json template, see setup-mateonunez-skills/seeds/seed-biome-2x.json.
Before pnpm add -D <thing>:
package.json already responsible for that job? If yes, replacement only — not addition.node:test, node:assert, Intl), the new tool needs to justify why the standard isn't enough.If it doesn't hold up against those four, it doesn't make the cut.
.md files we'll keep Prettier" / "Just for the legacy package we'll keep ESLint". Carve-outs become permanent. Pick one, retire the other.biome check --staged works. Two tools to do what one does.nx to a small monorepo for caching. pnpm + --filter covers it. Reach for nx/turbo only when build times actually hurt.find . -name '*.ts' | xargs ... works, no tool needed.Some pairings are fine because the jobs are different: Biome (lint/format) + tsc (types) + node:test (tests). The rule isn't "one tool total" — it's "one tool per job". Type-checking is not formatting; testing is not linting.