lint

Make the files the user touched pass the repo's linters and formatters, and set those tools up where the repo has none. The repo's config and scripts are the rules: this skill runs them and leaves their choices alone unless the user decides otherwise at a gate.

• On its own (/lint): use the interview mode and round format from implement. Open each gate with Lint · Step N · Round k.
• Inside another skill (implement, ado-implement, pr-review): use that skill's mode, and fold this skill's gates into its current round.

Controls: take the merged lint controls from the calling skill, or read them with controls.sh lint --ref origin/<base> (CONTROLS.md). They set the scope (LINT-01), what must pass (LINT-02, LINT-03), how a suppression looks (LINT-04), and the baselines (LINT-10 to LINT-12). List any the repo turned off in the first round.

Scope is the touched files: changed against the base branch (git diff --name-only --diff-filter=d origin/<base>...HEAD) plus uncommitted ones (git status --porcelain). Lint the whole repo only when the user asks or the repo's LINT-01 says so.

1. Detect and check

Dispatch the Lint Runner subagent with the repo root, the base ref, the scope's file list, and the merged lint controls. In clients without that agent, dispatch a general subagent whose prompt is the body of lint-runner, followed by the same inputs. It runs in check mode and returns the repo's tools and commands, anything it couldn't run, and the findings sorted into auto-fix, code change, and rule question. Keeping that output in the subagent keeps long lint logs out of the conversation.

A Not run entry is a tool problem: show its error and fix it with the user, installing anything missing on their yes, then dispatch again.

Done when the runner returns with nothing under Not run.

2. Set up

Only for pieces the runner marked none.

Gate: for each missing piece, the baseline its setup control names (LINT-10 to LINT-12); SETUP.md shows how to set up the defaults. Where the repo overrides a setup control, set up what the override names. List the files to add, packages to install, scripts to define, and the options. The user can decline a piece; it stays none and goes in the report.

After installing, dispatch the runner with the scope whole repo and report its counts. When existing code produces many findings, recommend landing the setup as its own PR before the feature work, or the gentler starting level that SETUP.md names.

Done when every none piece is set up or declined.

3. Fix

Gate: the runner's count in each group, the auto-fixes to apply, the code changes you propose, and one question per rule question.

• Auto-fixes: run the runner's fix commands on the scope.
• Code changes: edit by hand, then rerun the tests that cover the edit.
• Rule questions: on the user's yes, suppress as LINT-04 requires, for example: // eslint-disable-next-line <rule> -- <reason>, // biome-ignore <rule>: <reason>, a #pragma warning disable <ID> // <reason> and restore pair, or [SuppressMessage("<category>", "<ID>", Justification = "<reason>")]. Changing a rule's severity in config affects the whole repo, so ask it as a separate question.

Dispatch the runner again after each batch. Done when it returns clean.

4. Report

A table per stack: each check command, its result, and the counts fixed and suppressed, plus any piece left none. Offer to add missing check commands to CI, as a local edit on the user's yes.

In teach mode, link each rule you fixed or suppressed to its documentation: https://eslint.org/docs/latest/rules/<rule>, https://typescript-eslint.io/rules/<rule>, https://biomejs.dev/linter/rules/<rule>, https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/<caXXXX> for CA rules, and …/code-analysis/style-rules/<ideXXXX> for IDE rules.