I used to have a big rules folder with all my coding agent rules, indexed in CLAUDE.md. The expectation was agents would load the right rules when the moment was right. It usually did the right thing, usually.

You’ve probably experienced this. Somewhere in a long session, Claude gets to a place, let’s say it went from writing backend code to the frontend, starts adding a test, and ‘forgets’ to look up the frontend test rules. It’s an agent, it’s not clockwork. If only we could make it load the right guides like one...

Context fades as the session moves on. An agent working away on a ticket doesn’t always ‘remember’ we have hinted at a doc with frontend test rules 15 turns ago. Even if we preload all the rules upfront, there’s no guarantee they will all be followed precisely either. Besides, all those rules are just noise until they become relevant.

This is what I do. Rules that apply all the time get loaded upfront: mostly basic working practices. The rest are injected into the conversation when the agent is about to do the relevant thing.

Here is a real example. I have a design guide to optimize Claude ultra code workflows for token efficiency. If I link it in CLAUDE.md, it’s not always followed and I burn bunch of tokens. A hook makes it unmissable:

hook: runs before every tool call
  if this call is spawning a workflow or fleet of workers:
    block it once; reply: “Read workflow-design-guide.md before building the workflow.”
  the retry goes through

The key is to BLOCK the first call to create a workflow, put the rule into the conversation, and let the now-informed agent retry.

Once you understand how it works, you can get creative. Put logic inside the hook so it responds differently to each situation. For tests:

hook: runs before every file write
  if the file ends in .test.ts or .test.js:
    in frontend/ → block once; reply with the frontend test rules
    in backend/  → block once; reply with the backend test rules
  everything else goes through

Claude now sees only the conventions for the side it’s touching. You don’t need both sets of test rules loaded in every session.

This is the crux of it: situational rules arrive at the situation; anything reliably detectable can become a gate.

You get more control, and Claude gets room to work without carrying an enormous guide through every step.

Here’s something you can try for yourself. Prompt Claude Code to add a hook like the example below. Describe your own file extensions, folder names and doc paths. When agents try to edit those files, they will stop and read the doc first.

The prompt: “Add a file write hook that looks for writes to any .test.ts file and, depending on whether the file is under frontend/ or backend/, responds with ‘retry after reading docs/[frontend|backend]-test-rules.md‘. It should block once per rule doc.”

If you want to take it to the next level, plant rule files in your folder structure and make the hook locate them. The hook stops being one big switch statement you keep updating. Each file carries its own note, right where the work happens.

One last note. I came across Birgitta Böckeler’s writeup on harness engineering, on Martin Fowler’s site. She splits an agent's harness into guides - advice given before the agent acts, and sensors - checks on what it did after. The hooks here take the best of both: they watch like a sensor, advise like a guide, and fire right as the agent is about to act.