Lint and Validate Skill

A Claude Code skill that enforces mandatory code validation after every change — running language-appropriate linters, formatters, type checkers, and build verification to ensure code is error-free before task completion.

When to Use This Skill

Choose this skill when:

• Ensuring code quality after every edit or generation
• Running ESLint, Prettier, TypeScript, or language-specific validators
• Enforcing consistent code standards across a project
• Catching syntax errors, type errors, and style violations immediately
• Verifying builds succeed after code modifications

Consider alternatives when:

• You need a comprehensive code review (use a code review skill)
• You need security-focused scanning (use a security skill)
• You need performance analysis (use a profiling tool)

Quick Start

Copy
# Add to your Claude Code project
claude mcp add lint-and-validate

# Run validation on current project
claude "lint and validate all changed files"

Copy
# .claude/skills/lint-and-validate.yml
name: lint-and-validate
description: Run all validation tools after every code change
triggers:
  - "lint"
  - "validate"
  - "check code"
config:
  auto_fix: true
  fail_on_warning: false
  validate_build: true

Core Concepts

Validation Pipeline by Language

Language	Lint	Format	Type Check	Build
TypeScript	eslint .	prettier --write .	tsc --noEmit	npm run build
JavaScript	eslint .	prettier --write .	—	npm run build
Python	ruff check .	ruff format .	mypy .	—
Rust	cargo clippy	cargo fmt	—	cargo build
Go	golangci-lint run	gofmt -w .	—	go build ./...

Validation Order

Copy
# 1. Format first (changes file content)
npx prettier --write "src/**/*.{ts,tsx}"

# 2. Lint second (checks formatted code)
npx eslint "src/**/*.{ts,tsx}" --fix

# 3. Type check third (validates types)
npx tsc --noEmit

# 4. Build last (verifies everything compiles)
npm run build

Auto-Fix Configuration

Copy
// .eslintrc.json
{
  "extends": ["eslint:recommended", "plugin:@typescript-eslint/recommended"],
  "rules": {
    "no-unused-vars": "error",
    "no-console": "warn",
    "@typescript-eslint/no-explicit-any": "warn",
    "prefer-const": "error"
  }
}

// .prettierrc
{
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "printWidth": 100,
  "tabWidth": 2
}

Configuration

Parameter	Type	Default	Description
auto_fix	boolean	true	Auto-fix fixable issues
fail_on_warning	boolean	false	Treat warnings as errors
validate_build	boolean	true	Run build after linting
changed_files_only	boolean	true	Only validate modified files
format_first	boolean	true	Run formatter before linter
type_check	boolean	true	Run type checker
parallel	boolean	false	Run checks in parallel

Best Practices

1. Run validation after every code change, not just at commit time — catching errors immediately reduces context-switching cost; an error found 10 seconds after writing is cheaper to fix than one found 10 minutes later.

2. Format first, then lint — formatting changes file content which may fix or introduce lint issues; running the formatter first ensures the linter checks the final version of the code.

3. Enable auto-fix for style issues, not logic issues — auto-fix is safe for formatting, unused imports, and const vs let; but auto-fixing logic warnings like no-unused-vars can delete intentional code.

4. Validate only changed files during development — running linters on the entire project after each small change is slow; validate changed files during development and run full validation in CI.

5. Make the validation pipeline match CI exactly — if CI runs eslint, tsc, and build, your local validation should run the same commands in the same order to catch issues before pushing.

Common Issues

ESLint and Prettier conflict on formatting rules — Install eslint-config-prettier to disable ESLint's formatting rules. Let Prettier handle formatting exclusively and ESLint handle code quality rules.

Type checker reports errors in node_modules — Add skipLibCheck: true to tsconfig.json to skip type checking third-party packages. This is safe because library types are the library author's responsibility.

Build fails but lint passes — Linting and type checking don't catch all build issues. Module resolution, missing exports, and build tool configuration can cause build failures that pass lint. Always include a build step in validation.