Hooks: automating the things you keep forgetting

Writing 'always run the formatter after editing' into your project instructions puts the rule into the same pool as everything else competing for attention. It works, most of the time, until the session gets long.

A hook is different in kind. It is executed by the harness around a tool call, not remembered by the model. It fires on the hundredth edit exactly as it fired on the first.

So the useful question is not what rules to write down, but which rules should stop being rules and become machinery. Anything phrased as 'always' or 'never' is a candidate.

A pre hook runs before a tool call and can block it. Use it to prevent things that are expensive to undo: an edit to a generated file, a command with a destructive flag, a write outside the project.

A post hook runs afterwards and cannot block anything. Use it for maintenance that should always follow an action: formatting, a type check, a notification.

The distinction matters when choosing. A pre hook that only warns has no advantage over an instruction; its value is entirely in refusal. A post hook that tries to prevent something is running too late.

Format after edit. A post hook that runs your formatter on any file that was written. Removes an entire category of diff noise and a whole class of review comments.

Block edits to generated files. A pre hook that refuses writes to build output or generated directories. Editing generated code is a mistake that is invisible until the next build silently discards the work.

Notify on completion. A post hook on session end that tells you it finished. Small, and it stops you watching a terminal.

Add more only in response to something that actually went wrong. Speculative hooks accumulate into a configuration nobody understands.

Three properties to design for:

Fast. A hook that takes two seconds costs two seconds every time. Anything slow should be triggered manually rather than hooked.

Quiet on success. A hook that prints on every run trains you to ignore its output, which defeats the one time it has something to say.

Specific in its matching. Match narrowly — this tool, this file pattern — so it fires when intended and not on everything adjacent.

Anything requiring a decision. A hook cannot weigh a situation. If the right action depends on context, it is not a hook.

Long-running processes. Test suites, builds, deployments. Trigger them explicitly; hooking them makes every small action slow.

Anything with side effects outside your machine. A hook that posts, deploys or sends is a hook that will eventually do so at a moment you did not intend.

The safe boundary: hooks may check, format, block and inform. They should not publish, deploy or delete.

Keep a note during a week of work of every time you fix the same category of thing — a formatting issue, a forgotten step, a file that should not have been touched.

Anything appearing twice is a hook. Anything appearing once is probably an accident.

This is also the honest way to keep the set small. Hooks written in response to real repeated friction are used and trusted; hooks written speculatively are the ones you eventually disable to debug something else and never turn back on.