Claude Skills vs Hooks: Instructions or Enforced Steps?

Claude skills and Claude Code hooks both shape how an AI assistant works, but they do it differently. A skill is a saved instruction you call when you need it. A hook is a script that runs automatically when a specific event occurs. Choosing the wrong one gives you a control that looks like it works until the moment it matters most.

Tools like fenbs record the approved procedures and the reasons for each control decision. When the next person asks why a step is a hook rather than a skill, the record gives them the reasoning rather than leaving them to guess.

What Claude skills are

A Claude skill is a saved prompt instruction in a Claude Project. You write it once, give it a name, and call it when you need that output. "Draft a pull request description", "Review this for brand voice", "Break this task into steps" are all candidates for a skill. You decide when to use it.

Skills are deliberate. They rely on a person (or an assistant following instructions) to call them at the right moment. A well-designed workflow includes the call in its steps: "When the draft is ready, call the Brand review skill before sharing." That is effective when the workflow is followed, and ineffective when it is not.

The Claude skills examples page has ready-made skill templates across common use cases. See how to create a Claude skill for the full setup process.

What Claude Code hooks are

A Claude Code hook is a shell script that runs automatically when a defined event occurs in Claude Code. Events include things like before Claude runs a command, after it writes a file, or before a session ends. The hook runs regardless of whether anyone intended it to.

Hooks enforce steps. A hook that runs a linter before every file write enforces that linting happens. A hook that logs every command Claude runs enforces that logging happens. The person who configured the hook may forget it exists. It still runs.

Hooks require Claude Code and are configured in the workspace, not in a Claude Project. They are separate from skills, and the two can work together: a hook might call a script that sends a notification, while the quality review of what Claude produced is a skill you call afterward. See Claude Code hooks examples for working patterns.

When to use a skill

Use a skill when the task is valuable but not mandatory, when the person doing the work is the right one to decide when it applies, or when the instruction is complex enough that typing it every time is the real cost.

• Drafting, reviewing, or reformatting content on demand
• Breaking a task into steps before starting a new piece of work
• Running a quality check before sharing something externally
• Applying a domain-specific procedure that requires judgment about when it fits
• Recurring tasks where the person initiates and reviews the output

Skills are also the right choice when the instruction needs to vary slightly by context. You can pass different inputs to the same skill: the same "Review for brand voice" skill works for a blog post and a UI label, even though the review will surface different issues.

When to use a hook

Use a hook when the step must happen every time without exception, when skipping it even once creates a real risk, or when you cannot rely on a person remembering to call the relevant skill.

• Running security or lint checks before every commit
• Logging every command Claude runs in a sensitive environment
• Blocking file writes to specific directories
• Sending a notification every time a particular event fires
• Enforcing a workflow step that has caused problems when skipped in the past

A hook is the right choice when you would write "always do X before Y" as a rule, not a suggestion. If missing the step once is acceptable, a skill is probably enough. If missing it once is a compliance issue, a security risk, or a costly mistake, a hook enforces it.

When to use both

Skills and hooks complement each other. A hook can enforce the mandatory steps, and a skill can handle the judgment-based ones that follow. Say a team uses Claude Code to generate API documentation. A hook ensures the output is always saved to a specific directory. A skill reviews the documentation for clarity and completeness. The hook is not optional; the skill is called when the review is needed.

The combination is also useful for auditing. The hook logs what Claude did; the skill produces the human-readable summary of what happened. Neither does the other's job, and neither can substitute for the other. Together they cover the full range of controls, from optional quality improvements to steps that must run every time without exception.

Common mistakes when choosing between skills and hooks

The most common mistake is using a skill for a step that should be a hook. A team adds a security review skill and includes it in workflow documentation. Then someone is in a hurry, skips the skill call, and ships a manifest without the review. The skill was optional. A hook would have enforced the review regardless of whether anyone remembered to call it.

The opposite mistake also happens: using a hook for something that should be a skill. A hook that runs a detailed documentation review before every file write fires on every change, including trivial ones. The friction causes engineers to look for ways around it. A skill called deliberately when a documentation review is actually needed produces better results with less resistance.

A third mistake is treating the choice as permanent. A skill can become a hook when the team decides a step must be enforced. A hook can be removed if its friction outweighs its value. Document both decisions in fenbs: why the step was added as a skill or hook, and what would cause the team to change that. Without that record, the next person who questions the setup has no basis to evaluate it.

Recording the reasons for each control

Skills and hooks accumulate over time. A team that adds one per month ends up with a set of controls whose original reasons are buried in chat history or forgotten entirely. Recording each control decision when it is made prevents the question "why does this hook exist" from becoming unanswerable.

The most important decision to record is why a step was made a hook rather than a skill, or vice versa. That reasoning survives even when the person who made it moves on. It also prevents a future review from quietly downgrading a mandatory step to an optional one without knowing what the original risk was.

How to do this with fenbs

1. Create a free account and add a project for the team or product whose controls you are documenting.
2. Add each recurring skill to Skills and prompts with a clear name and a note on when to use it.
3. For each hook, add a Decisions and rules entry: what it does, the trigger event, and the reason it is mandatory.
4. Connect Claude over MCP from Integrations. At the start of a session, ask Claude to read the project rules so it understands which steps are enforced and which are optional.
5. When a control is added, changed, or removed, record the decision in fenbs with the date and reason.

For skill creation details, see how to create a Claude skill. For hooks patterns and examples, see Claude Code hooks examples. The claude skills marketplace lists skills others have shared.