husky — команда для Claude Code: CI-проверки и починка репозитория
Прогоняет линтер, сборку, типы и тесты по шагам и правит ошибки, пока репозиторий не станет рабочим. Полезно перед коммитом.
npx claude-code-templates@latest --command automation/huskyЧто делает husky
Команда запускает проверки из корня репозитория и идёт по шагам: сначала обновляет зависимости, затем линтер, потом сборку с типами, покрытие тестами и валидацию пакетов. На каждом шаге ошибки разбираются и исправляются, а если правки внесены, предыдущие проверки прогоняются заново — чтобы не притащить регрессию. В конце файлы только добавляются в индекс, коммит не делается.
Аргументы задают режим: --skip-install пропускает установку зависимостей, --only-lint оставляет только линтер, --skip-tests убирает тесты. Обычный тестовый прогон команда не запускает — он упирается в таймаут, вместо него идёт test:coverage и пакеты по одному. Снапшоты обновляются только после объяснения сути изменений.
Инструменты ограничены Bash и Read, так что править код агент будет через консольные команды. Перед стейджингом команда спрашивает разрешение, если что-то исправляла, и предлагает текст коммита. Из индекса исключаются подмодули в lib/* — это стоит проверить, если у вас монорепозиторий с сабмодулями.
Какие задачи решает
- прогнать линтер, типы и тесты одной командой перед коммитом
- починить упавшую сборку и не сломать остальное
- разобраться, почему падает конкретный пакет в монорепозитории
- подготовить файлы к коммиту, не делая сам коммит
- проверить, что правки не внесли регрессию
Примеры запросов агенту
- /husky
- /husky --only-lint
- /husky --skip-install --skip-tests
Как установить husky
1Через claude-code-templates
npx claude-code-templates@latest --command automation/husky2Вручную: положить файлы
.claude/commands/husky.mdВызов — /husky. Для всех проектов — ~/.claude/commands/
Вручную: положить файлы
~/.codex/prompts/husky.mdВызов — /prompts:husky. В Codex этот формат помечен устаревшим, замена — скиллы
Вручную: положить файлы
.github/prompts/husky.prompt.mdВручную: положить файлы
.gemini/commands/husky.tomlGemini хранит команды в TOML: текст запроса — в поле prompt
Из того же набора205
Весь набор →Похожие
Рядом в теме «DevOps и инфраструктура»
Все слэш-команды по теме «DevOps и инфраструктура» →Вопросы о husky
Как установить husky в Claude?
Через шаблоны: npx claude-code-templates@latest --command automation/husky. Файл команды появится по пути .claude/commands/husky.md.
Что делает husky?
Прогоняет проверки репозитория по шагам — зависимости, линтер, сборка с типами, покрытие тестами, валидация пакетов — и исправляет найденные ошибки. В конце файлы добавляются в индекс без коммита.
Можно ли запустить только линтер?
Да, с аргументом --only-lint. Ещё есть --skip-install для пропуска установки зависимостей и --skip-tests, чтобы не гонять тесты.
Исходный текст
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