What it is.
Hooks fire at points in the session lifecycle, and matcher patterns decide which events yours responds to. Your handler is a script, so the rule is code and not an instruction anyone can skip.
For marketing work this is how a voice rule stops being advisory. A hook can run your banned-word check on every draft and refuse the ones that fail, so the rule is enforced and not suggested.
Hooks live in configuration files at defined locations, so a team can share them and a project can carry its own.
What you get.
- Your own script running at defined points in a session.
- Matcher patterns, so a hook only fires on the events it should.
- Hook locations that let a project carry its own rules.
- A failing check can block the action, so the rule is enforced.
- A shared setup, so a team's standards apply to everyone.
How to set it up.
Pick one rule you keep having to repeat, since that repetition is what a hook is for.
Write the check as a script that exits non-zero when it fails, and test it outside the session first.
Read the hook lifecycle and choose the event that fires at the right moment.
Set a matcher pattern so the hook only runs on the relevant events.
Put the configuration in the project location if the whole team should get it.
Test with an input you know should fail, because a hook that never fires looks identical to a passing check.
Use cases
Enforce the style guide
Run your own script at the point where the rule would get broken.
Fire on the right events only
Use matcher patterns so the hook stays quiet the rest of the time.
Make a convention automatic
Turn the thing you keep reminding people about into a check.
Best for
Voice and brand rules
A banlist in a document gets skipped. A banlist in a hook does not.
Team standards
Project-level hooks apply the same checks to everyone without a review meeting.
Guardrails on file changes
A hook can refuse an action instead of asking somebody to notice it.