Can a hook do what a skill does?

No. A hook runs a shell command — it can't change how Claude thinks or writes. A skill shapes Claude's behaviour and knowledge. They're complementary, not interchangeable.

Should I use a hook or a skill to enforce code style?

Both, for different aspects. A skill tells Claude 'write code in this style' (shaping what it produces). A hook runs your formatter after every edit (enforcing the mechanical rules). The skill prevents style issues; the hook catches anything that slips through.

Can hooks block Claude from doing something?

Yes. A `PreToolUse` hook can reject an action before it happens — like blocking any edit to the `main` branch. That's guardrail territory, not knowledge territory, which is exactly what hooks are for.

Hook vs Skill in Claude Code — Claude for Humans

Both hooks and skills fire automatically — you don’t invoke either one. But they do fundamentally different things, and using the wrong one leads to a brittle or ineffective setup.

The one-line version

A hook runs a shell command when a specific event happens (before an edit, after a save, on session start).
A skill gives Claude knowledge about how to do something — it shapes thinking, not actions.

Hook — the automatic action

A hook is a command that fires at a specific moment:

After every edit, run `prettier --write` on the changed file.

It’s mechanical. It doesn’t change what Claude thinks — it runs a command at a trigger point. Hooks are for enforcement, formatting, logging, and guardrails.

Use a hook when:

You want something to happen at a specific moment (format, lint, log, block)
The action is a shell command, not knowledge
You’d automate this even without AI

Skill — the automatic knowledge

A skill is a SKILL.md file that teaches Claude how to do something:

.claude/skills/api-design/SKILL.md
→ "When designing API endpoints, always use plural nouns, return consistent error shapes..."

It doesn’t run a command. It shapes how Claude approaches work when the topic is relevant. Skills are for conventions, processes, and expertise.

Use a skill when:

You want to change how Claude thinks about something
The instruction is knowledge or a convention, not a shell command
You’d explain this to a new team member, not script it

Side by side

	Hook	Skill
What it is	A shell command on a trigger	A knowledge file Claude reads
When it fires	At a system event (pre/post edit, session start)	When Claude sees the topic is relevant
What it does	Runs a command	Shapes Claude’s thinking
Good for	Formatting, linting, logging, blocking	Conventions, processes, expertise
Analogy	A tripwire	A training manual
Can it block an action?	Yes (`PreToolUse`)	No — it guides, not guards

How they work together

The best setups use both:

Skill: “When writing CSS, use logical properties and our design tokens” (shapes what Claude writes)
Hook: “After every edit to a .css file, run stylelint --fix” (catches anything mechanical)

The skill prevents mistakes by shaping intent. The hook catches anything that slips through by running enforcement. Together, they’re a two-layer safety net: knowledge first, automation second.

The rule of thumb

If it’s a command a script could run → hook. If it’s knowledge a human would explain → skill.