dev-pre-commit/SKILL.md
Use when setting up pre-commit hooks, configuring Husky, adding lint-staged, or enabling commit-time formatting, type checking, or testing. Installs and wires up Husky v9, lint-staged with Prettier, and optionally typecheck and test scripts.
npx skillsauth add paulund/skills dev-pre-commitInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Check for package-lock.json (npm), pnpm-lock.yaml (pnpm), yarn.lock (yarn), bun.lockb (bun). Use whichever is present. Default to npm if unclear.
Install as devDependencies:
husky lint-staged prettier
npx husky init
This creates .husky/ and adds prepare: "husky" to package.json.
.husky/pre-commitWrite this file (no shebang needed for Husky v9+):
npx lint-staged
npm run typecheck
npm run test
Adapt: replace npm with the detected package manager. If typecheck or test scripts are absent from package.json, omit those lines and inform the user.
.lintstagedrc{
"*": "prettier --ignore-unknown --write"
}
.prettierrc (if missing)Only create if no Prettier config exists:
{
"useTabs": false,
"tabWidth": 2,
"printWidth": 80,
"singleQuote": false,
"trailingComma": "es5",
"semi": true,
"arrowParens": "always"
}
.husky/pre-commit exists and is executable.lintstagedrc existsprepare script in package.json is "husky"npx lint-staged to confirm it worksStage all changed/created files and commit with message: Add pre-commit hooks (husky + lint-staged + prettier)
This runs through the new hooks as a smoke test.
MUST DO
prettier --ignore-unknown to skip unparseable files (images, etc.)MUST NOT DO
.husky/pre-commit.prettierrc if a Prettier config already existsdevelopment
Use when implementing any logic, fixing any bug, or changing any behaviour. Use when you need to prove code works, when a bug report arrives, or when modifying existing functionality. Do NOT use for config changes, data migrations, or dependency updates.
development
Use when starting a new feature, when requirements are unclear, when asked to write code without a clear spec, or before any non-trivial implementation. Do NOT use for trivial bug fixes or one-line changes.
development
Use when you want authoritative, source-cited code free from outdated patterns. Use when building with any framework or library where correctness matters. Detects the stack from dependency files, fetches official documentation, implements following documented patterns, and cites sources for every framework-specific decision.
development
Use when preparing to ship a feature, release, or deployment. Use before merging to main, creating a release, or deploying to production. Do NOT use for CI-only changes or internal refactors that don't reach production.