feat(detect): recognize oxlint alongside eslint, biome and stylelint

[theCodeDrift]

What

taskless detect now reports oxlint as a JavaScript/TypeScript linter. A new oxlint entry in LINTER_SIGNALS (packages/cli/src/detect/scan.ts), shaped like biome: config-file presence on disk, or an oxlint dependency in package.json (manifest-only matching honoring the language tag, same as eslint and biome).

Also in this PR:

• Three detect tests: .oxlintrc.json alone detects oxlint; oxlint only in devDependencies detects oxlint; an eslint-only repo still reports eslint and not oxlint.
• OpenSpec change detect-oxlint (single PR shape), archived here: the cli-detect example config list names .oxlintrc.json and a new scenario covers oxlint from either signal.
• .changeset/detect-oxlint.md (patch; pre-1.0, an added signal is not a minor).
• packages/cli/src/agent/detect.md is untouched: it does not enumerate the JS linters, only shows an eslint example in the JSON shape.

Why

A repo that has moved to oxlint reported no JS linter, so detect output and everything downstream (init, the route recipe) treated the project as unlinted. oxlint's plugin model has no cross-file or type-aware seam for third-party rules, so those are exactly the repos where Taskless runtime rules add something the linter cannot.

Config filenames verified against the docs

Source: https://oxc.rs/docs/guide/usage/linter/config.html, which states: "Oxlint automatically looks for a .oxlintrc.json, .oxlintrc.jsonc, oxlint.config.ts, or oxlint.config.mts in the current working directory."

Included (the auto-discovered set):

• .oxlintrc.json
• .oxlintrc.jsonc
• oxlint.config.ts
• oxlint.config.mts

Excluded: oxlint.config.js, oxlint.config.mjs, oxlint.config.cjs. The issue suggested these, but the docs only accept a JS-extension path when it is passed explicitly with -c/--config ("any path with a JS/TS extension (.js, .mjs, .cjs, .ts, .mts, .cts) is accepted"); oxlint never discovers them on its own, so the filename is dead weight in the sweep. The JS plugins page (https://oxc.rs/docs/guide/usage/linter/js-plugins.html) only ever shows .oxlintrc.json and oxlint.config.ts. The comment on the signal entry records this so the next person does not re-add them.

How verified

• pnpm openspec validate detect-oxlint --strict passes.
• CLAUDE.md dry-run archive check: grep '^#### Scenario' openspec/specs/cli-detect/spec.md before (9) vs after (10); the only diff is the added oxlint scenario, every prior scenario survives and the requirement title is byte-identical. Then archived for real.
• pnpm build, pnpm typecheck, pnpm lint (including taskless check on the rebuilt CLI), pnpm --filter @taskless/cli test (94 files, 1531 tests) all pass.

Fixes #349

[theCodeDrift]

@claude /review

[claude]

Claude finished @theCodeDrift's task in 1m 43s —— View job

---

Review mode: incremental — read 0 prior review thread(s) before reviewing.

.prior-review.json contains no reviewThreads, reviews, or comments other than the @claude /review trigger itself, so there is nothing previously raised to classify. This is the first review of this PR — the full diff was assessed from scratch.

• Read .prior-review.json
• Fetch PR diff and metadata (gh pr diff, gh pr view)
• Read packages/cli/src/detect/scan.ts in full, plus detect.test.ts, the spec deltas, and the OpenSpec archive
• Cross-check downstream consumers (commands/detect.ts, agent/detect.md, agent/route.md, agent/create-legacy-rule.md) for any hardcoded linter enumeration the new signal should have joined
• Verify the MODIFIED Requirements delta restates every prior scenario (per this repo's CLAUDE.md archive-fidelity rule)
• Post findings

Assessment

I found nothing to flag. This is a small, well-scoped addition that follows the existing biome pattern exactly:

• packages/cli/src/detect/scan.ts: the new oxlint LinterSignal (config files + deps: ["oxlint"]) is structurally identical to biome's entry, correctly tagged with languages: ["JavaScript", "TypeScript"] so the dependency lookup is scoped to nodeManifests via the existing servesNode branch — no special-casing needed.
• Config filenames match what's claimed in the PR description and verified against oxc.rs's docs (.oxlintrc.json, .oxlintrc.jsonc, oxlint.config.ts, oxlint.config.mts); the excluded oxlint.config.{js,mjs,cjs} variants are correctly reasoned about (only reachable via explicit -c, so listing them would be dead weight) and the comment on the entry records why, so a future contributor won't re-add them.
• Checked callers/consumers for a hardcoded linter enumeration that would now be inconsistent: commands/detect.ts just forwards detectRepository's result; agent/detect.md and agent/route.md only show a single illustrative eslint example (not an enumeration); agent/create-legacy-rule.md lists a few example configs but doesn't enumerate biome either, so this PR doesn't introduce a new inconsistency there.
• OpenSpec archive fidelity: diffed openspec/specs/cli-detect/spec.md before/after — the MODIFIED Requirements block in the archived delta restates all 6 prior scenarios verbatim plus the 1 new oxlint scenario (7 total, matching the PR's claimed 9→10 count for the whole requirement file). Nothing was silently dropped.
• Changeset is patch on a 0.y.z package for an added signal — correct per this repo's semver guidance.
• Tests cover the three cases described in the PR body (config-only, dep-only, eslint-only-repo-negative) and follow the existing one-test-per-signal-style convention used for the other linters in this file (e.g. biome, stylelint also get a single representative test each, not one per config filename), so the lighter coverage of the other three config filenames (.oxlintrc.jsonc, oxlint.config.ts, oxlint.config.mts) is consistent with how this test file already treats every other multi-filename signal, not a gap specific to this change.

No correctness, security, performance, or clarity issues found in the diff.

[theCodeDrift]

Re: @claude[bot] — "Claude finished @theCodeDrift's task in 1m 43s … I found nothing to flag."
#353 (comment)

Acknowledged: review found no correctness, security, performance, or clarity issues; no changes needed.

— AI Coding Agent