Watch This If Your Coding Agent Is Ignoring Your Rules (You Need Hooks)
A walkthrough of why CLAUDE.md rules get silently skipped, and how to turn the ones that name an event into deterministic hooks instead.
Posted
2 days ago
Duration
Format
Tutorial
educational
Views
21.8K
355 likes
57 · 43
Big Idea
The argument in one line.
Rules are guidance a probabilistic model can silently skip, but hooks are deterministic code tied to a real event, so any instruction shaped like 'when X happens, do Y' belongs in a hook instead of another line in your rules file.
Who This Is For
Read if. Skip if.
READ IF YOU ARE…
You use Claude Code, Codex, or Cursor and have watched your agent skip a step in your CLAUDE.md or AGENTS.md file more than once.
You've been told your rules file is 'too long' and want a principled way to decide what to cut versus what to automate.
You want a concrete, working example of a Stop hook and a PreToolUse hook before building your own.
You're evaluating whether to let an agent self-edit its own system prompt over time.
SKIP IF…
You've never used a coding agent with a hooks system (Claude Code, Codex, Cursor) — the examples assume that primitive already exists.
You already have a mature hooks setup and just want new hook ideas, not the case for why hooks matter.
TL;DR
The full version, fast.
Coding agents treat CLAUDE.md rules as guidance, not law, because the underlying model is probabilistic and can silently skip a step, especially as the rules file grows (a cited study found letting an agent self-edit its own system prompt made performance worse, while adding hooks helped almost across the board). Hooks fix this by attaching deterministic scripts to specific lifecycle events, PreToolUse, Stop, SessionStart, and others, where the script's exit code becomes the enforcement mechanism: exit 0 allows the action, exit 2 blocks it and feeds the reason back to the agent. The practical move is an audit: read every rule and ask whether it names an event ('after implementing, run the tests') or encodes judgment ('money is integer cents, never floats'). The former becomes a hook, the latter stays a rule, and anything that's neither should be deleted.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Cold open: hooks are the most underappreciated, most-requested piece of content on the channel.
00:39 – 02:13
02 · What a hook actually is
Definition: a hook is a deterministic action tied to a coding-agent event, one of five core harness components alongside rules, sub agents, MCP servers, and skills.
02:13 – 04:23
03 · Why your rules get ignored
LLMs are probabilistic and can silently skip a rule; the classic example is an agent claiming a test suite passed when part of it is still red.
04:23 – 07:17
04 · Too many rules make agents worse
Cites Anthropic's 80% system-prompt cut and a self-evolving harness study where letting an agent rewrite its own rules scored below baseline, while adding hooks helped.
07:17 – 08:18
05 · The hooks-create skill
Introduces the free hooks-create skill: describe the guarantee you want in a sentence and it interviews you, then builds and wires up the hook.
08:18 – 09:58
06 · Sponsor: MindsHub Cowork
Sponsored segment for MindsHub Cowork, an agentic workspace that lets you mix models/providers per workflow step.
09:58 – 12:01
07 · Guarantee your tests with a Stop hook
Live demo: a Stop hook (stop_tests_must_pass.py) runs the test suite whenever the agent tries to end its turn and forces it to resume and fix failures.
12:01 – 13:28
08 · How a hook talks back
Explains the exit-code contract: exit 0 allows/passes, exit 2 blocks and returns feedback to the agent, any other code is a script error.
13:28 – 15:58
09 · Hooks for security
Demo of a PreToolUse hook blocking a read of .env, with the agent adapting by reading .env.example instead; introduces block-vs-observe and the exit-code-is-the-API diagram.
15:58 – 18:09
10 · A hook for every event
Walks the full event menu (PreToolUse, PostToolUse, UserPromptSubmit, SessionStart/End, Stop/SubagentStop, PreCompact, Notification) and gives the block-gate vs observe-log rule of thumb.
18:09 – 20:06
11 · The audit: event or judgment?
The core framework: for each rule ask if it names an event (convert to hook) or encodes judgment (keep as a rule); anything that's neither gets deleted.
20:06 – 21:59
12 · Every rule I'd turn into a hook
Walks his own CLAUDE.md line by line against the framework: session-start git status + DECISIONS.md read, pre-edit citation file coupling, the .env block, and the Stop-hook test run.
21:59 – 22:35
13 · Paste the rule, get the hook
Demos pasting a rule from his own working-agreement file straight into the hooks-create skill, which picks the event, writes the script, and wires it into settings.json.
22:35 – 23:07
14 · Hooks don't replace your rules
Closing caveat: hooks complement rules rather than replacing them; only the process-shaped instructions should move.
Atomic Insights
Lines worth screenshotting.
Rules in CLAUDE.md or AGENTS.md are guidance an LLM can skip; hooks are deterministic scripts tied to an event, which is why they're described as guarantees, not suggestions.
A study on self-evolving coding-agent harnesses found that letting an agent rewrite its own system prompt over time made performance worse, not better.
In the same study, adding hooks (called middleware) improved performance on nearly every task type except the hardest ones.
Anthropic reportedly cut Claude Code's system prompt by 80%, evidence that a bloated rules file can hurt an agent more than help it.
The exit code a hook script returns is the entire communication channel back to the agent: exit 0 allows the action, exit 2 blocks it and passes the reason as feedback.
A PreToolUse hook that blocks reads of .env can also redirect the agent to read .env.example instead, so the block becomes guidance rather than a dead end.
The rule of thumb for hook design: pre-event hooks (PreToolUse, Stop, UserPromptSubmit) can block an action; post-event hooks (PostToolUse, Notification) can only observe and log.
The audit test for any line in a rules file is one question: does this line name an event, or does it encode judgment? Naming an event means it should become a hook.
A rule that is neither judgment nor an event, like 'write clean code', isn't adding new instruction the model doesn't already have, so it can just be deleted.
Hooks are cross-tool: the same event-plus-exit-code pattern works whether the coding agent is Claude Code, Codex, or Cursor.
Hooks don't replace rules; a hooks setup still needs judgment-encoding rules like coding conventions and constraints alongside the deterministic layer.
Takeaway
Turn every 'when X happens, do Y' rule into a hook.
WHAT TO LEARN
A coding agent's rules file is guidance a probabilistic model can skip, but attaching a deterministic script to a real lifecycle event turns that same instruction into a guarantee.
01Nobody is using hooks
Hooks are described as the most underappreciated part of any AI coding assistant, seen missing across hundreds of audited developer and company setups.
02What a hook actually is
A hook is a deterministic action guaranteed to fire on a defined coding-agent event, distinct from the four other harness components: rules, sub agents, MCP servers, and skills.
Rules and skills are both guidance the agent can choose to follow or not; a hook is the one component built to guarantee behavior every time.
03Why your rules get ignored
Large language models are probabilistic, so the same rule can be interpreted or applied differently across runs.
The classic failure case: an agent claims it finished testing while part of the test suite is still failing, because it missed a step in a longer workflow.
This gets worse in larger codebases where a validation workflow has many individual checks for the agent to remember and execute in order.
04Too many rules make agents worse
Anthropic reportedly cut Claude Code's system prompt size by about 80%, suggesting a smaller rules file can outperform a larger one.
A cited study let a coding agent evolve its own system prompt over many tasks and found performance dropped versus the unmodified baseline.
In the same study, adding hooks (framed as middleware) improved results across nearly every task difficulty except the hardest tier.
05The hooks-create skill
The hooks-create skill turns a one-sentence description of a desired guarantee into a fully wired-up hook through an interview process.
The skill is Claude Code specific by default but can adapt its output for other agents like Codex or Cursor if you tell it which tool you're using.
07Guarantee your tests with a Stop hook
A stop_tests_must_pass.py hook runs the project's test suite whenever the agent tries to end a turn and reports failures back if anything is red.
When the hook blocks, the agent doesn't just get an error; it resumes and works to fix the specific failures the hook surfaced.
08How a hook talks back
A hook script can be written in bash, TypeScript, Python, or anything else; the language doesn't matter, only its final exit code does.
Exit 0 means the check passed or the conversation can proceed; exit 2 means something is blocked and must be addressed before continuing.
09Hooks for security
A PreToolUse hook can detect an attempted read of .env (via a regex match) and block it before the file's contents ever reach the model's context.
The block message can guide the agent toward a safe alternative, such as reading .env.example, so the agent still makes progress instead of stalling.
The same pre-tool-use pattern generalizes to other security guarantees, like blocking a recursive force delete.
10A hook for every event
The full event menu covers PreToolUse, PostToolUse, UserPromptSubmit, SessionStart/SessionEnd, Stop/SubagentStop, PreCompact, and Notification.
Pre-event hooks (before a tool call, before stopping) can block; post-event hooks (after a tool call, notifications) are limited to observing and logging.
Post-event hooks are described as good for building an audit trail over time, useful for later spotting opportunities to improve the workflow.
11The audit: event or judgment?
The core test: for each line in a rules file, ask whether it names an event ('when this happens, do this') or encodes judgment ('never use floats for money').
Lines that name an event should become hooks; lines that encode judgment should stay as rules; lines that are neither should be deleted rather than kept.
12Every rule I'd turn into a hook
Session-start rules like 'run git status and read DECISIONS.md' map directly to a SessionStart hook so the agent never starts a turn without that context.
A rule like 'before editing routes, read the citations file first' becomes a PreToolUse hook that blocks an edit until the coupled file has been read in that session.
Rules like 'never read the .env file' and 'log every command you run' map to PreToolUse and PostToolUse hooks respectively, security and observability guarantees.
13Paste the rule, get the hook
Pasting an existing rule straight into the hooks-create skill was enough for it to pick the right event, write the script, and update settings.json automatically.
14Hooks don't replace your rules
Hooks are a complement to rules, not a replacement; the rules that encode genuine judgment and convention still belong in the rules file.
Glossary
Terms worth knowing.
Hook
A script tied to a specific event in a coding agent's lifecycle that runs automatically and, through its exit code, can allow, block, or otherwise affect what happens next.
PreToolUse
The hook event that fires right before the agent makes a tool call, letting a script inspect and potentially block that call before it runs.
Stop hook
A hook that fires when the agent believes it has finished a turn, commonly used to run a check like a test suite and force the agent to keep working if it fails.
SessionStart hook
A hook that fires when a new agent session begins, often used to inject required context like a decisions log or core memory file.
Exit code 2
The convention used by Claude Code and similar tools where a hook script returning exit code 2 blocks the agent's action and sends the script's message back as feedback.
Deterministic
Behavior that happens the same way every time, as opposed to the probabilistic, sometimes-inconsistent behavior of a language model following written rules.
Harness
The surrounding system, rules, sub agents, MCP servers, skills, and hooks, that extends a raw coding model into a full agentic workflow.
MCP server
A connector that gives a coding agent access to an external platform or data source as one of the five core components of an agentic harness.
Skill
A reusable, describable workflow or prompt that a coding agent can invoke, distinct from a hook because it's guidance rather than a guarantee.
“You go through each section or line of your rules and you ask yourself, is this naming an event or is it encoding judgment?”
the entire framework compressed into one repeatable question→ newsletter pull-quote↗ Tweet quote
22:50
“Hooks don't replace your rules. They complement each other.”
the necessary caveat that keeps the video's thesis from overreaching→ IG reel cold open↗ Tweet quote
The Script
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
17px
metaphor
The most underappreciated part of every single AI coding assistant is hooks. I've personally seen the AI coding system for hundreds of developers and entire companies, and almost every single time, there is not enough use of hooks.
They are so incredibly powerful and almost always underappreciated. And so in this video, I wanna show you what hooks are, why they're so incredibly valuable, and how you can build your own.
So you can make your AI coding workflows more reliable by building in guarantees. This is the big word for today. And let me tell you, this is the most requested piece of content on my channel.
So I'm super excited to get into this with you. Now, I'll make hooks very concrete for you throughout this video. But to give you the quick definition right now to get started, hooks are actions that you want to guarantee are performed whenever we hit certain events within our coding agent.
There's a whole event menu that we'll get into as well. But for example, right before your agent is going to read a file or right when the conversation stops, we can fire an action that might perform an audit or block things for the sake of security, maybe log things for observability. There are so many uses of hooks and we'll get into examples for all of them.
And no matter the coding agent you're using like Codex, ClodCode, or Pi, they essentially all support this primitive of hooks. It's one of the core five components of any AI coding assistant that you build up to extend the harness and really create your own AI coding workflows. So we have rules, which we're gonna talk about a lot here as well.
We have our sub agents to delegate work, MCP servers to connect to our platforms, skills which are our workflows, our reusable prompts, and then we have hooks which are our deterministic automations. And you'll hear me say deterministic a lot in this video because deterministic is pretty much equivalent to guarantee.
Right? Like everything else that we have for our coding agent, like skills and rules, they're guidance for the agent. It's not a guarantee that it's going to follow the full workflow or listen to every rule every single time.
That is why hooks are so powerful. It's the one thing we build into our coding agent that is actually going to ensure that something is happening the same way as it should every single time. And so if you're wondering right now, should I watch this full video?
The answer is yes. If you've ever had a time with your coding agent where you just get so frustrated because no matter how specific you are about some rule within your claw dot m d or agents dot m d, the agent doesn't always follow it. And that happens all the time because large language models are probabilistic.
They don't interpret your instructions or your workflows the same way every single time and sometimes they just miss rules or they miss a step in the workflow and that becomes so frustrating.
And one really classic example that I run into myself is typically when you have your agent perform any kind of implementation, you have rules that guide it through checking its own work and validating things after. So you have a step by step process like how to run your test suite for example.
But agents will sometimes miss different parts of your test suite. And so they'll say they're done and that they did all the testing they needed to, but part of your test suite is still red. And so the agent didn't fully validate its work.
And this is especially common for larger code bases where there's just a lot of checks that have to be performed. And so this is a really classic example where we try to fit something within our rules that really should be a hook so we can guarantee. Like right when the conversation is done, we'll use a stop hook to run the tests deterministically.
We are guaranteeing the tests to be run. If there are any failures, we're gonna force the agent to resume and fix those. And so this is a really good example that I'll dive into more in a little bit with you.
But this also presents the idea here that sometimes there are things that you have in your skills or rules that actually should become hooks. And this is the framework I wanna guide you through here as well to help you identify when should we be creating hooks.
Because I don't want you to just understand them. I want you to know how you should really be building them into your own workflow as well. So really the big idea here is that we want to extract the larger process away from the agent as much as we can.
So instead of having to put in our rules when this thing happens then you do this, we're going to turn that into a hook so we can make sure it happens without relying on the agent to remember the right order of operations. And really what I'm telling you here is super in line with, I'm sure, a lot of studies you've seen come out like Anthropic reducing the size of their system prompt for Claude code by 80%.
Just a lot of studies like this one here that show that too many rules for an agent can actually become detrimental. If you're just splitting its focus between so many processes and conventions. Now, please, don't get me wrong.
I'm not saying rules are bad. They're still really important. It's just it's way too easy to take rules too far.
There's a lot of studies that show that. Like this study right here, super fascinating. I'll link to it in the description.
It's a bit more technical, I'll cover the high level here. They essentially built their own harness that allows their coding agent to evolve their own AI layer over time. So editing its own rules and hooks to try to perform better on the same tasks later.
And then they have a separate evaluator judge, like, did these changes to the AI layer actually lead to better performance across different difficulties of tasks? And so this is the control right here, how well it did without any self evolution. And then at the bottom, this is when it was allowed to make changes to its own rules because system prompt is basically the global rules for your agent.
And we can see the numbers decreased. It actually got worse, which proves that if we just keep appending on two rules, is what coding agents will do when you let them evolve their own rules, we are just diverting attention. Even if the individual rules we add might help in isolation for certain types of tasks, If we're just bloating our rules, we're making things worse.
And then for hooks on the other hand, which they call middleware, adding them in was helpful. For every single task type except for hard tasks, just changing the hooks was able to increase performance.
And really the only reason it's a bit worse for the hard tasks is because you do have to evolve the full AI layer together to really get the best results like they show with the bottom row here. But the main point that I'm making is just tacking on more rules is going to hurt you. That's why we have to be careful about what we build into rules.
And if we want to make our rules more lean, we have to think about what other parts of the AI layer are we going to bring those things into. If we're taking process out of the rules, where does it belong?
And it belongs in hooks. And so with that, the star of the show here is I'm just gonna go through a bunch of really practical examples of hooks that I'm using every single day to build guarantees into my workflows. And so as we go through this, you'll understand more how hooks work just going through the examples, and then we'll cover the audit, figuring out which rules should become hooks because I can guarantee that you already have a good chunk of your rules that's screaming out to you, make me a hook.
And so I'll show you how we can go through that process. You already have a part of your AI layer that you can translate into this. And for all the examples that I cover with you here, I have them all in my skills repository that I'll link to in the description.
And so feel free to use these hooks as a reference or just directly use the ones that I am. And so the other thing that I wanna show you is the hooks create skill. So for every single hook that I show you in this video, I use the process pretty much like this to build it.
So this skill, you just describe what should the hook do, what's the guarantee I want in my workflow, And then it'll go through an interview process to identify everything it needs, then build the entire hook for you and incorporate it into your coding agent like Claude code. So this skill is Claude code specific, but you can just tell it like I'm using codex or pi instead and it will be able to adapt.
And so for every single hook I show you in this video, the way that I created it was pretty much this prompt. Right? Like I use the skill slash hooks create.
And then for example, that testing guarantee example I showed earlier, I just said, when the conversation ends, run the full test suite to make sure everything is green. If it is not, force the agent to fix it.
And obviously, you'll you'll wanna specify like what is my test suite and hopefully you already have that, but then it'd be a part of the interview process. You can start really simple with your prompt and it'll just do the whole thing for you. The sponsor of today's video is MindsHub, specifically their product MindsHub CoWork.
It's an agentic workspace that takes whole tasks off your plate and comes back with finished work. Now, are lot of apps out there that do this, but here's what makes them special.
Different models are better at different things now and the price gap between them is enormous. So what you really wanna do is use the right model at each step of your workflow depending on what you need at each stage for your price, speed, and performance. And that is what Mind's Hub co work specializes in.
Plus their unified inference allows you to use Mind's Hub for inference, access to any model. So within my co work here, I have my planning model for deeper reasoning, my routing model to figure out each turn when I wanna call upon a more expensive one, and my coding model whenever I need to write code for any of my tasks.
And so these are the defaults that we have here, Claude Sonnet five, Kimi k three, and Haiku 4.5. The models don't really matter though. What I really wanna show you just how easy it is for us to mix models and providers within Cowork.
Then going to the chat interface for Cowork, it has all the features you would expect, very feature rich. And so here, I asked it to research the current state of open source AI agent harnesses and it dug deep with all the models and providers that I have set up and then gave me this beautiful dashboard at the end with the summarization of everything that it found.
And yes, I checked all these numbers myself. It got it completely right. And the agent doing all the work in Cowork is Anton, which is MIT licensed right here in GitHub.
So all the routing logic that I'm talking about here is just a file you can open up and read. MindsHub is free to start with 5,000,000 tokens a month across Cowork and their unified inference API if you want the same model freedom for your agents, and you can bring your own API keys. I'll have a link to them in the description.
Cool. So with that, let's go back to the main example I was showing you earlier where we are always going to run tests after implementation and force the agent to iterate if there are any failures. Let's see this in action now and how I set it up.
So over here in a repo where I have this top hook set up, all of your hooks, at least for clog code, are going to be defined in a settings dot JSON file. And the skill I just showed you to build these, it'll help you with all the setup as well. So don't worry too much about the technical details.
I'm just showing you how we're building this into our process. So we have this JSON where we are specifying all of our hooks and we specify the individual events that we have happened in our coding agent where we're going to trigger these different scripts to run. And this really houses all the examples I'm gonna show you.
I'm I'm gonna at least show you a couple of them pretty quickly here. And so here we have our stop hooks. These are the things we're going to run, the actions we're going to run when the coding agent says it is done, right, when it passes control back to us.
And so here I have the stop tests must pass dot py. So I don't need to like show the full script right now, but essentially this just runs the test suite we have for our code base and it's going to return an error if there's anything that is failing. And so for an example here, I have a super simple conversation where I just told it to add one line to the read me.
But you can imagine this would be a full implementation where it touched a ton of files and maybe we still have the agent run tests because that's a part of our skill for implementation, but we wanna make sure that everything is run. And so now we can see the stop hook that fired and we got an error.
It blocked because the tests are not all passing. So this turn is not done. And we can see the output where it ran the test.
It's citing the failures that we encountered in our unit tests and now the agent is continuing. Right? It's forced to pick things back up and address the failures.
Now this is a little bit of a cheesy example because I'm just telling it to add one line, but I wanted a simple conversation just to show you the hook running. This is what it looks like in a conversation no matter the agent you're using, they'll just be logs that say that the hook ran.
So going back to the diagram here, I just wanna quickly help you understand how the hook communicates back to our coding agent. And remember, hooks are cross tool. So really all this applies no matter the coding agent.
And so the script that runs the hook, it can be a bash script, a typescript script, a python script. It's going to run whatever it needs for that deterministic action and then it's going to give an exit code.
And that exit code determines if the coding agent is able to continue or if there's something that is blocked or something that it needs to iterate on. So if we exit zero, we're saying the hook is green.
The check passed for that tool eval or we're allowing the conversation to stop. But if there's an exit too, we are blocking. We're communicating back to the coding agent.
There is a problem that has to be addressed here. Like maybe we're not gonna allow the agent to perform that action. That's an example I'll show you in a little bit.
Or maybe, no, we can't stop the conversation here. There's something that has to be addressed. This is how we communicate failure.
And then if the hook itself, like the code itself broke, then there's a different kind of error code, but usually that's less important. So we're focusing mainly on these two, either it passed or it failed. And depending on what the event is that triggers the hook, the exit code, the failure is going to mean a different thing.
So like for our testing example here, the stop hook failure means that we can't actually end the conversation. Right?
We're blocking the action of stopping the conversation. But then another example I wanna give you here is using the pre tool use. And this is probably the most popular event to apply hooks to because we're able to evaluate an action the agent is about to take before it makes that tool call.
So there are a lot of different things around security that we can implement with the pre tool use event. I love this one so much.
So one really good example is the dot ENV block. You really never want your coding agent to read your environment variables because then you have API keys that are going into the context of your LLM and that's sent to the data servers for whatever coding agent you are using. And so we want to prevent the coding agent from ever reading this file.
And again, you could put it in your rules. Don't read the dot ENV or don't run the remove command or don't edit files in this directory.
But just because it's a rule does not mean the agent is always going to follow it. This is such an important guarantee to build into your workflows stopping your agent from making certain tool calls. And we can see an example of this in action as well.
So I just simply asked it, what is my open router API key in my dot ENV file? And it's kinda scary, but the agent was more than happy to just try to read that file. So if you ask it to explicitly or the agent just gets confused with more context run, it'll do things that it really shouldn't, like read a dot ENV or delete a directory.
But we blocked it. Take a look at this. We have the tool call here where it tried to read from the dot ENV, but we have an error.
Pre tool use. The hook fired and it gave an error. Blocked.
Access to secrets is not allowed. And the other neat thing is the hook actually provides guidance to the coding agent. If there's a dot e n v dot example, we can read that instead because maybe the agent is just trying to figure out what environment variables we have in the project.
And so the agent is able to adapt based on the failure that comes from the hook. So it's not like we just interrupt the conversation and crash the coding agent. It becomes a part of the process where it takes this as feedback to continue.
And the hook is very simple to set up. So going to our settings dot JSON instead of a stop hook, it's a pre tool use. And then we have this one right here, pre tool use secrets.
This is the script that ran to evaluate what the agent was about to do. It detected based on a regular expression that it's trying to access a secret, and then we print the message, which that goes back to the agent.
This is the feedback, and then we have that two exit code I was telling you about in the diagram that forces it to iterate and do something different. And I've only given you a couple of examples here of hooks that I'm using every single day, but there are super useful hooks for every single event in the menu here. Like for example, you could build another stop hook that sends you an alert like a desktop notification or a Slack message whenever the coding agent is done so you know to give it another input.
Or we could use the post tool use or sub agent stop for observability like every time a sub agent is done or we just finished performing an action, we can build up a sort of audit trail. So we can go back with our agent later to identify opportunities to make things more efficient, just evolve our AI layer over time. Start session is another really good example.
Like right when we start a new instance of our coding agent like Claude code, maybe there's specific context you want to inject in. I do this for my second brain where there's like my core memory file that I use a start session hook to bring in as context along with my global rules. A lot of good examples here.
Don't have time to cover all of them, but you can just start to run wild. You can have your imagination run wild here with the different things that you can automate just building guarantees into your workflows.
The the core sort of mental model that I would have here is with hooks, you're either blocking something from happening or you are observing something. So we've seen really good examples of pretool use and stop already.
There's so many good uses for security with hooks. I mean, have no excuse for not using hooks. They're useful in any AI coding workflow.
And we focus less on observability here because it's a bit more specific to your process and your code bases, but especially using the post tool use just to log all the actions your agent is making. So the rule of thumb is any kind of pre hook is a gate because it's before the coding agent takes that action like ending a conversation or invoking a tool.
And anything post is more for logging like the post tool use. And by the way, the hooks create skill that I showed you earlier that helps you create hooks. It knows all these best practices.
So kind of walk you through like based on what you ought to want to automate, here is the different events that I think you should consider for this in the menu. So at this point, going through examples, you probably already have some ideas for hooks you want to build for yourself, but I wanna make this even easier for you.
The most important part of this video is the rule auditing. How do you, along with the ideas you already have, get even more ideas by going through your rules and figuring out what things should you extract and turn into guarantees with hooks. Now luckily, this framework is actually quite simple.
So I would encourage you to go through this on your own global rules today. It's gonna help you so incredibly much. Basically, you do is you go through each section or line of your rules and you ask yourself, is this naming an event or is it encoding judgment?
And what I mean by that, let's take a look at a couple examples here. So like this one, money is integer sense never floats. Well, this really isn't a process at all.
We are encoding judgment. This is a constraint slash convention we have for our agent. This definitely belongs as a rule.
But now the next line, after implementing, run the tests. When we do this, then we need to do this. That is definitely a process and this is the example we cover first that should definitely be a stop hook so we avoid the problem we talked about up here.
And now here's another example. Never read the dot ENV file. This is our pre tool use hook example.
Now it might not necessarily read as a process. This might be a little bit of a stretch, but you could think about it like, you know, when you're about to read a file, make sure it's not a dot ENV. And then this example is probably even better.
Right? It's like when the session starts, read the decision dot m d. This should be a start session hook because the agent might get lost in the sauce of all your rules and not actually read this file when the conversation begins.
And so all of these, we are naming events that need to take place. When this happens, then we do this. Let's extract the process out because it's not judgment that we're encoding.
Definitely, most of our rules will probably stay as rules, but also if it's neither, if it's not judgment, if it's not naming an event, then just delete it. Right?
Like, write clean code. The agent already knows this. We're not really encoding new judgment here, so we can also prune our rules.
That's a whole another video I can make. But, yeah, right now, focus on is it a process or not. So to make this even more concrete for you to end things off here, even give you more examples, I have a global rule file that I purposely built in some processes that really should be hooks and these are things that I've turned into hooks for myself.
And so for example, at the start of every session, run git status and read the decisions dot m d. That should be a start session hook. Before you edit anything in routes, read rag slash citations dot py first.
This should be a pre tool use hook. And this is also an interesting example. I found this very useful where sometimes you know that there's important context in one part of the code base when the agent is operating on a specific file.
So you can guarantee with Hooks that it has looked at those things first so it really has all the information it needs to go ahead with those edits. And I'll show you an example of this actually. Like I said, like, you know, in this file here, I want you to add one, uh, sentence to the system prompt.
The pretool use hook failed. It says blocked. This file is coupled to files you've not read in this session.
You'll see Clog code do this by itself sometimes where it'll try to edit a file and then it'll get an update failure because it hasn't read the file yet. But this hook takes it even further to say like if these things are coupled, just make sure you read everything. Because a lot of times agents will try to perform certain actions without enough context.
So just another good random example there. This is our classic pre tool use like never read the dot ENV. That should definitely be a hook.
Never run a recursive force delete. That should be another security guard as a pre tool use. Log every command you run.
That should be post tool use. When you finish implementing, run the full test suite. Again, that is our stop hook.
So I'm repeating a couple of them here but just showing you how like without really understanding everything I'm covering in this video, this might actually seem like a good fit for your rules. Like, yeah, you want your tests to always be run.
Yeah. You don't want it to read from the dot ENV. But these just aren't guarantees.
And the fantastic thing here is that anything you identify in your rules as more of a process, you can pretty much just copy that section or line and feed it to the hooks create skill that I have linked in the description. So slash hooks create, just paste it in.
Right? Like I took it, I paste it in right here before you edit anything here, read this file, that's the file coupling example. And if I scroll down, it built it.
Right? It decided this is going to be a pre tool use. It figured out the parameters.
It built the hook. It wired it into the settings dot JSON. It did everything for me just based on the rule that I gave it.
It figured out the type of hook, the configuration, the script, and everything. Just please keep in mind as you're doing this process, hooks don't replace your rules. They complement each other.
They're very, important. It's just there are certain processes or events named in your rules that you can turn into hooks.
So I hope that really helps you identify the kinds of guarantees you can build into your workflows and just how hooks work in general. And so if you found this video useful and you're looking forward to more things on AI coding and different parts of the AI layer, I'd really appreciate a like and a subscribe.
And with that, I will see you in the next video.
The Hook
The bait, then the rug-pull.
Cole Medin has audited the AI coding setups of hundreds of developers and companies, and almost none of them use hooks enough. His claim: everything else you build into a coding agent, rules, skills, sub agents, is guidance the model can ignore, but a hook is a deterministic guarantee, and most rules files are full of instructions that should have been hooks all along.
Frameworks
Named ideas worth stealing.
18:09concept
The rule audit: event or judgment?
Does this line name an event?
If yes → convert to a hook
Does it encode judgment/convention instead?
If yes → keep it as a rule
If it's neither → delete it
A one-question test applied to every line of a rules file to decide whether it should become a deterministic hook, stay as guidance, or be cut entirely.
Steal forauditing any CLAUDE.md, AGENTS.md, or system-prompt file that's grown too long
13:28concept
The exit code is the API
exit 0 → allow / pass
exit 2 → block, message returned to the agent as feedback
any other code → non-blocking script error
The contract every hook script follows: its exit code is how it communicates allow/block/error back to the coding agent.
Steal forwriting any new hook script for Claude Code, Codex, or Cursor
Pre-event hooks can gate an action before it happens; post-event hooks fire after the fact and can only log, not block.
Steal fordeciding which event to attach a new hook to
00:39list
The five core components of an AI coding harness
Rules
Sub agents
MCP servers
Skills
Hooks
Rules and skills are guidance, sub agents delegate work, MCP servers connect to platforms, and hooks are the one component that's a deterministic guarantee.
Steal forstructuring any custom coding-agent harness
CTA Breakdown
How they asked for the click.
VERBAL ASK
22:50subscribe
“if you found this video useful and you're looking forward to more things on AI coding... I'd really appreciate a like and a subscribe”
single soft ask right at the very end, after the content is fully delivered, no repeated or aggressive pitching; the earlier sponsor segment for MindsHub Cowork (8:18-9:58) is the video's only other pitch
Add Modern Creator as a preferred source and Google shows you more of our breakdowns in Search, Top Stories, and AI Overviews. It only changes what you see, and you can undo it in your Google settings anytime.
Add to Preferred SourcesOpens your Google source preferences with us pre-loaded. Tick the box and you're done.
A software engineer who hasn't handwritten a line of code in over a year opens up the actual skill library and two-loop system that runs his AI-assisted development process end to end.
Boris Cherny told a Y Combinator crowd to delete your AI layer every six months. Cole Medin ran the actual benchmark to find out which parts of that advice hold up and which don't.
A 25-minute honest breakdown of loop engineering — what the AI coding elite actually mean by it, why it gets expensive fast, and how to build a harness that makes it reliable.
A change-log walkthrough of five new AI-coding skills, built around one idea: let the agent handle judgment, but keep humans in charge of anything you can't undo.
00:26
01:00
01:18
01:35
01:52
02:27
02:44
03:02
03:19
03:36
03:54
04:11
04:46
05:03
05:20
05:38
05:55
06:12
06:23
06:47
07:04
07:39
07:56
08:31
08:48
09:06
09:23
09:40
10:15
10:32
10:50
11:07
11:24
11:42
12:16
12:34
12:51
13:08
13:26
14:00
14:18
14:35
14:52
15:10
15:27
15:44
16:19
16:36
16:54
17:11
17:28
17:46
18:20
18:38
19:12
19:30
19:47
20:04
20:22
20:39
20:56
21:14
21:48
22:06
22:23
22:58
23:00
Video of the Day20:00
21:55
24:39
11:37
15:09