Skip to main content
command

husky — Claude Code command: CI checks and repo fixes

Runs lint, build, types and tests step by step, fixing failures until the repo works again. Handy before you commit.

Install into Claude Code · claude-code-templates All methods and platforms ↓
npx claude-code-templates@latest --command automation/husky
Open on GitHub

What husky does

The command works from the repo root and walks through the pipeline: update dependencies, run the linter, then build with types, test coverage and package validation. Failures get diagnosed and fixed along the way, and any fix sends you back through the earlier checks so you don't ship a regression. At the end files are staged only — nothing is committed.

Flags pick the scope: --skip-install skips dependency install, --only-lint stops after linting, --skip-tests drops the test step. The plain test command is deliberately avoided because it times out; coverage runs instead, package by package, which makes debugging easier. Snapshots are updated only after the change is explained.

Tool access is limited to Bash and Read, so edits happen through shell commands. Before staging, the command asks permission if it changed anything and suggests a commit message. Submodules under lib/* are excluded from staging — worth checking if your monorepo uses them.

What it helps with

  • run lint, types and tests in one pass before committing
  • repair a broken build without breaking the rest
  • debug a single failing package in a monorepo
  • stage files for a commit without committing
  • confirm a fix introduced no regression

Example prompts for the agent

  • /husky
  • /husky --only-lint
  • /husky --skip-install --skip-tests

How to install husky

1claude-code-templates

npx claude-code-templates@latest --command automation/husky

2Manually: put the files in place

.claude/commands/husky.md

Call it with /husky. For all projects use ~/.claude/commands/

Questions about husky

How do I install husky in Claude?

Use the templates CLI: npx claude-code-templates@latest --command automation/husky. The command file lands at .claude/commands/husky.md.

What does husky do?

It runs the repo's checks in order — dependencies, lint, build with types, test coverage, package validation — and fixes what fails. Files end up staged, with no commit made.

Can I run linting only?

Yes, pass --only-lint. There is also --skip-install to skip dependency install and --skip-tests to leave tests out.

Source text

husky.md · MIT
---
allowed-tools: Bash, Read
argument-hint: "[--skip-install] | [--only-lint] | [--skip-tests]"
description: Run comprehensive CI checks and fix issues until repository is in working state
---

# Husky CI Pre-commit Checks

Run comprehensive CI checks and fix issues: $ARGUMENTS

## Current Repository State

- Git status: !`git status --porcelain`
- Package manager: !`which pnpm npm yarn | head -1`
- Current branch: !`git branch --show-current`
- Package.json: @package.json
- Environment file: @.env (if exists)

## Task

Verify repository is in working state and fix issues. All commands run from repo root.

## CI Check Protocol

### Step 0: Environment Setup
- Update dependencies: `pnpm i` (unless --skip-install)
- Source environment: `.env` file if exists

### Step 1: Linting
- Check linter passes: `pnpm lint`
- Fix formatting issues automatically when possible

### Step 2: TypeScript & Build
- Run comprehensive build checks:
  ```bash
  pnpm nx run-many --targets=build:types,build:dist,build:app,generate:docs,dev:run,typecheck
  ```
- If specific command fails, debug that command individually
- Fix TypeScript errors and build issues

### Step 3: Test Coverage
- Source `.env` file first if exists
- Run test coverage: `pnpm nx run-many --target=test:coverage`
- **NEVER** run normal test command (times out)
- Run individual packages one by one for easier debugging
- For snapshot test failures: explain thesis before updating snapshots

### Step 4: Package Validation
- Sort package.json: `pnpm run sort-package-json`
- Lint packages: `pnpm nx run-many --targets=lint:package,lint:deps`

### Step 5: Double Check
- If fixes made in any step, re-run all preceding checks
- Ensure no regression introduced

### Step 6: Staging
- Check status: `git status`
- Add files: `git add`
- **EXCLUDE**: Git submodules in `lib/*` folders
- **DO NOT COMMIT**: Only stage files

## Error Handling Protocol

### 1. Diagnosis
- Explain why command broke with complete analysis
- Cite source code and logs supporting thesis
- Add console logs if needed for confirmation
- Ask for help if insufficient context

### 2. Fix Implementation
- Propose specific fix with full explanation
- Explain why fix will work
- If fix fails, return to Step 1

### 3. Impact Analysis
- Consider if same bug exists elsewhere
- Search codebase for similar patterns
- Fix related issues proactively

### 4. Cleanup
- Remove all added console.logs after fixing
- Run `pnpm run lint` to format files
- Ask user before staging changes
- Suggest commit message (don't commit)

## Development Notes

### File Organization
- Functions/types like `createTevmNode` are in:
  - Implementation: `createTevmNode.js`
  - Types: `TevmNode.ts`
  - Tests: `createTevmNode.spec.ts`

### Tool-Specific Tips

#### pnpm i
- If fails, abort unless simple syntax error (missing comma)

#### pnpm lint (Biome)
- Lints entire codebase
- Auto-fixes most formatting issues

#### TypeScript Builds
- Look for types in node_modules if not obvious
- For tevm packages, check monorepo structure
- Consult documentation if multiple failures

#### Test Execution
- Use Vite test runner
- Run packages individually for debugging
- Add console logs to test assumptions
- Explain snapshot changes before updating

## Success Criteria

Print checklist at end with ✅ for passed steps:
- ✅ Dependencies updated
- ✅ Linting passed
- ✅ TypeScript/Build passed
- ✅ Tests passed
- ✅ Package validation passed
- ✅ Files staged (no commits made)

## Safety Guidelines

- **Fix errors proactively** - TypeScript/tests will catch regressions
- **Never commit** - Only stage changes
- **One step at a time** - Don't proceed until current step passes
- **Ask permission** before staging if fixes were made

© davila7 · MIT · davila7/claude-code-templates

Similar slash commands

All slash commands for DevOps and infrastructure →

From the same set205

The whole set →

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor