Claude Code Basics Lesson 44 of 46

When You Actually Need One (and When It's Too Much)

Silvio Luchetti

In short

Three questions in a row: does it need judgment? is it a prohibition? does it have to happen every time?
Judgment → instructions or a skill. Prohibition → permission. Must happen → hook.
If a permission is enough, use the permission: it's one line and needs no upkeep.
It's completely fine to never write one: knowing they exist is enough.

The rule of thumb, in three questions

You have something you want to achieve. Ask yourself these three questions, in this order:

1. Does it need judgment? If it depends on an assessment — "when the tone is too formal," "if the document looks incomplete" — then it's not an automation. It's instructions, or a skill. A trigger that fires automatically doesn't know what "too formal" means.
2. Is it a prohibition? If what you want is for something to not happen, it's a permission. One line, no maintenance.
3. Does it have to happen every time, at a precise point? If yes, and there's nothing to judge, it's a hook.

The rule of thumb that untangles it: instructions for nuance, permissions for prohibitions, hooks for automations.

The overlap that causes confusion

You've probably noticed that a hook attached to "before a tool" can block, and so it can do a permission's job. True. And it's almost always the wrong choice.

A deny rule is declarative: you write down what can't be touched and you're done. A hook is something that runs: it has to be written, it has to be tested, and the day it stops working you won't notice until it matters.

If a permission is enough, use the permission. The hook is for when the condition is smarter than "this specific path" — when it depends on the moment, on a check that needs to run, on something that has to be looked at before deciding.

It's completely fine to never write one

Let's close the chapter with some honesty. Hooks are the most advanced thing in the whole course, and many people who finish it will never write a single one. That's fine.

Knowing they exist is still useful for three things:

Recognizing them when you find them in someone else's configuration, instead of treating them like black magic.
Knowing that problem has a solution, the day you notice "almost always" isn't good enough anymore.
Understanding the boundary: you now know there's a line between what's requested and what's guaranteed — and that distinction will be useful outside Claude Code too.

What's next

The map is complete. All four buckets, the engine, the install, and now level 2 of the first bucket too.

Only one thing remains, and it's the thing that turns all of this into a skill of your own instead of a course you watched: doing something with it. In the next lesson, the final project.

Did you get it?

Two minutes, no grade. Trying to answer — even getting it wrong — cements the concepts far more than rereading. Not in the mood? Skip it: the lesson still counts as complete.

"This folder never gets touched." What do you use?

"After every change to the documents, make a copy in the archive." What do you use?

"When the text is too formal, soften it." What do you use?

1
1. 1
2. 2
3. 3
2
1. 4
2. 5
3. 6
4. 7
3
1. 8
2. 9
3. 10
4. 11
5. 12
4
1. 13
2. 14
3. 15
4. 16
5. 17
6. 18
5
1. 19
2. 20
3. 21
4. 22
5. 23
6. 24
6
1. 25
2. 26
3. 27
4. 28
5. 29
6. 30
7
1. 31
2. 32
3. 33
4. 34
8
1. 35
2. 36
3. 37
4. 38
9
1. 39
2. 40
3. 41
10
1. 42
2. 43
3. 44
11
1. 45
2. 46