Automate Git Hooks for Code Quality
Git Hooks Automation sets up Husky, lint-staged, or the pre-commit framework to check code before commits reach CI.
Why it matters
Enforce code quality and consistency directly within your Git workflow. This asset automates the setup and management of Git hooks to lint, format, test, and validate code before it's committed or pushed, catching issues early and improving team collaboration.
Outcomes
What it gets done
Configure Husky and lint-staged for Node.js projects.
Implement commit message validation with commitlint.
Set up pre-push hooks to run tests automatically.
Utilize the pre-commit framework for Python and polyglot projects.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-git-hooks-automation | bash Overview
Git Hooks Automation
Git Hooks Automation sets up Husky/lint-staged or the pre-commit framework to lint, format, test, and validate commit messages at the git level before code reaches CI. Use it to set up or migrate git hooks, enforce commit conventions, or automate pre-push testing. CI still serves as the source of truth since hooks can be bypassed.
What it does
Git Hooks Automation sets up Git-level enforcement - linting, formatting, testing, and commit-message validation - that runs in seconds before a commit or push ever reaches CI, across whichever hook mechanism a project uses: raw hooks in .git/hooks/ (not version-controlled, so team-shared setups need a framework), Husky plus lint-staged for Node/TypeScript projects (running checks only on staged files for speed), or the language-agnostic pre-commit framework (YAML-configured, isolated hook environments, works for Python and polyglot repos alike). It covers the eight standard hook points and when each fires - pre-commit, prepare-commit-msg, commit-msg, post-commit, pre-push, pre-rebase, post-merge, post-checkout.
When to use - and when NOT to
Use it when asked to set up git hooks or pre-commit hooks, configure Husky, lint-staged, or the pre-commit framework, enforce Conventional Commits via commitlint, automate pre-push test runs, or migrate from Husky v4 to v9+. For projects without Node or Python, it also writes portable custom shell hooks shared via core.hooksPath rather than the local-only .git/hooks/ directory - including concrete checks like blocking direct commits to main/master, flagging debug statements (console.log, debugger, binding.pry, import pdb), rejecting files over 1MB, and pattern-matching for leaked secrets such as AWS keys, OpenAI-style sk- keys, GitHub tokens, and hardcoded passwords. Hooks are explicitly positioned as a first line of defense, not the source of truth - CI still re-runs the same checks since hooks can always be bypassed with --no-verify or a per-hook SKIP= variable.
Inputs and outputs
Input: the project's language stack and which checks to enforce at which git event. Output: a working hook configuration - for Husky, .husky/pre-commit running lint-staged, .husky/commit-msg running commitlint against a commitlint.config.js, and .husky/pre-push running the test suite; for the pre-commit framework, a .pre-commit-config.yaml wiring in trailing-whitespace, large-file, and secret-detection checks plus language-specific hooks like black, ruff, and shellcheck.
repos:
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v4.6.0
hooks:
- id: trailing-whitespace
- id: end-of-file-fixer
- id: check-yaml
- id: check-added-large-files
args: ['--maxkb=500']
- id: detect-private-key
It also diagnoses common failure modes - hooks silently skipped because they were never installed, permission denied from a non-executable hook file, stale hooks from an old setup, or hooks passing locally but failing in CI due to version drift - and recommends gradual adoption on existing projects: formatting first, then linting, then commit-message rules, then a pre-push test runner, to avoid team resistance.
Integrations
Related skills cover adjacent needs: @codebase-audit-pre-push for a deeper pre-push audit, @verification-before-completion for verifying work before claiming it done, @bash-pro for writing more advanced custom hook scripts, and @github-actions-templates for the CI workflows that back up whatever the hooks enforce locally.
Who it's for
Teams that want fast, team-shared, version-controlled Git-level quality gates - lint, format, commit-message, and test checks - running in under five seconds locally, with CI still enforcing the same rules as the actual source of truth.
FAQ
Common questions
Discussion
Questions & comments ยท 0
Sign In Sign in to leave a comment.