preflight-checks

$npx mdskill add rileyhilliard/claude-essentials/preflight-checks

Run project linters and formatters before committing code.

  • Catches quality errors early instead of relying on pre-commit hooks.
  • Auto-detects tools from package.json, tsconfig.json, and other configs.
  • Executes specific check commands for each identified tool.
  • Applies automatic fixes where available or flags manual intervention.

SKILL.md

.github/skills/preflight-checksView on GitHub ↗
---
name: preflight-checks
description: Detect and run project linters, formatters, and type checkers before committing or claiming completion. Auto-detects tools from project config files.
---

# Preflight Checks

Run the project's code quality tools before committing. Catch errors early instead of letting pre-commit hooks catch them.

## Tool Detection

Detect available tools from project config files. Check in this order:

| Config File | Tool | Check Command | Fix Command |
|-------------|------|---------------|-------------|
| `package.json` scripts | npm/yarn/pnpm | Look for `lint`, `typecheck`, `format`, `check` scripts | Run with `--fix` where available |
| `.eslintrc*` / `eslint.config.*` | ESLint | `npx eslint <files>` | `npx eslint --fix <files>` |
| `tsconfig.json` | TypeScript | `npx tsc --noEmit` | Manual fix required |
| `.prettierrc*` / prettier in package.json | Prettier | `npx prettier --check <files>` | `npx prettier --write <files>` |
| `pyproject.toml` with `[tool.ruff]` | Ruff | `ruff check <files>` | `ruff check --fix <files> && ruff format <files>` |
| `pyproject.toml` with `[tool.mypy]` / `mypy.ini` | mypy | `mypy <files>` | Manual fix required |
| `pyproject.toml` with `[tool.black]` | Black | `black --check <files>` | `black <files>` |
| `.flake8` / `setup.cfg` with `[flake8]` | Flake8 | `flake8 <files>` | Manual fix required |
| `go.mod` | Go | `go vet ./...` | `gofmt -w <files>` |
| `Cargo.toml` | Rust | `cargo clippy` | `cargo clippy --fix` |
| `.pre-commit-config.yaml` | pre-commit | `pre-commit run --files <files>` | Runs auto-fix internally |

## Execution Order

Run tools in this order. Each step can change code that later steps check.

1. **Formatters** (auto-fix): prettier, black, ruff format, gofmt
2. **Linters** (auto-fix where possible): eslint --fix, ruff check --fix
3. **Type checkers** (manual fix): tsc, mypy, pyright

## Scope

Only check files that are staged or modified. Don't run checks on the entire codebase.

```bash
# Staged files
git diff --cached --name-only --diff-filter=ACM

# Unstaged modified files
git diff --name-only --diff-filter=ACM
```

Filter to relevant extensions for each tool (e.g., only `.ts`/`.tsx` for tsc, only `.py` for ruff).

## Auto-Fix Protocol

1. Run the formatter/linter with its fix flag
2. Re-stage any files that were modified: `git add <fixed-files>`
3. Report what was changed: "Fixed 3 formatting issues in src/auth/login.ts"

## When to Run

- Before `git commit` (used by `/ce:commit`)
- Before claiming work is complete
- Before creating a PR (used by `/ce:pr`)

## Failure Handling

Distinguish between fixable and non-fixable errors:

**Fixable (auto-fix and move on):**
- Formatting errors (whitespace, trailing commas, import ordering)
- Simple lint errors with auto-fix support

**Needs human decision (report and stop):**
- Type errors (wrong types, missing properties)
- Complex lint errors without auto-fix
- Test failures
- Errors you don't understand

Never silently skip a failing check.

More from rileyhilliard/claude-essentials

SkillDescription
architecting-systemsGuides clean, scalable system architecture during the build phase. Use when designing modules, defining boundaries, structuring projects, managing dependencies, or preventing tight coupling and brittleness as systems grow.
configuring-claudeBest practices for writing Claude Code skills, rules, and CLAUDE.md instructions. Use when creating SKILL.md files, authoring .claude/rules, writing CLAUDE.md project or user instructions, or configuring Claude behavior for a project or team.
fixing-flaky-testsDiagnose and fix tests that pass in isolation but fail when run concurrently. Covers shared state isolation and resource conflicts. References condition-based-waiting for timing issues.
handling-errorsPrevents silent failures and context loss in error handling. Use when writing try-catch blocks, designing error propagation, reviewing catch blocks, or implementing Result patterns.
managing-databasesGuides database architecture decisions for PostgreSQL, DuckDB, Parquet, PGVector, and Neo4j. Use when designing schemas, choosing storage strategies, optimizing queries, tuning maintenance, configuring vector search, modeling graph data, or diagnosing performance issues across OLTP, OLAP, similarity search, and graph workloads.
managing-pipelinesGuides CI/CD pipeline architecture, security hardening, and deployment strategies for GitHub Actions. Use when designing workflows, securing supply chains, optimizing build performance, configuring deployments, managing infrastructure as code pipelines, or setting up pipeline observability.
migrating-codeSafe code migrations with backward compatibility and reversibility. Use when upgrading dependencies, changing database schemas, API versioning, or transitioning between technologies.
optimizing-performanceMeasure-first performance optimization that balances gains against complexity. Use when addressing slow code, profiling issues, or evaluating optimization trade-offs.
planning-productsDefines product features from a PM perspective before technical planning begins. Use when scoping new features, writing product specs, defining user problems, choosing what to build, researching existing patterns, or bridging the gap between strategy and implementation. Covers JTBD analysis, competitive research, UX/DX experience definition, and scope negotiation for consumer, B2B, and developer tool products.
reading-logsAnalyzes logs efficiently through targeted search and iterative refinement. Use when investigating errors, debugging incidents, or analyzing patterns in application logs.