← ClaudeAtlas

add-a-linterlisted

Add a new linter to vigiles's cross-referencing engine as one cohesive, type-enforced unit — a LinterAdapter in the LINTERS registry, with the conformance test enforcing docs + site parity so no site is forgotten
zernie/vigiles · ★ 15 · AI & Automation · score 76
Install: claude install-skill zernie/vigiles
Add a linter to vigiles's cross-referencing engine (the `enforce("eslint/...")` moat). This is a **contributor** task, not a third-party extension point: the `LINTERS` registry is a `Record<BuiltinLinter, LinterAdapter>` — a **closed set** baked into core — so a linter is added by editing vigiles itself, and the type system + the conformance test make the parity **un-forgettable**. The whole reason this skill exists: a linter used to be smeared across ~7 scattered sites (existence check, config checker, CLI-tool map, suggestion enumerator, generate-types discoverer, docs, site) with **nothing** enforcing that you touched all of them — miss one and it failed silently. Now `tsc` fails if the registry entry is missing, and `src/core/linter-contract.test.ts` fails if the docs table or the marketing site drifts. **Follow the steps; let the gates catch what you forget.** See `research/linter-adapter-architecture.md`. ## The one invariant A linter is **one `LinterAdapter`** in **one registry**. Everything else — existence, config-enabled, suggestions, type-gen, docs, site — is a field or a method on that adapter, cross-checked by the conformance test. You never again hunt for "the other place this linter is registered." ## Steps Work in this order — each step's gate tells you the next is needed. 1. **Name it (the single source).** Add the lowercase name to `BUILTIN_LINTERS` in `src/core/spec.ts`. `BuiltinLinter` derives from this array, so the moment you save, `tsc` fail