agentleFS
Sign inStart free
imMamdouhaboammarimMamdouhaboammar/matts-skills-into-chatgpt/skills/setup-pre-commit/SKILL.md

setup-pre-commit

Skill8 starsChanged 2 months agoMITView on GitHub

Configure pre-commit quality checks with Husky and lint-staged while preserving package manager conventions. Use when setting up git pre-commit hooks, automated formatters, staged linters, or typecheck gates — even if the user says \"add pre-commit hooks\". Do NOT use for continuous integration (CI) pipeline setup.

We split this skill into the rules it gives an agent

6 rules. 0 are common, 1 is distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 106 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Staged-Only Formatting: Run Prettier strictly against staged files via lint-staged with --ignore-unknown --write to prevent un-staged code …

    line 15
  2. Very specific:

    Preserve Existing Configurations: If .prettierrc or existing Husky hooks exist, merge scripts safely without overwriting user rules.

    line 17
  3. Distinctive:

    Mandatory Smoke-Test Commit: Verify the entire hook pipeline by staging all configuration changes and executing a verified test commit.

    line 18
  4. Very specific:

    Key Point: Check if prettier, lint-staged, or husky are already installed.

    line 46
  5. Very specific:

    Key Point: Verify that "prepare": "husky" is added to package.json.

    line 51
  6. Very specific:

    Key Point: Create .lintstagedrc with {"*": "prettier --ignore-unknown --write"}.

    line 65

“Common” is measured: kept by at least 6 in 10 of the 106 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Setup Pre-Commit Hooks

Install and configure deterministic Git pre-commit quality gates using Husky, lint-staged, and Prettier, preserving existing repository package managers and build scripts.

Core Invariants

  1. Package Manager Fidelity: Detect and use the repository's native package manager (bun, pnpm, yarn, npm); do NOT introduce conflicting lockfiles.
  2. Staged-Only Formatting: Run Prettier strictly against staged files via lint-staged with --ignore-unknown --write to prevent un-staged code drift.
  3. Repository-Wide Typecheck & Test: Execute full typecheck and unit test passes inside .husky/pre-commit after lint-staged succeeds.
  4. Preserve Existing Configurations: If .prettierrc or existing Husky hooks exist, merge scripts safely without overwriting user rules.
  5. Mandatory Smoke-Test Commit: Verify the entire hook pipeline by staging all configuration changes and executing a verified test commit.

Architecture & Map of Content (MOC)

[ Git Commit Attempt ] ──► [ .husky/pre-commit Hook ]
                                     │
         ┌───────────────────────────┼───────────────────────────┐
         ▼                           ▼                           ▼
  [ lint-staged ]             [ Typecheck Gate ]          [ Unit Test Gate ]
  - Prettier format           - `npm run typecheck`       - `npm run test`
  - Staged files only         - Full project types        - Unit/Integration pass
ComponentResponsibilityConfiguration File
Husky EngineGit hook manager v9+.husky/pre-commit
lint-stagedRun formatters exclusively on staged changes.lintstagedrc
PrettierCode style standardization.prettierrc

Step-by-Step Procedure (TWI)

Step 1: Detect Package Manager & Check Existing Setup

  • Action: Detect the lockfile (bun.lockb $\rightarrow$ bun, pnpm-lock.yaml $\rightarrow$ pnpm, yarn.lock $\rightarrow$ yarn, else npm).
  • Key Point: Check if prettier, lint-staged, or husky are already installed.
  • Why: Reusing existing dependencies prevents package bloat and lockfile churn.

Step 2: Install DevDependencies & Initialize Husky

  • Action: Install husky, lint-staged, and prettier as devDependencies, then run npx husky init.
  • Key Point: Verify that "prepare": "husky" is added to package.json.
  • Inline Checklist:
    • Dependencies installed in devDependencies
    • .husky/ directory created
    • prepare script present in package.json

Step 3: Write .husky/pre-commit & .lintstagedrc

  • Action: Configure .husky/pre-commit:
    npx lint-staged
npm run typecheck
npm run test
    (Adapting npm to the detected package manager, and omitting typecheck/test if scripts are absent).
  • Key Point: Create .lintstagedrc with {"*": "prettier --ignore-unknown --write"}.
  • Why: prettier --ignore-unknown safely ignores binaries and images while formatting all supported text formats.

Step 4: Smoke Test and Initial Commit

  • Action: Stage all created hook files and run git commit -m "Add pre-commit hooks (husky + lint-staged + prettier)".
  • Key Point: Confirm that the commit triggers the pre-commit hook and passes all stages.
  • Why: Live commit execution proves that hooks are executable and correctly configured.

Anti-Rationalization Guardrails

Tempting RationalizationBinding RuleEngineering Rationale
"Run prettier across the whole repository on every commit."Run Prettier strictly on staged files via lint-staged.Full-repo formatting on every commit slows developer workflows and pollutes diffs.
"Skip the typecheck and test steps in pre-commit to make it faster."Include typecheck and fast tests in pre-commit.Catching type errors locally before push prevents broken remote CI builds.
"Use npm commands in a pnpm or bun repository."Strictly match detected package manager commands.Mismatched package managers create duplicate lockfiles and broken installations.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free