setup-pre-commit

Overview of setup-pre-commit skill

What setup-pre-commit does

The setup-pre-commit skill helps an agent add a practical Git commit gate to a JavaScript or TypeScript repository using husky, lint-staged, Prettier, and optional typecheck and test scripts. In plain terms, it wires up formatting on staged files and can block bad commits before they land.

Who this skill is best for

This skill is best for teams or solo developers who want a low-drama pre-commit setup in an existing repo and do not want to hand-design the first Husky configuration. It fits especially well when you already have a Node-based project and want commit-time formatting plus lightweight quality checks.

The real job-to-be-done

Most users do not just want “Husky installed.” They want a repo where contributors can commit confidently, with a predictable hook that:

• formats staged files,
• runs existing typecheck and test scripts when present,
• avoids inventing extra tooling,
• matches the repo’s package manager.

That is the practical value of setup-pre-commit.

What makes setup-pre-commit different from a generic prompt

A generic prompt might suggest many possible Git hook patterns. The setup-pre-commit skill is narrower and more useful for a common case: set up the specific path of Husky + lint-staged + Prettier, detect the package manager, create the right files, and avoid adding typecheck or test commands that the repo does not actually support.

What it sets up by default

Based on the skill source, the expected output includes:

• husky initialization
• a .husky/pre-commit file
• a .lintstagedrc
• a .prettierrc only if no existing Prettier config exists
• hook commands for lint-staged, plus typecheck and test when those scripts already exist

Best-fit and misfit repos

Best fit:

• Node.js repos
• frontend or full-stack TypeScript apps
• repos that already use package.json
• projects with existing test and typecheck scripts

Less ideal:

• polyglot monorepos with custom hook orchestration
• repos that already use another hook manager
• teams wanting very fast, selective, or language-specific commit pipelines beyond the defaults
• projects where running tests on every commit is too slow

How to Use setup-pre-commit skill

Install context for setup-pre-commit skill

If you are using the Skills system, add the skill from the source repository:

npx skills add mattpocock/skills --skill setup-pre-commit

Then invoke it when you want the agent to modify the current repository, not to explain Git hooks abstractly.

What inputs the skill needs from your repo

The setup-pre-commit usage quality depends on repo context. Before calling it, make sure the agent can inspect:

• package.json
• any lockfile such as package-lock.json, pnpm-lock.yaml, yarn.lock, or bun.lockb
• existing Prettier config files
• existing .husky/ or Git hook setup
• whether typecheck and test scripts exist

Without that context, the agent may produce commands that do not match your package manager or scripts.

The repository file to read first

Start with SKILL.md. This skill is simple and self-contained, and the important logic is all there:

• detect package manager
• install husky, lint-staged, and prettier
• run npx husky init
• write .husky/pre-commit
• write .lintstagedrc
• add .prettierrc only if missing
• verify the result

For this specific skill, there are no extra helper files carrying hidden behavior.

How to prompt setup-pre-commit well

A weak prompt:

Set up pre-commit hooks.

A stronger prompt:

Use the setup-pre-commit skill in this repo. Detect the package manager from lockfiles, inspect package.json, add Husky with lint-staged and Prettier, and only include typecheck or test in .husky/pre-commit if those scripts already exist. Do not overwrite any existing Prettier config. Show me the files you changed and the exact commands you ran.

Why this is better:

• it anchors the package manager rule,
• prevents invented scripts,
• preserves existing formatting conventions,
• asks for a reviewable diff.

How to turn a rough goal into a complete request

If your real goal is “make our Git workflow safer,” convert it into repo-specific constraints:

• package manager in use
• whether tests are fast enough for pre-commit
• whether you want formatting only or formatting plus validation
• whether the repo already has Prettier or Husky
• whether you want the hook to be minimal for contributor speed

Example:

Use setup-pre-commit for Git Workflows in this React TypeScript repo. We use pnpm, already have a test script, and have typecheck in package.json. Keep the hook simple and fast. Reuse existing Prettier config if present. If tests look expensive, explain whether they should stay in pre-commit or move to pre-push.

That prompt gives the agent decision-quality information, not just a task label.

Expected files and commands

For a normal npm repo, the skill will usually lead to:

• install dev dependencies: husky, lint-staged, prettier
• run npx husky init
• create .husky/pre-commit
• create .lintstagedrc
• possibly create .prettierrc

The hook content should be adapted to the package manager. The source skill explicitly says to replace npm with the detected package manager where needed.

Practical package manager behavior

The skill’s package manager detection rule is straightforward:

• package-lock.json → npm
• pnpm-lock.yaml → pnpm
• yarn.lock → yarn
• bun.lockb → bun
• if unclear → npm

This matters because many poor setup-pre-commit install attempts fail not on Husky itself, but on mixed package-manager commands in docs or generated files.

What the skill will omit on purpose

A useful boundary: the skill is not supposed to invent scripts that your repo does not already support. If package.json has no typecheck or test, those lines should be left out of .husky/pre-commit, and the user should be told that explicitly.

That makes the skill safer than broad prompts that assume every project has a TypeScript check and test runner.

Suggested workflow after running the skill

After the agent applies the skill:

1. inspect package.json
2. inspect .husky/pre-commit
3. inspect .lintstagedrc
4. confirm no existing Prettier config was overwritten
5. run a test commit with a small staged formatting change
6. decide whether test belongs in pre-commit or should move elsewhere

This last step is important: correctness is not the same as ergonomics. A hook that runs long tests may be technically valid but still harm adoption.

A good default review checklist

Before merging the changes, verify:

• the package manager matches the repo
• .husky/pre-commit uses commands contributors can run locally
• the hook does not call missing scripts
• staged formatting is limited via lint-staged
• Prettier config was only added if missing
• commit latency is acceptable for daily use

setup-pre-commit skill FAQ

Is setup-pre-commit good for beginners?

Yes, if the repo is a standard Node project. The skill is opinionated but not complicated, and it avoids a lot of common first-time friction around Husky initialization and basic lint-staged wiring.

What does setup-pre-commit not cover?

The skill does not try to design a full code quality strategy. It does not choose ESLint rules, optimize monorepo hook execution, or create sophisticated file-type-specific lint-staged commands. Its scope is the initial commit-hook setup.

When should I not use setup-pre-commit?

Skip it if:

• your repo already has a mature Git hook system,
• you need language-specific multi-step hooks outside Node tooling,
• you want very customized staged-file patterns,
• running tests on every commit would obviously slow developers down.

In those cases, a more tailored prompt or existing internal standard may be better.

Is this better than asking an AI to “set up Husky”?

Usually yes for this exact use case. The value of setup-pre-commit is not novelty; it is constrained execution. It encodes a sensible default path and reduces guesswork around lockfile detection, missing scripts, and when to create Prettier config.

Does setup-pre-commit work for monorepos?

Sometimes, but with caution. It can still help if the repo has one clear top-level package.json and one hook strategy. It is less reliable when packages have independent scripts, separate formatting policies, or workspace-specific test commands.

Does it force Prettier even if the repo already has formatting config?

No. The source instructions say to create .prettierrc only if no existing Prettier config exists. That is an important adoption-friendly behavior.

Can I use setup-pre-commit for Git Workflows beyond formatting?

Yes, but only in a limited sense. The skill supports adding typecheck and test to the commit workflow when those scripts already exist. It is not a full branch protection or CI design tool.

How to Improve setup-pre-commit skill

Give the skill stronger repo facts up front

The fastest way to improve setup-pre-commit usage is to provide concrete repo signals in your prompt:

• package manager
• whether typecheck exists
• whether test exists
• whether tests are fast
• whether a Prettier config already exists
• whether .husky/ already exists

The skill becomes much more reliable when it can operate from verified facts instead of assumptions.

Ask for a diff-minded implementation

A strong improvement prompt is:

Use the setup-pre-commit skill, but minimize changes. Reuse existing config where possible, avoid replacing current hook behavior, and show the exact file diff before writing anything risky.

This helps in repos that may already contain partial tooling.

Prevent the most common failure mode

The most common failure mode is adding commands that the repo cannot run. Improve results by explicitly telling the agent:

Only add typecheck and test to the hook if those scripts already exist in package.json. Otherwise omit them and explain why.

That instruction is aligned with the source skill and prevents broken commits.

Tune for developer speed, not just correctness

Many teams discover that npm run test in pre-commit feels too heavy. If speed matters, ask the agent to evaluate hook cost:

Use setup-pre-commit, but if tests appear slow or broad, explain whether they should move to pre-push or CI instead of pre-commit.

This turns the skill from “install tooling” into “fit the workflow.”

Request package-manager-safe commands

If your team uses pnpm, yarn, or bun, say so explicitly even if the lockfile is present. That removes ambiguity and improves command consistency in generated hook files and follow-up instructions.

Ask the agent to preserve existing standards

If your repo already has formatting or hook files, add:

Do not overwrite existing Prettier or Husky config without comparing and explaining the merge strategy.

That matters more than it sounds. Pre-commit tooling often fails socially because it replaces local conventions too aggressively.

Improve output quality with a validation step

A better final prompt includes:

After applying setup-pre-commit, verify that the hook files exist, dependencies are in devDependencies, and the hook references only valid scripts. Then tell me how to test it with one staged file.

This pushes the agent beyond file creation into actual usability.

Iterate after the first pass

If the first output is technically correct but awkward, refine with one of these follow-ups:

• “Make the hook faster.”
• “Adapt this for pnpm.”
• “Remove test from pre-commit but keep typecheck.”
• “Keep existing Prettier settings and only add missing pieces.”
• “Adjust for a monorepo root package.”

That is usually more effective than starting over with a brand-new broad prompt.

What users care about most

For most adopters, the best setup-pre-commit guide is not “how many tools it installs,” but whether it:

• works with the current repo immediately,
• avoids breaking commits,
• respects existing config,
• stays fast enough that developers keep it enabled.

Use the skill with those outcomes in mind, and it is much more likely to deliver lasting value.