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