/lint

name: lint
description: "Runs linter+typechecker with auto-detected toolchain (ruff/mypy, eslint/tsc, phpstan, golangci-lint, clippy). Triggers: lint, typecheck, static analysis."
effort: low
disable-model-invocation: true
argument-hint: "[path]"
allowed-tools: Bash, Read

Lint Runner

$ARGUMENTS

Run linting and type checking based on detected project type.

Project context

• Project files: !`ls pyproject.toml package.json composer.json pubspec.yaml go.mod 2>/dev/null`

Auto-Detection

Run the bundled script to detect available linters:

python3 ${CLAUDE_SKILL_DIR}/scripts/detect-linters.py .

Usage

/lint [path]

Commands by Project Type

| Project Type | Lint Command | Type Check | |--------------|--------------|------------| | **Python** | `ruff check .` | `mypy .` | | **TypeScript/Node** | `npx eslint .` | `npx tsc --noEmit` | | **PHP** | `./vendor/bin/phpstan analyse` | - | | **Go** | `golangci-lint run` | - | | **Rust** | `cargo clippy` | - | | **Flutter/Dart** | `dart analyze` | - |

Python Projects

# Linting
ruff check .

# Type checking
mypy .

# Auto-fix
ruff check --fix .
ruff format .

TypeScript/Node Projects

# Linting
npx eslint .

# Type checking
npx tsc --noEmit

# Auto-fix
npx eslint --fix .

PHP Projects

# Static analysis
./vendor/bin/phpstan analyse

# Code style
./vendor/bin/phpcs
./vendor/bin/phpcbf  # auto-fix

Docker Execution (if applicable)

# Generic pattern - replace {container} with your app container
docker exec {container} make lint
docker exec {container} make typecheck

Quality Gates

• Linting: 0 errors
• Type checking: 0 errors (for new code)

Common Issues

| Error | Fix | |-------|-----| | Missing type hints | Add type annotations | | Unused imports | Remove or use `# noqa: F401` | | Line too long | Break line or disable for that line | | Import order | Let linter fix with `--fix` |

Rules

• **MUST** auto-detect the linter from project config (`pyproject.toml`, `package.json`, `.eslintrc.*`, `composer.json`, `go.mod`, `Cargo.toml`, `pubspec.yaml`) — do not assume
• **MUST** show the diff before applying any `--fix` run; the user owns the decision to accept auto-fixes
• **NEVER** suppress lint errors with blanket `# noqa` or `eslint-disable-next-line` without naming the specific rule and a reason
• **NEVER** run the formatter (ruff format, prettier, dprint) inside a lint pass unless the project has that wired explicitly — formatting and linting are separate concerns
• **CRITICAL**: report the error count **before and after** any auto-fix — delta visibility is what makes the run trustworthy
• **MANDATORY**: respect the project's lint config (`.ruff.toml`, `eslint.config.js`, `phpstan.neon`) — overriding project rules on the fly produces arguments during code review

Gotchas

• `ruff check .` and `ruff format .` are **separate** commands in modern ruff (>0.1.0). Running only `ruff check` misses formatting drift; some repos expect both as part of "lint".
• `mypy` without `--strict` has a permissive default: missing annotations count as `Any`, so the type checker silently accepts untyped functions. Check whether the project pins `strict = true` in `pyproject.toml` before declaring "0 type errors".
• `eslint` follows `eslint.config.js` (flat config, ESLint 9+) OR `.eslintrc.*` (legacy). Mixing produces mysterious "no rules applied" errors. Check ESLint version first (`npx eslint --version`).
• `phpstan` levels (0-10) silently affect which rules apply. A repo at level 5 has different expectations than level 9; report the level alongside the error count.
• `golangci-lint` composes many linters; disabling one at the project level may still show its warnings if invoked with `--enable-all` flag. Check `.golangci.yml` before treating a warning as a new regression.
• Dart analyze reports on **all** files including generated `*.g.dart`. Some projects expect generated files to be excluded via `analysis_options.yaml`; without it, lint noise dominates real issues.

When NOT to Use

• To **fix** the errors — use `/fix` after this skill surfaces them
• To run tests — use `/test`
• For code review of logic and design — use `/review`
• For security-specific static analysis (SAST) — use `/cve-scan` or `/security-patterns`
• For project-specific rule authoring — edit the linter's config directly