Claude Code Hooks vs Slash Commands vs Skills (2026): Which Surface Should Own Your Workflow?

Claude Code hooks, slash commands, and skills are easiest to separate by asking who starts the action. Use a slash command when the human should explicitly start a session control or workflow. Use a skill when Claude needs reusable method, reference material, or a checklist it can load when relevant. Use a hook when a lifecycle event must run a script, request, prompt, or agent every time.

The current Claude Code docs make one boundary especially important: custom commands have been folded into skills, while existing .claude/commands/ files still work. That means the practical question is no longer "which old customization folder should I use?" It is "who should trigger this work, how deterministic does it need to be, and what should happen if the model forgets?"

The Fast Route Board

This table is the part to remember. Slash commands are about timing. Skills are about method. Hooks are about certainty. A slash command gives the human a clear button-like moment. A skill gives Claude a reusable package of instructions and files. A hook gives the runtime an event-bound rule that does not depend on Claude deciding to remember it.

The first mistake is treating all three as automation. They can all reduce repeated typing, but they do not carry the same risk. A command can be forgotten. A skill can be loaded too broadly or too narrowly. A hook can fire too often and block the wrong thing. Good Claude Code customization starts by naming that failure mode before you create another file.

As of June 1, 2026, use the official commands reference, skills docs, hooks guide, and hooks reference for behavior. Command availability and bundled skills can vary by platform, plan, and environment, so do not treat any third-party command list as a complete inventory.

Slash Commands Are For Explicit Timing

A slash command is the right surface when the important part is that a human chooses the moment. You type / at the start of a message, choose a command, and optionally pass arguments after it. That makes commands good for session control, deliberate workflow starts, and actions where the person supervising Claude should be visible in the loop.

Use a slash command or user-invoked skill when the workflow sounds like:

• "Run this review now."
• "Summarize the current state before I switch tasks."
• "Start the release checklist with these arguments."
• "Explain this selected code path."
• "Create a plan, but do not execute yet."

The strongest reason to stay command-shaped is side effect control. If a workflow could deploy, delete, bill, publish, rewrite many files, contact an external service, or change a branch state, human timing is not a minor UX preference. It is part of the safety model. A skill can still carry the method behind that workflow, but invocation should stay explicit unless the action is truly low-risk.

That is why the current custom-command merge into skills should not be read as "commands disappeared." The visible / invocation surface still matters. The change is that skills are now the richer packaging path for many custom workflows. They can carry metadata, supporting files, dynamic context, tool controls, and lifecycle hooks in a way a simple old command file did not.

The clean pattern is:

1. Keep built-in session commands for session control.
2. Use a user-invoked skill when the command should launch a reusable workflow.
3. Keep legacy .claude/commands/*.md only when it already works and does not need the richer skill contract.

If you are tempted to create a command with no clear human timing requirement, pause. It may be a skill that Claude should load when the work appears, or a hook that should run at an event boundary.

Skills Carry Reusable Method

A skill is the right surface when Claude needs a reusable way to work. The useful unit is not "a prompt I like." It is a method with enough structure to be worth packaging: instructions, references, examples, scripts, templates, and boundaries that should load together.

Anthropic's current skills docs describe SKILL.md as the required entrypoint, with optional supporting material around it. That shape matters because a good skill can keep repeated workflow knowledge out of always-on project instructions while still making it available when the task calls for it.

Use a skill when the workflow sounds like:

• "Review pull requests with this evidence checklist."
• "Run this migration audit the same way every time."
• "Create API docs from code with these examples and format rules."
• "Localize articles with a strict source-truth pack."
• "Test a web app with our browser QA rubric."

The test is whether the method would be annoying or risky to re-explain in every session. If the answer is yes, a skill can be a real upgrade. If the answer is no, leave it as a prompt, a doc, or a short note until it repeats enough to deserve a package.

Skills also let you control how they are invoked. Some skills should be available for Claude to load when relevant. Others should be direct only. If a skill has side effects, costs money, contacts another system, or changes production state, make it user-invoked and keep the human timing visible. That is where a command-like skill gives you the best of both surfaces: a reusable method behind an explicit /skill-name.

If your next question is which skills to install first, use the Best Claude Code Skills guide. The route decision here is narrower: decide when a skill is the right kind of surface at all.

Hooks Enforce Runtime Events

A hook is the right surface when the event should trigger the action regardless of whether Claude remembers it. Hooks are for lifecycle automation: before or after tool use, at session boundaries, around notifications, during compaction, or around other configured events. The handler can be a command, HTTP request, prompt, or agent, depending on the hook type and current docs.

Use a hook when the workflow sounds like:

• "After file edits, run a formatter or capture a short log."
• "Before a risky tool call, block a narrow class of known-bad commands."
• "When the session starts, inject a small piece of current context."
• "When Claude needs attention, send a notification."
• "When work stops, write a compact session record."

The word narrow is doing real work here. A hook is a poor place for broad judgment. If the question is "is this code review good enough?" that belongs in a skill, subagent, or explicit review workflow. If the question is "did this command try to delete a protected path?" that can be a hook. Hooks are strong when the rule can be checked deterministically, observed consistently, and explained in a short failure message.

Hooks also need more care than skills because they fire automatically. A bad skill may waste context or steer a task badly. A bad hook can interrupt every session, add latency, create noisy logs, or block valid work. Start with observing and logging before blocking. Once the signal is stable, make the hook stricter.

Use /hooks or the current configuration/debugging routes to inspect what is active. If the problem is that Claude keeps forgetting a workflow, do not jump straight to a hook. First decide whether the workflow is method, memory, access, or event enforcement.

Combine Surfaces Only When Each Layer Has A Job

The strongest setups often combine these surfaces, but only when each layer has a different job. A combined setup is not better because it is more advanced. It is better when it removes ambiguity.

Here are three safe patterns.

The bad version is vague layering: a command that repeats a skill, a skill that tries to enforce policy, and a hook that asks Claude to make subtle judgment. The good version is explicit layering:

• The command chooses the moment.
• The skill teaches the method.
• The hook enforces a narrow invariant.

If you cannot name the job of each layer in one sentence, remove a layer. Simpler setups are easier to debug, safer to share with a team, and less likely to create hidden behavior that surprises the next person working in the repo.

Stop Rules For Overbuilt Claude Code Setups

Use these stop rules before adding another file under .claude/ or another hook entry in settings.

Do not put nuanced judgment in hooks. Hooks are best at deterministic checks, not broad review taste. A hook can block a command pattern or validate a path. A skill or subagent should handle judgment-heavy review.

Do not auto-trigger destructive skills. If a workflow can publish, deploy, delete, spend money, or touch production, keep a human invocation step. Package the method in a skill if needed, but make the start explicit.

Do not turn one-off prompts into skills. A skill earns its place when a workflow repeats and benefits from references, examples, scripts, or templates. A single favorite prompt is not a skill yet.

Do not use a command list as a strategy. Knowing many slash commands is less useful than knowing which surface owns which job. Use the official commands reference when you need inventory. Use a route board when you need design judgment.

Do not use hooks as memory. If Claude needs a rule visible before work starts, put it in the right memory or project instruction surface. Hooks run at events; they should not become a hidden policy document.

Do not use skills when the missing piece is access. A skill can teach Claude how to work with GitHub, a browser, a database, or a deployment system. It cannot magically expose those systems. If external access is missing, the next layer is usually MCP. The broader layer choice is covered in Claude Code Memory vs MCP vs Skills, and concrete server selection belongs in the Best Claude Code MCP Servers guide.

Do not use hooks or skills to solve unattended runtime ownership. If the real question is whether recurring work should run in the cloud, on your machine, inside an open session, or in CI, read the Claude Code Routines guide. Hooks and skills can support an automated workflow, but they do not decide where the workflow should live.

A Small Design Checklist

Before you build anything, answer these questions in order:

1. Who should trigger the work: human, Claude, or runtime event?
2. Is the work a one-off action or a reusable method?
3. Does the behavior need to run automatically or only on demand?
4. Can the rule be checked deterministically?
5. Could the action cause side effects, costs, or production changes?
6. Does Claude need external data or action access?
7. Will teammates understand why this layer exists?

If the answer points to explicit timing, start with a slash command or user-invoked skill. If it points to method, write a skill. If it points to deterministic event handling, configure a hook. If it points to external access, use MCP. If it points to unattended runtime, choose the runtime owner before adding extension files.

That order prevents most Claude Code customization sprawl. It also makes your setup easier to explain: "This command starts the workflow, this skill carries the method, and this hook enforces one invariant." That is the standard to aim for.

FAQ

Are slash commands and skills now the same thing?

Not exactly. The current docs say custom commands have been folded into skills, and a skill can be invoked through /skill-name. But slash commands are still the visible session invocation surface. Treat commands as timing and invocation; treat skills as reusable workflow packaging.

Should I migrate every .claude/commands/ file to a skill?

No. Existing command files can still work. Migrate when the workflow needs richer packaging, supporting files, metadata, tool controls, dynamic context, or better discoverability. If a simple command still does one small job clearly, it does not need a migration just for aesthetics.

Are hooks more reliable than skills?

They are more deterministic, not universally better. A hook fires when its configured event happens. That is useful for formatters, logs, notifications, and narrow guards. It is not a good replacement for workflow judgment. Skills are better when Claude needs method, context, examples, or a checklist.

Can a skill call tools or use hooks?

Skills can define workflow context and controls, and current docs describe advanced options around tool access and lifecycle behavior. The important design rule is still separation of concerns: use the skill for method, and use hooks only for the event-bound part that should run automatically.

What should I inspect before adding another surface?

Start with /help or the commands reference for command availability, /skills for available skills, /hooks or config debugging for hooks, and /context when you suspect instructions are already loaded. If you cannot name the missing layer after those checks, do not add another layer yet.

Where should project-wide rules go?

Put broad always-on project rules in CLAUDE.md or the appropriate memory surface, not in a hook or a skill. Put detailed repeatable procedures in skills. Put event enforcement in hooks. If this boundary is the real problem, the broader memory vs MCP vs skills guide is the better next read.

The Short Version

Choose the surface by trigger owner. Slash commands are for explicit human timing. Skills are for reusable method. Hooks are for deterministic lifecycle events. Combine them only when the command, skill, and hook each have a distinct job.

That one rule keeps Claude Code customization practical. It lets you start workflows intentionally, package repeated methods cleanly, and enforce narrow invariants without turning your .claude/ setup into a pile of overlapping automation.