Claude Code Hooks: Rules Nobody Builds

Writing a rule in CLAUDE.md once should be enough. Your agent reads it first, adopts the standard, and follows it. That is how the system is supposed to work.

It is not how it always works.

Your output shifts between sessions. A pattern you corrected last week appears again this week. A standard that held for ten files slips on the eleventh. You catch it in review. You fix it. You tell the agent again. You are the enforcement layer - and you are doing it manually, one correction at a time.

The problem is not the model. The problem is that rules written in CLAUDE.md ask Claude to remember them. Remembering is not enforcement.

Hooks do not ask Claude to remember anything. They run automatically before and after every tool call - whether or not the agent recalls the rule, whether or not the context holds - and the standard applies regardless.

Two types of hook

Claude Code has two hook types. Each fires at a different point in the tool call.

PreToolUse hooks run before Claude touches anything. The agent has decided to take an action - write a file, run a command, call an API - and the hook intercepts it first. The hook can inspect the action, send Claude a warning, or block it entirely. A PreToolUse hook on a critical configuration file reminds the agent of the rule before it proceeds. A PreToolUse hook on a destructive command blocks execution until conditions are met.

PostToolUse hooks run after the action completes. The agent has written the file, and the hook reads what landed. It can check for patterns that should not be there, validate the structure, and send a correction back before the next step begins. A PostToolUse hook on a component file catches a forbidden pattern and auto-corrects it before the session moves on.

The key difference is timing. PreToolUse prevents. PostToolUse corrects.

What a hook looks like in practice

Hooks live in .claude/hooks/ as shell scripts. Each script reads the tool call as JSON from stdin and exits with a code that tells Claude what to do next.

Exit code 0 means pass - the action continues. Exit code 1 blocks it - Claude receives the hook output as an error and stops. Exit code 2 sends a warning without blocking - Claude reads it as context and proceeds with the action.

A hook that warns Claude before it edits a layout file checks the file path, prints a reminder about the known pattern to avoid, and exits with code 2. The warning becomes part of the agent’s context for that tool call - not a note to read later, but an instruction that applies right now.

A hook that validates a blog post after it is saved reads the file, scans for forbidden characters and missing frontmatter fields, and exits with code 1 if something fails. Claude reads the validation output and knows exactly what to fix before moving forward.

Where hooks sit in the full system

Hooks are the fifth layer in the Agent Orchestration Layer framework - the layer most builders reach last, because the layers before it have to be in place first.

CLAUDE.md sets the rules. The /docs folder holds the project memory. Skills compress repeated tasks. MEMORY.md carries context forward. Hooks are what makes all of it hold under pressure.

Most builders write a CLAUDE.md and stop there. The rules are in the file. The agent is supposed to follow them. The problem is that “supposed to” is not enforcement - it is expectation. And expectations degrade over long sessions, repeated tasks, and context windows that fill faster than any file can track.

Hooks close the gap between what the rules say and what actually happens.

The starting point

The Claude System Starter Kit includes a Hooks guide covering both hook types, the three-exit-code system, and the first hooks most useful to set up on a real project.