You keep forgetting to run the check. A hook never forgets — it fires whether or not anyone remembers. This is the machine underneath "rules don't enforce themselves."
There was a rule the operator believed in: at the start of every work session, read the project's running log so you don't redo or undo what got done last night. Simple. Sensible. And forgotten constantly — by the human in a hurry, and by the AI whose memory is wiped clean every session (each new chat starts from zero; it remembers nothing you didn't write into a file it reloads). A "remember to do X first" rule depends on someone choosing to remember X — and the one thing you can rely on is that, under pressure, nobody does. The check that only happens "when I remember" is the check that quietly stops happening.
"My rule was: every session, catch up on the log before touching anything. I meant it. And I'd skip it half the time because I was already typing the thing I came to do. The cost wasn't abstract — I'd undo work from the night before because neither of us had read what happened. I didn't need a louder reminder. I needed the catch-up to just happen without me deciding to do it."
"And my side is worse: I start every session blank. If you don't hand me the log, I can't 'remember' to read it — there's nothing to remember from. A rule that says 'the AI should read the log first' is asking the forgetful party to police the forgetting. The fix isn't asking harder. It's making the tool shove the log in front of both of us the instant the session opens — before either of us gets a vote."
Here is the one idea of this module. The program you run the AI inside of — call it the harness (for us, that's Claude Code, the app that wraps the model and actually executes things) — can be told: "at this exact moment, run this little script, automatically." That standing instruction is a hook. You list it once in a settings file, and from then on the harness fires it at the moment you named — at session start, or before a tool runs — with no decision from the AI at all. That's the whole difference from a written rule. A rule says "please do X" and waits for the AI to choose to. A hook just does X, the same way every time, because the tool — not the model — is the one running it. The AI can't forget a hook any more than a turnstile can forget to turn: nobody chose to run it, so there's nothing to skip.
SessionStart / PreToolUseA named instant the harness watches for: a session opening, or right before a tool fires. You pick which moment the hook hangs on.
Claude Code, not the modelThe program running the AI. It fires the hook at that moment — automatically, every time. The AI is never asked and never decides.
a tiny commandWhat runs: print the log, scan the staged files, block a bad command. Plain output or an exit code the harness reads and acts on.
The model: a written rule is a sticky note on the fridge that says "take your keys." A hook is a lock that won't let the door shut unless the keys are in your hand. The note depends on you reading it and choosing to obey on a chaotic morning; the lock just acts, every single time, whether or not you noticed the note. SessionStart = the lock checks the moment you reach for the door (the session opens). PreToolUse = it checks right before the door actually swings (a tool is about to run). Either way the machinery moves for you. That is why a hook is the enforcement underneath the rule: the rule names what you want; the hook is the part that doesn't wait for anyone to remember.
Coming up, you'll add one line to settings.json telling the harness: "at SessionStart, run a script that prints the last few lines of the project log." You wire it, close the chat, and open a brand-new session tomorrow — without thinking about the log at all. What appears?
tail the last lines of LOGS.md (print the end of the log file). For PreToolUse: scan what's about to happen and, if it's forbidden, exit 2 to block it (exit 2 is the one that blocks; any other non-zero only warns and the action still runs).settings.json under hooks, keyed by the moment. This is the one wiring step: from now on the harness — the Claude Code tool itself — runs your script at that moment. The AI never decides to.Same rule as always: answer it right, or the module isn't done.
CLAUDE.md — and why does that difference make it stick?A hook is automation the harness runs for you, not a request the AI chooses to honor. The rule says what you want; the hook is the part that happens without anyone remembering.
A working session-start-log.sh you drop into your harness — the Claude Code tool, the program running the AI. A SessionStart hook is a script the harness runs by itself the instant a new chat opens, and whatever it prints lands in the AI's context — so this one prints the last lines of your project's LOGS.md at the top of every session. Save it where the wiring expects it — ~/.claude/session-start-log.sh (it downloads to ~/Downloads, so move it there: mkdir -p ~/.claude && mv ~/Downloads/session-start-log.sh ~/.claude/) — then wire it once in settings.json; from then on the catch-up read happens whether or not you or the AI remember it. No more stepping on last night's work because nobody read the log. One honest limit, stated plainly: a SessionStart hook surfaces the log so it's in front of you both — it does not force anyone to act on it (that's a different mechanism — a blocking PreToolUse hook, which exit-blocks an action; you saw that flavor in the secret-commit module). This hook removes the remembering, not the judgment. Plus HOOK-MOMENTS.md: a plain-language map of which moment to hang a hook on — SessionStart vs PreToolUse vs the others — and what each one can and can't do. You now own a piece of the machine that catches you up on its own — and small hooks exactly like this are what let a non-coder run a whole fleet: once the routine stops depending on anyone remembering, the workflow becomes the asset the ban forced into existence.
Don't take "runs automatically" on faith — that's the whole lesson. But the first time, you'll almost certainly get the wiring slightly wrong. That's fine — it's a one-line fix, and watching it fail then fire is how you learn to trust it. Try it: wire the hook, but point LOGS_FILE at a path that doesn't exist (a typo, the wrong project). Open a fresh session:
Notice the hook didn't crash or vanish — it fired and told you the path was wrong (that's the exit 0 + plain message in the script, on purpose). Fix the one line — correct the path — re-open the session, and now it catches you up for real:
See the log at the top of a session you just opened, having typed nothing → the harness ran it for you. See a blank screen waiting for you to ask → it's not wired, and you're back to remembering. The difference between a rule and a hook is exactly this: you can watch it happen without choosing to.