Mine your history for hooks
The best source of new hooks is your own session history. Group past sessions by what went wrong, and the top failures are your backlog.
Find your hooks by auditing your own transcripts
Companion changelog to the guide at claude-guide.sauer.com.au. This week’s addition lives in Chapter 4 (Hooks).
The Hooks chapter already made the core case: a rule the harness enforces beats a rule the assistant merely reads. What it didn’t tell you was how to find the hooks that matter to you specifically. This update fixes that, and the method is almost embarrassingly direct.
The method: read your own history
Your past sessions are on disk. The rules your assistant keeps breaking are sitting in them in plain sight: not as code mistakes, but as the same correction made twice. So don’t guess at your hook backlog. Build it from evidence:
- Take a month of your own transcripts.
- Cluster the moments where you pushed back, corrected, or repeated yourself, grouped by what went wrong, not by what the task was. (This is itself a good job to hand the assistant: point it at the logs and ask for the clusters.)
- Rank the clusters by how often they cost you. That ranking is your hook backlog.
The pattern that comes back is rarely “it can’t code.” It’s behavioural and repetitive: it claimed something was done when it wasn’t; it did work you didn’t ask for; it kept asking permission you’d already given; it leaned on a stale note instead of checking the live system.
Two hooks that fall straight out of the audit
Neither of these blocks a file path. They were the two highest-frequency clusters, and both are worth copying.
A Stop guard that refuses an unproven
claim. It reads the assistant’s final message. If that message
asserts done / fixed / deployed / working but shows no evidence
in the same breath (no command output, no status code, no commit hash,
no figure), it blocks once and asks for proof, or for an honest “I
couldn’t verify this.” “It works” stops being something the assistant
can say for free.
A UserPromptSubmit injector that fires only on
heat. Most of the time it stays silent. But when your message
reads as a terse order or a correction (just do it, I already told
you, stop asking), it quietly prepends your hardest-won rules to
that single turn. The discipline arrives exactly where the record shows
it tends to slip, and costs nothing on the calm turns.
The framing worth keeping
Why a hook and not another line in your standing instructions? Because a rule the model merely reads can be rationalised past under pressure; a rule the harness enforces cannot. So treat the third repeat as a signal: the third time you add the same instruction to CLAUDE.md, that’s not a documentation gap. It’s a hook waiting to be written.
How to spot it in your own setup
- You’ve corrected the same behaviour more than twice: stop editing CLAUDE.md and write the hook.
- The assistant says “done” and you’ve learned to re-check before believing it: that’s the Stop-guard hook.
- Your terse, under-pressure instructions are the ones most likely to be mishandled: that’s the heat-triggered injector.
The full section is in Chapter 4 of the guide.
The cards
