lintlisted

# adr-kit lint You are running `/adr-kit:lint`. The user wants to know whether existing ADRs in their project pass the four verification gates that the main `adr` skill enforces. You read files; you do not modify them. You report. ## Inputs - **No argument**: lint every `docs/adr/ADR-*.md` file in the project root. - **A directory path**: lint every `ADR-*.md` file under that directory. - **A file path**: lint that one file. If the user passed something else (a glob, a non-existent path), explain politely and stop. ## Configuration (since v0.9.0) Established projects often have a long history of ADRs that predate the four canonical gates. Linting them under strict rules produces noise rather than actionable feedback. Two opt-in mechanisms let a project apply the gates surgically: strict on new ADRs, advisory on legacy ones. ### Mechanism 1: project-level config file Before linting, look for `docs/adr/.adr-kit.json` (relative to the project root, or to the directory passed as argument if the user pointed elsewhere). If it exists, read it and apply it as policy. If it does not exist, fall back to default behaviour (everything strict, exact match to v0.7.x output). Recognised fields: - `strict_from` (string, optional): first ADR identifier (inclusive) on which all gates are enforced strictly. ADRs with a numerically lower number are linted in *advisory* mode for the gates that opt in (see `severity`). Format: `ADR-XXX` matching the filename pattern. Example: `"ADR-082"