agentleFS
Sign inStart free
PradnyeshpPradnyeshp/Claude-Skills/.claude/skills/pre-commit/SKILL.md

pre-commit

Skill2 starsChanged 4 months agoMITView on GitHub

Set up or improve pre-commit hooks that lint, format, and check the project before each commit, matching its language and tooling. Use when the user says "set up pre-commit hooks", "add a git hook", "run lint before commit", "configure husky", "add pre-commit", or "block bad commits".

11 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 4 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 11 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If a framework is already configured, extend its config rather than introducing a second one.

    line 27
  2. Distinctive:

    Only wire checks the project can actually run — verify the command exists in scripts/manifest before adding it.

    line 35
  3. Distinctive:

    Don't add new dependencies beyond the hook framework and its standard companions, and call out exactly what gets installed.

    line 36
  4. Very specific:

    Keep hooks fast and staged-file-scoped.

    line 37
  5. Very specific:

    Never weaken or auto---no-verify anything.

    line 38
  6. Distinctive:

    After writing, summarize each hook, the install/activate command, and how to skip a hook in an emergency (git commit --no-verify).

    line 39

“Common” is measured: kept by at least 6 in 10 of the 11 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

Project + existing hook detection

!ls package.json pyproject.toml Cargo.toml go.mod Gemfile 2>/dev/null

!ls .pre-commit-config.yaml .husky .lefthook.yml lefthook.yml .git/hooks 2>/dev/null

!cat package.json 2>/dev/null | grep -A20 '"scripts"'

Instructions

Set up (or improve) pre-commit hooks for this project. Use the checks/framework in $ARGUMENTS if given; otherwise pick the idiomatic tool for the stack and wire up the checks the project already supports.

Method

  1. Pick the right framework for the ecosystem, preferring one already in use:
    • JS/TS: husky + lint-staged (run linters/formatters only on staged files).
    • Python: the pre-commit framework (.pre-commit-config.yaml).
    • Polyglot / language-agnostic: pre-commit or lefthook.
    • If a framework is already configured, extend its config rather than introducing a second one.
  2. Use the project's real commands. Pull lint/format/typecheck/test commands from the scripts/manifest above (e.g. eslint, prettier --write, ruff, black, gofmt, cargo fmt). Don't invent script names or add tools the project doesn't have.
  3. Scope to staged files where the tool supports it (lint-staged, pre-commit) so the hook stays fast — a slow hook gets bypassed with --no-verify.
  4. Order checks fast-to-slow and fail early: format → lint → typecheck → quick tests. Keep the full/slow test suite in CI, not the hook, unless the user asks.
  5. Write the config to the conventional path and add any needed prepare/install step (e.g. "prepare": "husky" in package.json). Note the one command the user runs to activate hooks locally.

Rules

  1. Only wire checks the project can actually run — verify the command exists in scripts/manifest before adding it. If a desired check has no tooling yet, say so instead of inventing it.
  2. Don't add new dependencies beyond the hook framework and its standard companions, and call out exactly what gets installed.
  3. Keep hooks fast and staged-file-scoped; heavy work belongs in CI (point to the ci-setup skill).
  4. Never weaken or auto---no-verify anything. The hook should be bypassable by the user, not by default.
  5. After writing, summarize each hook, the install/activate command, and how to skip a hook in an emergency (git commit --no-verify).

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