Configure Staged Formatting and Commit Checks

What it does

The source detects the package manager from lockfiles, installs Husky, lint-staged and Prettier as development dependencies, and initializes a pre-commit hook. Formatting uses Prettier with ignore-unknown so unsupported assets are skipped. Typecheck and test commands follow only if those package scripts exist. An existing Prettier configuration is preserved. The workflow closes with verification and an authorized commit that exercises the hook. Its purpose is consistent local feedback; server-side checks still need their own enforcement.

When to use it

• Add commit-time feedback to a JavaScript repository with existing checks.
• Reuse the project’s formatting rules for staged changes.
• Make missing typecheck or test scripts visible instead of inventing commands.

Step-by-step workflow

1. Inspect lockfiles, package scripts and existing hooks or formatter configuration.
2. Choose the project’s package manager and review required dev dependencies.
3. Initialize or merge Husky configuration without discarding current hooks.
4. Configure staged formatting followed by existing typecheck and test commands.
5. Verify the staged-file behavior and inspect the commit diff before any authorized commit.

Example request

Use setup-pre-commit to propose hooks for this pnpm project. Preserve our existing Prettier configuration and Husky checks. Run staged formatting first, then the actual package scripts that exist. If test is missing, explain that gap without creating a fake passing script. List dependency and prepare-script changes for review. Do not stage all files or commit unrelated work.

Worked example

A repository may have a typecheck script but no test script. The hook should run the real typecheck and explicitly report the missing test command. If the developer has partly staged a file, formatting can affect its working-tree or staged representation; review what lint-staged leaves behind before committing. An existing style configuration should govern the output rather than new default preferences. The validation should demonstrate the configured sequence, not merely the presence of a .husky directory.

What you get

A reviewed Husky hook, lint-staged configuration and dependency changes that use actual project scripts.

How to evaluate the result

• Confirm the detected package manager matches the lockfile.
• Verify existing formatter rules and hooks remain intact.
• Check a failing project command stops the commit path.

What you need

A supported Node package project, Git hooks, its package manager and authorization to add development dependencies. Hook execution may alter staged formatting.

Setup and activation

The publisher documents plugin setup for Claude Code, Codex and Copilot, and manual Agent Skills setup for Gemini CLI and other clients. Choose one distribution method per client to avoid duplicate skills. The engineering collection expects project-specific tracker, triage-label and document-location settings from setup-matt-pocock-skills. Keep referenced companion skills and files available. This catalogue review does not install or run them; scan the exact source before any later installation. Client tools, permissions and subagent support still need separate validation.

Limits and considerations

Local hooks can be bypassed and do not replace CI. A slow full test suite can make every commit expensive. Review existing prepare behavior before replacing it, and preserve partial staging and unrelated changes.

Related workflows

• Use retro to assess whether local checks prevent observed mistakes.
• Use code-review to inspect dependency and hook changes.

License and reuse

MIT at repository level (Copyright 2026 Matt Pocock). Preserve the copyright and permission notice when redistributing substantial source material; inspect any separately licensed dependencies or assets.

Further reading

• Reviewed SKILL.md (immutable commit)
• Publisher README: distributions and compatibility
• Reviewed MIT license