Propose a minimal pre-commit hook set that fits the repo's existing tooling
Category: Tooling · Updated 2026-09-22 · Tools: Both
Use this on a repo that has lint/format/test tooling configured but nothing enforcing it before a commit lands, so issues get caught later than they need to. Best proposed first rather than installed outright, since an overly strict hook set on an existing repo can block commits with a wall of pre-existing violations. Small usage.
Full prompt
Look at what linting, formatting, and testing tooling this repo already has configured (config files, package.json scripts, CI config, or equivalent) and propose a minimal pre-commit hook setup built from those existing tools — don't introduce a new linter or formatter the project doesn't already use. Prefer running checks only against staged/changed files rather than the whole repo, so commits stay fast. Before proposing full-repo lint or test as a hook, check whether running it now would fail on pre-existing violations elsewhere in the codebase, and flag that if so, since a hook that blocks on day one due to unrelated existing issues will just get bypassed or disabled. Show me the proposed hook configuration and wait for confirmation before installing anything or modifying git config.
Tips
- The pre-existing-violations check matters a lot in practice — a hook that immediately blocks unrelated commits over old issues gets disabled within a week
- Scoping checks to staged/changed files rather than the whole repo is usually the difference between a hook people tolerate and one they route around
- Review the proposed config yourself before installing — confirm it matches tooling your team actually already uses, since introducing a new tool through a hook is a bigger decision than it looks
Still waiting on a reset? See what to do when you hit the limit, or check Codex / Claude time since last reset.
Back to the prompt library · Subscribe: all-products feed