Determinism is cheap; instrument it anyway
What a hook is and why it is different from a skill
A hook is an event-driven piece of automation. It fires when a specific event occurs — a file is saved, a session ends, a command is run — and performs a defined action in response. The behaviour is deterministic: the same event produces the same response every time, with no involvement from a model and no tokens spent. This makes hooks structurally different from skills. A skill engages the assistant on a task; a hook bypasses the assistant entirely. The two are complementary. Skills handle the work that requires judgement; hooks handle the work that does not.
The events worth hooking
A few events repay being hooked. File save, to run a formatter or commit the change to version control. Session end, to log what was done and to play a small sound so the worker knows the agent has finished. Session start, to remind the worker about anything pending from the previous session. Command completion, to surface a result that would otherwise live only inside the agent's output. The criterion for whether to add a hook is that the same response is right every time the event occurs and the cost of running it incorrectly is small. If either condition fails, the work belongs in a skill, not a hook.
Instrumentation prevents silent failure
The risk of automation in this layer is not that it does the wrong thing — the determinism makes that easy to spot — but that it fails silently and continues to appear to be working. A hook that no longer fires, a formatter that is broken, a log that has stopped accumulating: the visible state of the system looks unchanged, and the worker only notices weeks later when something downstream goes wrong. The cheap defence is the discipline of one industrial-engineering tradition: surface defects immediately. Hooks should log every firing, alert when an expected firing is missed, and refuse to mask their own failures.
Where to draw the line with deterministic automation
There is a natural temptation to push more and more behaviour into hooks because they are cheap and predictable. The honest limit is that anything requiring interpretation belongs in a skill, even if a tempting heuristic could be coded into a hook. Determinism that gets the easy ninety percent right and produces silent wrongness on the rest is worse than no automation at all. A working stance is to keep hooks for moves that the worker is willing to defend in every case the event will ever occur, and to push everything else into the assistant where judgement can still be applied. Boundaries set this way tend to hold.
Of the small repetitive things you do at the end of each working session, how many would be uncontroversial to have happen automatically every time, regardless of context?