Quality Tools

Provide standardized tool definitions and usage patterns for code quality verification. This skill centralizes tool knowledge that was previously duplicated across agents. JavaScript/TypeScript linter for code quality and style eslint [files] eslint --fix [files] eslint --format=json [files] Check code style, find potential bugs, enforce coding standards</use_case> Error/warning count, file locations, rule violations Code formatter for consistent style prettier --check [files] prettier --write [files] Ensure consistent code formatting</use_case> List of files that need formatting (check mode) TypeScript type checker tsc --noEmit tsc -p tsconfig.json --noEmit Type checking, finding type errors</use_case> Type errors with file:line locations Go language quality tools go fmt ./... go vet ./... golangci-lint run Go code formatting and static analysis</use_case> Rust language quality tools cargo fmt --check cargo clippy cargo check Rust code formatting and linting</use_case> Nix language quality tools nixfmt [files] nix flake check statix check Nix code formatting and validation</use_case> Python language quality tools black [files] ruff check [files] mypy [files] Python code formatting, linting, and type checking</use_case> Standard workflow for quality verification 1. Run type checker (tsc, mypy, etc.) 2. Run linter (eslint, clippy, etc.) 3. Run formatter check (prettier, black, etc.) 4. Report findings with locations Workflow for automatic fixes 1. Run formatter (prettier --write, cargo fmt) 2. Run linter with fix (eslint --fix) 3. Verify with check commands 4. Run tests to confirm no regressions Check only changed files 1. Get list of changed files (git diff --name-only) 2. Filter by file type 3. Run quality tools on filtered list Types of lint rules and their purposes Error prevention: Catch potential bugs Best practices: Enforce coding standards Style: Consistent formatting Security: Detect vulnerable patterns Which fixes are safe to auto-apply Safe: Formatting, import sorting, simple style fixes Review needed: Complex refactors, logic changes Manual only: Security issues, breaking changes Standard exit codes for quality tools 0: Success, no issues 1: Issues found 2: Configuration or execution error Run type checker before linter for faster feedback Verify with tests after auto-fixes Use project-specific configuration when available Report all issues with file:line locations Run incremental checks for large codebases Separate formatting from logic changes in commits </best_practices> Auto-fixing without reviewing changes Review auto-fix changes, run tests after Only addressing errors, ignoring warnings Address warnings that indicate potential issues Running linter without type checking first Run type checker first for faster feedback loop </anti_patterns> What type of quality check is needed? Use language-specific type checker (tsc, mypy, cargo check) Use linter (eslint, clippy, ruff) Use formatter (prettier, black, cargo fmt) Run in sequence: types → lint → format </decision_tree> Run quality checks before marking implementation complete Report findings with file:line locations Use project configuration when available Auto-fixing without test verification Ignoring type errors Running only subset of quality tools Run tests after quality fixes Integration with implementation workflow </related_skills>