taskless detect recognizes eslint, biome and stylelint for JavaScript and TypeScript, but not oxlint. A repo that has moved to oxlint reports no JS linter, so the detect output (and everything downstream that reads it, like init and the agent recipes) treats the project as unlinted.
What to add
A new entry in LINTER_SIGNALS in packages/cli/src/detect/scan.ts, shaped like the biome one:
{
name: "oxlint",
languages: ["JavaScript", "TypeScript"],
configFiles: [".oxlintrc.json", "oxlint.config.js", "oxlint.config.mjs", "oxlint.config.cjs", "oxlint.config.ts"],
deps: ["oxlint"],
},
Per the oxlint docs (https://oxc.rs/docs/guide/usage/linter), .oxlintrc.json is the primary config file. The oxlint.config.* forms cover the JS plugin config introduced with the JS Plugins alpha; confirm against the current docs which of those oxlint actually loads before committing the list, since a config filename that never exists is dead weight in the sweep.
Dependency evidence: oxlint in package.json (devDependencies in practice). Same manifest-only matching as eslint and biome, honoring the language tag.
Also touch
openspec/specs/cli-detect/spec.md: add .oxlintrc.json to the example list in "Linter configs are detected from disk"
packages/cli/src/agent/detect.md if it enumerates the JS linters
- Fixtures: a repo with only
.oxlintrc.json detects oxlint; a repo with oxlint only in devDependencies detects oxlint; an eslint repo is unchanged
Why now
oxlint is where a growing share of JS repos are heading for the static tier, and its plugin architecture cannot do cross-file rules (custom plugins never get a type checker; type-aware rules run in a separate tsgolint binary with no seam for third-party rules). That makes an oxlint repo exactly the kind of project where Taskless runtime rules add something the linter cannot, so detect needs to see it.
taskless detectrecognizes eslint, biome and stylelint for JavaScript and TypeScript, but not oxlint. A repo that has moved to oxlint reports no JS linter, so the detect output (and everything downstream that reads it, likeinitand the agent recipes) treats the project as unlinted.What to add
A new entry in
LINTER_SIGNALSinpackages/cli/src/detect/scan.ts, shaped like thebiomeone:Per the oxlint docs (https://oxc.rs/docs/guide/usage/linter),
.oxlintrc.jsonis the primary config file. Theoxlint.config.*forms cover the JS plugin config introduced with the JS Plugins alpha; confirm against the current docs which of those oxlint actually loads before committing the list, since a config filename that never exists is dead weight in the sweep.Dependency evidence:
oxlintinpackage.json(devDependenciesin practice). Same manifest-only matching as eslint and biome, honoring the language tag.Also touch
openspec/specs/cli-detect/spec.md: add.oxlintrc.jsonto the example list in "Linter configs are detected from disk"packages/cli/src/agent/detect.mdif it enumerates the JS linters.oxlintrc.jsondetects oxlint; a repo withoxlintonly indevDependenciesdetects oxlint; an eslint repo is unchangedWhy now
oxlint is where a growing share of JS repos are heading for the static tier, and its plugin architecture cannot do cross-file rules (custom plugins never get a type checker; type-aware rules run in a separate
tsgolintbinary with no seam for third-party rules). That makes an oxlint repo exactly the kind of project where Taskless runtime rules add something the linter cannot, so detect needs to see it.