Quality tooling awareness for projects. Covers linting, formatting, type checking, testing, dead code detection, and pre-commit hooks. Use when reviewing code, setting up projects, or noticing missing quality tooling.
Quality tooling awareness for projects. Covers linting, formatting, type checking, testing, dead code detection, and pre-commit hooks. Use when reviewing code, setting up projects, or noticing missing quality tooling.
Quality Tooling
These tools keep codebases healthy. When working in a project, check whether they are configured. If any are missing, suggest them to the user.
Tools to know
Node / TypeScript
Tool
Purpose
Config files
Run command
ESLint
Catch bugs and enforce patterns
.eslintrc*, eslint.config.*
pnpm lint
Prettier
Consistent formatting
.prettierrc*, prettier.config.*
pnpm format
TypeScript
Type safety
tsconfig.json
pnpm typecheck
Vitest / Jest
Tests
vitest.config.*, jest.config.*
pnpm test
knip
Dead code: unused exports, deps, and files
knip.json, knip.ts
pnpm knip
Lefthook
Pre-commit hooks: run checks before push
lefthook.yml
auto on commit
Also check repo/package.json for scripts containing: lint, format, typecheck, test, check, validate.
PHP
Check repo/composer.json for scripts. Look for PHPStan (static analysis), PHP-CS-Fixer (formatting), PHPUnit (tests).
Python
Check repo/pyproject.toml or repo/setup.cfg. Look for ruff (lint/format), black (formatting), mypy (types), pytest (tests).
Minimum expected tooling
Every project SHOULD have at minimum: lint, format, test. Increasingly, dead code detection (knip) and pre-commit hooks (lefthook) are expected.
Do not install or configure tools without the user's approval. Flag what's missing and explain why it helps. Let the user decide.
Runtime Freshness
Projects SHOULD target the current Active LTS of their language runtime. Maintenance LTS is acceptable. EOL runtimes SHOULD be flagged.
Runtime freshness is advisory, not a hard failure. Legitimate exceptions exist: libraries with documented compatibility policies, hosting-locked client projects, migration-in-progress repos. Surface findings as a prompt and let the user decide.
Check the current LTS from the language's official schedule, not memory (LTS designations rotate each October):
"CI matrix includes Node 18 (EOL). Current Active LTS is Node 24. Drop EOL and add current LTS?"
If the user cites a constraint (hosting, compatibility, library support policy), record it in the project's wiki so future sessions see the exception and skip the prompt.
When to suggest
Setting up a new project: suggest the full set
Reviewing code with unused imports/exports: suggest knip
Seeing inconsistent formatting: suggest prettier
No tests for changed code: suggest vitest
No pre-commit hooks: suggest lefthook
CI matrix or engines pins an EOL runtime: suggest dropping it and adding current Active LTS
Fix everything, hide nothing
See work-habits: "Leave it better than you found it" and "Resolve, never hide." Both apply fully to quality checks. Fix every issue regardless of who introduced it. NEVER suppress checks. Fix the code.
When reviewing code, scan for existing suppressions (eslint-disable, @ts-ignore, .skip, noqa, phpcs:ignore, etc.) and flag every instance to the user. These are hidden technical debt.
pnpm lockfile sync
In pnpm workspace projects, the root pnpm-lock.yaml and site-level lockfiles MUST stay in sync. CI uses --frozen-lockfile and will reject mismatched lockfiles. This is the most common cause of deploy failures.
After ANY pnpm install, pnpm update, or pnpm add in a workspace, run pnpm install at the repo root to regenerate the root lockfile. Commit both lockfiles together. If you forget, the next deploy will fail.
Running quality checks
Use the /quality command to discover and run all configured checks. It handles the full cycle: discover, run, fix, repeat until clean.
