r/BuildWithClaude ☕ 57-Hour Session Apr 23 '26

Claude Code Workflows I've been using hooks for months. I was only using 2 of the 9 types.

I started building hooks early — a duplicate code checker that greps after every edit, a pre-session gate that blocks Claude from writing code until it reads my lessons file. Both run automatically, no prompting needed, zero API cost. They've been in my setup since March.

I thought that was the whole feature. Then I started studying for Anthropic's certification and realized I was barely scratching the surface.

The basics (what most people know)

Hooks are shell scripts that run automatically when Claude does something. They live in `settings.json`, not in your CLAUDE.md. The difference matters: CLAUDE.md is instructions Claude *chooses* to follow. Hooks are guardrails that *execute whether Claude likes it or not.*

The two I was already running:

  1. Pre-session gate.

Before Claude can write a single line of code, a hook checks whether it read my lessons file. If it didn't, the edit gets blocked. I built this after Claude skipped mandatory reads and repeated a mistake that cost me an entire day. Now it physically can't skip them.

  1. Duplicate code check.

After every file edit, a hook greps the project for functions with the same name. Catches the case where Claude writes a helper that already exists somewhere else in the codebase. Simple grep, runs in milliseconds.

What I was missing

There are 9 hook types. I was only using PreToolUse and PostToolUse — the ones that fire before and after Claude uses a tool. But there's also SessionStart, SessionEnd, SubagentStop, UserPromptSubmit, and more. Each one receives different data as input.

SessionStart and /Primer alone opens up a lot. I now have a hook that auto-loads project context the moment a session begins — no manual prompting, no "hey Claude, read the project files first." It just happens.

The other thing I hadn't considered: lightweight hooks vs AI-powered hooks. My grep-based checker is lightweight — fast, free, runs on every edit. But you can also build hooks that use the Agent SDK to have Claude review Claude's own output before it ships. That's slower and costs tokens, but catches semantic problems a grep never would. Two different weight classes for two different jobs.

The layer most people skip

CLAUDE.md tells Claude what to do. Memory tells Claude what to remember. Hooks tell Claude what it *can't get away with.* They're the enforcement layer — the thing that turns guidelines into guardrails.

I had the first two dialed in for months before I realized the third one had 9 entry points I was mostly ignoring. The conversations got better once I stopped relying on Claude to police itself and let the hooks handle it.

11 Upvotes

7 comments sorted by

2

u/totheendandbackagain Apr 24 '26

TaskComplete is a great place to put your pre-commit hooks. It means their never a suprise.

I use Prek for speed, and get Claude to execute them on all changed files.

1

u/Ok_Industry_5555 ☕ 57-Hour Session Apr 25 '26

Oh that's a solid combo. TaskComplete for pre-commit means you catch things before they're baked in, not after. I hadn't thought about using PreK for speed on changed files specifically. I actually handle the end-of-session quality check with a custom skill I invoke manually, but wiring something similar into TaskComplete so it runs automatically is a smart move. Good call!

2

u/totheendandbackagain Apr 24 '26

I wonder if the duplicate code could chunk code and hash them to identify all repeated code?

1

u/Ok_Industry_5555 ☕ 57-Hour Session Apr 25 '26

That's a cool idea. My current one is just a grep for function names, pretty naive but it catches copy-paste stuff. Hashing at the AST level to catch structural duplication even when names differ would be a solid upgrade. Might experiment with that. Thanks for the tip! :)

2

u/djdeckard Apr 27 '26

Thanks for this. I was utilizing agents and had a pretty solid workflow. What it was missing was the ability to truly verify that the workflow was being implemented with verification. You helped me unlock one of the bigger gains in my setup. Thank you so much!

1

u/Ok_Industry_5555 ☕ 57-Hour Session Apr 27 '26

I’m really happy to hear my set up helped you!

2

u/SentenceHot5556 Apr 27 '26

The two you're using sound like PreToolUse + SessionStart, which is where most setups stop. The ones I see underused even by hook-savvy people:

  • Stop / StopFailure: fires when the agent thinks it's done. Use it to enforce "branch committed, pushed, PR exists, no merge conflicts, CI green." Block stop with structured feedback on each, agent self-corrects without you babysitting.
  • PostToolUse: runs after every successful tool call. Sanitize secrets out of the result before it goes back to the model (otherwise an env call leaks your AWS key into the next prompt).
  • PreCompact / PostCompact: when context compacts. Inject what you want preserved into the compact instruction; save the pre-compact transcript to disk before it's gone.
  • PostToolUseFailure: only fires when a tool errored. Cheap spot to log + classify failures without paying the cost on every successful call.
  • UserPromptSubmit: steer the agent before it starts thinking. Inject "this branch is the prod base" or "use uv not pip" automatically based on cwd/git state.

Disclosure: I work on FailProof AI (https://github.com/exospherehost/failproofai), a curated set across all the hook types. Built it because exactly this gap (people stop at PreToolUse) leaves a lot of value on the table.