Ward vs pre-commit: what is the difference?
Updated
The pre-commit framework manages Git hooks that run when you commit. Ward checks code at four moments, starting with every edit your coding agent makes, and installs its own Git hooks for the commit and push layers.
What does the pre-commit framework do well?
From the pre-commit documentation: it is a framework for managing and maintaining multi-language pre-commit hooks. You list hooks from many repositories in .pre-commit-config.yaml, and it installs and runs them on git commit. Hooks can also run on other Git stages, and you can run them on all files by hand. If you want to pick formatters and linters from a large shared catalog of hooks, it is a good fit.
What does Ward do differently?
Ward starts earlier. After each agent edit, Ward runs a fast check on the edited files and gives the failure to the agent, so the agent fixes it before it ever commits. Ward also has its own rules, tests and coverage, security scanners and CI layer, all in one ward.toml. For Git it installs hooks with ward init --quality-hooks: pre-commit runs the fast checks on staged files, and pre-push adds compile, tests and coverage.
When is pre-commit the better choice?
- Your team already uses it and the hooks you need exist in its catalog.
- You only want hooks at commit time, with no agent integration.
- You want to mix many small, independent hooks from different authors.
Can I use Ward and pre-commit together?
Yes. Ward’s documentation says a hook manager that rewrites hook files may drop Ward’s section, and tells you to add ward check --profile pre-commit to that manager’s configuration instead. With the pre-commit framework, that means a local hook that calls Ward. You keep your existing hooks, and Ward adds the agent edit layer and the stricter layers.
ward check --profile pre-commit
Where do I go next?
Ready to try it? Install Ward and run ward init in your project.