quality-tools

name	Quality Tools
description	Tool definitions and usage patterns for code quality tools (ESLint, Prettier, tsc, linters), plus a language-neutral catalog of cohesion-raising refactor operations and a skeleton for multi-dimensional scored reviews. Agents reference this skill instead of inline tool definitions.
version	2.1.0

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 (ESLint 10, flat config only) eslint [files] eslint --fix [files] eslint --format=json [files] Flat config only (eslint.config.js/ts). Use defineConfig() and globalIgnores(). eslintrc format is fully removed. Config is resolved from each linted file's directory, not cwd. Check code style, find potential bugs, enforce coding standards Error/warning count, file locations, rule violations Code formatter for consistent style prettier --check [files] prettier --write [files] Ensure consistent code formatting List of files that need formatting (check mode) TypeScript type checker (TS 6.0 stable, TS 7.0 native preview available) tsc --noEmit tsc -p tsconfig.json --noEmit Type checking, finding type errors Type errors with file:line locations Go language quality tools (Go 1.26) gofmt -l [files] go vet ./... staticcheck ./... Go code formatting and static analysis Rust language quality tools (edition 2024) cargo fmt --check cargo clippy cargo check Rust code formatting and linting Nix language quality tools (nixfmt-rfc-style is the standard formatter) nixfmt [files] nix flake check statix check Nix code formatting and validation Unified linter and formatter for JS/TS/JSON/CSS (alternative to ESLint+Prettier) biome check [files] biome check --fix [files] biome format [files] biome lint [files] biome.json configuration file. Supports linting + formatting in a single pass with 10-100x faster performance than ESLint+Prettier. All-in-one code quality for JS/TS projects; preferred when ESLint plugin ecosystem is not required Error/warning count, file locations, rule violations PHP language quality tools (PHP 8.5+) phpstan analyse php-cs-fixer fix [files] pest --parallel PHP static analysis, formatting, and testing Haskell language quality tools (GHC 9.14) fourmolu -i [files] hlint [files] cabal build --ghc-options="-Wall -Werror" Haskell code formatting, linting, and type checking C/C++ quality tools (C23, C++26) clang-format -i [files] clang-tidy [files] C/C++ formatting and static analysis Swift language quality tools (Swift 6.3) swift-format format -i [files] swiftlint [files] Swift code formatting and linting Python language quality tools (ruff is the dominant linter/formatter, replacing flake8, black, isort) ruff format [files] ruff check [files] ruff check --fix [files] mypy [files] Python code formatting, linting, and type checking 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 Standard workflow for quality verification 1. Run type checker (tsc, mypy, etc.) 2. Run linter (eslint, clippy, etc.) 3. Run formatter check (prettier, ruff format, etc.) 4. Report findings with locations Workflow for automatic fixes 1. Run formatter (prettier --write, ruff format, cargo fmt) 2. Run linter with fix (eslint --fix, ruff check --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

<refactoring_operations> A catalog of language-neutral operations that raise cohesion and testability. Each is a bounded, behavior-preserving move; apply the smallest one that addresses the finding rather than a broad rewrite.

Move display-derivation logic (the branching that decides what to show) out of a view or component into a pure selector or "data" helper, leaving the view render-only. A component mixes decision logic with rendering, so it cannot be tested without rendering it. The pure helper is unit-testable in isolation; the view composes or renders frames without embedding decisions. A component is legitimately render-only only once such a pure selector exists. Replace a thin re-export module (a barrel or index) with direct imports from the concrete modules. A file exists only to re-export other modules and adds an indirection layer without any behavior. Point each consumer at the concrete module it actually needs. Once no consumer imports the barrel, delete it. Separate wiring (state, transport, lifecycle) from implementation (the actual computation) by extracting the implementation into a focused helper module. A hook, handler, or service function grows because it both wires dependencies and performs complex logic. Extract complex callback logic from a hook into a helper, keeping only state wiring in the hook file. Keep transport-level handlers thin and move stream piping or payload-to-event mapping into a dedicated helper. Split a complex command into data-only spec helpers, a parse helper that returns explicit values, and a thin orchestrator that only validates and dispatches. Run the targeted test file and the type or compile check for the touched package after each extraction; behavior must be unchanged.

<scored_review> Output skeleton for a multi-dimensional quality review (performance, documentation, or general design). It turns a diffuse "review" into a prioritized, actionable report. Score each dimension separately on a fixed scale (for example N dimensions each out of 100) with a one-line status per dimension, so weak areas stay visible rather than being averaged away. Separate findings into Critical (must fix before release) and Quick Wins (high impact, low effort), each with an effort estimate. Sequence remediation into phases (for example reliability first, then performance, then testing, then advanced), so the report reads as a rollout plan rather than a flat list. State the analysis's basis and its limits: an architectural or static review is not runtime measurement. Do not present estimated improvements or scores as measured results. Give an explicit confidence level and its known limitations (what was not exercised: real workloads, low-resource systems, actual profiling). </scored_review>

<decision_tree name="tool_selection"> What type of quality check is needed? Use language-specific type checker (tsc, mypy, cargo check) Use linter (eslint, clippy, ruff, biome lint) Use formatter (prettier, ruff format, cargo fmt, biome format) Use biome check (single tool for both) Run in sequence: types → lint → format </decision_tree>

<best_practices> 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 Prefer the smallest cohesion-raising refactor operation (view-data extraction, barrel removal, helper split) over a broad rewrite, and verify behavior with targeted tests after each move (refactoring_operations) For scored reviews, separate Critical from Quick Wins, phase the rollout, and state the analysis basis and its limits honestly (scored_review) </best_practices>

<anti_patterns> 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 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

<error_escalation inherits="core-patterns#error_escalation"> Minor linting warning with no functional impact Type error or test failure blocking CI Code quality gate failure preventing deployment Security vulnerability detected by static analysis </error_escalation>

<related_skills> Run tests after quality fixes Integration with implementation workflow </related_skills> <related_agents> Locate code patterns and references in this skill domain Review implementation quality against this skill guidance Analyze code complexity and suggest refactoring improvements </related_agents>