lintinglisted

# Linting Fix machine-detectable code issues — run the project's linters and static analyzers, resolve or justifiably suppress findings, and tighten config so real issues surface and noise dies down. This is the automated quality gate, not a substitute for human review. ## When to use - Fixing a failing lint/static-analysis gate in CI or a pre-commit hook - Tightening lint rules — turning on stricter rules, removing broad ignores, paying down `eslint-disable` debt - Running static analysis (type checkers, security linters, complexity analyzers) and triaging findings - Establishing lint config for a new project or after a toolchain migration - Triggers on "lint", "linting", "fix eslint", "static analysis", "lint 修复", "静态分析", "格式检查", "代码规范检���" **Not for:** human-judgment review of a diff — smells, spec faithfulness, design (use `code-review`); diagnosing runtime behavior bugs (use `debugging`); behavior-preserving structural moves like extracting or splitting modules (use `refactoring`). ## Steps ### 1. Detect the toolchain Read the project before running anything. Don't impose a linter the project doesn't use. - Find lint config and scripts: `package.json` (`lint` script, `eslint`/`biome`/`prettier` config), `pyproject.toml`/`setup.cfg` (`ruff`/`flake8`/`mypy`), `Cargo.toml` (`clippy`), `.golangci.yml`, `.editorconfig`. - Find the CI gate — what command does CI actually run? Lint locally with the same command, or you'll fix issues CI doesn't see and miss issues CI blo