| name | quality-code-check |
| description | Code quality validation through linting, type checking, and build verification. Multi-language support for automated quality gates. Use when validating code quality: - After implementation to validate code meets standards - Before creating pull requests or commits - When debugging build/type/lint issues - User explicitly requests quality checks Provides language-specific tool commands and validation workflows for: - JavaScript/TypeScript (ESLint, tsc, build tools) - Python (Ruff, MyPy, Pyright) - Go (golangci-lint, go build) - Rust (Clippy, cargo check/build) - Java (Gradle, Maven) Focuses on detecting issues early through systematic automated checks. |
Quality Code Check
Purpose
Establish consistent code quality standards through automated validation tools, ensuring code reliability, maintainability, and consistency.
Core Principle
Code quality validation is a safety gate that catches errors early, prevents tech debt accumulation, and ensures code meets project standards.
Quality Check Categories
1. Linting - Code Style & Best Practices
What linting detects:
- Code style violations (indentation, spacing, naming)
- Unused variables and imports
- Missing error handling patterns
- Potentially dangerous patterns
- Code complexity issues
Language-specific tools:
- JavaScript/TypeScript: ESLint
- Python: Ruff, Flake8
- Go: golangci-lint
- Rust: Clippy
- Java: Spotbugs, Checkstyle
Approach:
- Run linting on all modified files
- Auto-fix warnings when possible
- Fix remaining errors manually
- Minimize warnings to project standards
2. Type Checking - Type Safety
What type checking validates:
- Type consistency
- Function parameter and return types
- Null/undefined safety
- Generic type parameters
Language-specific tools:
- TypeScript:
tsc --noEmit - Python: MyPy, Pyright
- Go: Compiler (built-in)
- Rust: Compiler (built-in)
- Java: Compiler (built-in)
Approach:
- Enable strict type checking when available
- Run on all modified code
- Fix type errors before proceeding
- Use type annotations for function signatures
3. Build Verification - Compilability & Packaging
What build checking validates:
- Code compiles without errors
- All imports and dependencies resolve
- Asset bundling completes
- Runtime entry points exist
Language-specific tools:
- JavaScript/TypeScript: Webpack, Vite, or
npm run build - Python:
python -m py_compileor test imports - Go:
go build ./... - Rust:
cargo build - Java: Maven (
mvn compile), Gradle (gradle build)
Approach:
- Run full build after all changes complete
- Use production build configuration when available
- All build steps must succeed without errors
Tool Invocation
Note: Commands are examples. Adjust to your project's package manager, config files, and scripts.
Project Detection
Use Glob to detect project type:
- Glob(pattern="
**/package.json") → JavaScript/TypeScript - Glob(pattern="
**/pyproject.toml") or Glob(pattern="**/requirements.txt") → Python - Glob(pattern="
**/go.mod") → Go - Glob(pattern="
**/Cargo.toml") → Rust - Glob(pattern="
**/pom.xml") or Glob(pattern="**/build.gradle") → Java
Language-Specific Commands
JavaScript/TypeScript
# Check package.json scripts first
npm run lint
npx eslint . --max-warnings=0
# Type checking
npm run typecheck
npx tsc --noEmit
# Build
npm run build
Python
# Linting
ruff check .
ruff check . --fix # auto-fix
# Type checking
mypy .
pyright
# Import check
python -c 'import your_package'
Go
# Linting
golangci-lint run
go vet ./...
# Build (includes type checking)
go build ./...
Rust
# Linting
cargo clippy -- -D warnings
# Type checking
cargo check
# Build
cargo build
cargo build --release # production
Java
# Gradle
./gradlew check
./gradlew build
# Maven
mvn verify
mvn compile
Error Handling
Tool not found:
- Try command, catch error
- If not found: Skip check, notify user
- Continue with remaining checks
Check fails:
- Parse error output
- Report specific violations
- Suggest fixes based on error type
- Retry after fixes
Validation Workflow
When to Run
- After implementation is stable enough
- Before creating pull requests or commits
- When user explicitly requests
- Incrementally during development (optional)
Quality Check Sequence
Detect available tools from project configuration
- Use Glob to find config files
- Identify which tools are available
Run linting (scoped to changed files when possible)
- Execute appropriate commands
- Fix auto-fixable issues first (--fix flag)
- Manually fix remaining violations
- Target: Meet project's warning standards
Run type checks
- Execute appropriate commands
- Fix all type errors
- Validate type consistency across modules
- Target: No type errors
Run build (full build, production config when available)
- Execute appropriate commands
- Ensure all code compiles
- Validate all imports resolve
- Confirm output artifacts generated
- Target: Build succeeds without critical errors
Error Recovery
If quality checks fail:
- Analyze errors - Identify root causes
- Fix issues - Make minimal changes to resolve
- Re-run checks - Execute same commands again
- Repeat - Continue until checks pass
If unable to fix:
- Document the issue and root cause
- Mark as blocked if preventing progress
- Escalate or ask user for guidance
Common Mistakes
- Ignoring warnings - Warnings often indicate real problems → Fix them or understand why acceptable
- Only checking one file - Changes can break type checking across others → Check all modified files and dependencies
- Skipping the build step - Code might lint/type-check but fail to compile → Always verify full build
- Accepting auto-fixes blindly - Auto-fixes might hide real issues → Review each auto-fix before committing
- Not checking package.json scripts - Projects often define custom commands → Check scripts first before running tools directly
- Inconsistent standards - Allowing different levels across features → Maintain consistent standards for your project
Validation Checklist
Before considering quality checks complete:
- Code is stable enough to validate
- Linting tool runs successfully on changed files
- Lint warnings minimized to project-acceptable levels
- Type checking tool runs successfully
- No critical type errors remain
- Build completes successfully
- No critical build errors present
- Warnings at project-acceptable levels
- All blocking issues fixed or escalated
Key Takeaway
Systematic quality validation catches issues early and maintains consistency.
Quality checks are flexible gates that validate code against project standards:
- Run when code is stable enough
- Adjust tool commands to your project's needs
- Target project-appropriate warning levels
- Use as validation before PRs, commits, or deployment
Commands shown are examples - check your project's scripts first. Quality standards should be consistent within your project but may vary between projects.
Systematic checks catch errors early, prevent tech debt accumulation, and build confidence in code readiness.