Bundled rulesets
alint ships 22 bundled rulesets compiled straight into the binary, with no network round-trip. They are the on-ramp: instead of hand-writing rules, you add one extends: line and inherit a curated set, from oss-baseline (a Repolinter migration starting point) to per-language, monorepo, CI, hygiene, compliance, and agent-aware sets. Two properties make them safe to adopt broadly: every rule is fact-gated, so a ruleset applies itself only where it belongs, and everything it declares is overridable field-by-field from your own config.
What they are
Section titled “What they are”The 22 sets fall into a few families: oss-baseline (the migration starting point for the archived Repolinter); seven language sets (rust, python, node, go, java, php, dotnet); a monorepo base with Cargo, pnpm, and Yarn workspace overlays; ci/github-actions; tooling/editorconfig; hygiene sets (hygiene/lockfiles, hygiene/no-tracked-artifacts); compliance (compliance/reuse, compliance/apache-2) and apache/governance; docs/adr; and the two agent-aware sets (agent-context, agent-hygiene). Each is a hand-curated group of rules, compiled into the binary, referenced as alint://bundled/<name>@v1. alint init scaffolds a starting config for you: it always extends oss-baseline and adds a language set for each stack it auto-detects (Rust, Node, Python, Go, or Java). The php and dotnet sets ship too but are not auto-detected, so add those to extends: by hand.
Fact-gating
Section titled “Fact-gating”The reason you can extend a language set without worrying whether it fits: each rule inside carries a when: gate over a per-run fact. rust@v1’s rules are when: facts.has_rust, so extending it in a repo with no Rust is a silent no-op, not a wall of irrelevant findings. Adopt the whole set and it activates itself where it applies. This is why oss-baseline plus every language set is a reasonable default: the gates keep each one dormant until its stack shows up. In a polyglot monorepo the gating goes one level finer: a language set’s per-file rules also carry a scope_filter: { has_ancestor: <manifest> }, so rust@v1’s rules fire only inside a directory that actually contains a Cargo.toml, never across an unrelated package.
Adopting and overriding
Section titled “Adopting and overriding”Add the sets you want to extends:, then tune them in your own config. A rule you inherit is overridden field-by-field by id: name the same id and set just the fields you want to change (a level, a path, a message), and the rest of the rule stays as the bundle defined it, exactly like config layering merges a drop-in. What a bundled ruleset does not gain is extra execution privilege: reached through extends:, it sits below the same trust boundary as any fetched ruleset, so it cannot declare spawning rules, custom: facts, allow_out_of_root, or a baseline any more than a remote one can. What it gains instead is provenance: shipping in the binary, it resolves offline and is byte-identical to the release, with nothing to fetch or hash-pin.
In practice
Section titled “In practice”Extend the OSS baseline and the Rust set, and downgrade one inherited rule to a warning while a repo catches up:
version: 1extends: - alint://bundled/oss-baseline@v1 - alint://bundled/rust@v1rules: - id: readme-exists level: warningalint list shows the union of the inherited rules with your override applied; alint check runs the Rust rules only if the tree actually has Rust.
Going deeper
Section titled “Going deeper”- Bundled rulesets reference documents every ruleset and the rules it contains.
- Composition and trust is the
extends:merge and trust boundary in depth. - Config layering is how overrides and drop-ins assemble one effective config.