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