{"slug": "claude-code-hooks-vs-skills-when-to-use-which", "title": "Claude Code Hooks vs Skills: When to Use Which", "summary": "Claude Code's Hooks and Skills, both released in 2026, serve fundamentally different purposes: Hooks run shell commands deterministically on lifecycle events like pre-commit or post-tool-use, while Skills are markdown bundles Claude loads probabilistically when it judges them relevant to a user request. Hooks are best for guardrails, telemetry, and blocking unsafe actions, whereas Skills suit reusable procedures and multi-step workflows. The wrong choice between the two can waste context, break reliability, or both.", "body_md": "*Originally published on rikuq.com. Republished here for Dev.to's readers.*\n\nClaude Code shipped Hooks and Skills near each other in 2026, and they get conflated. They solve different problems and the wrong choice burns context, breaks reliability, or both.\n\nThe 30-second answer: **Hooks run on lifecycle events whether you want them to or not. Skills run when Claude decides they're relevant.** That single distinction tells you which one to pick almost every time.\n\n| Hooks | Skills | |\n|---|---|---|\nWhat |\nShell commands the harness runs on lifecycle events | Markdown bundles Claude loads on demand |\nTrigger |\nFixed event points (`pre-commit` , `post-tool-use` , `prompt-submit` , `session-stop` , ...) |\nClaude matches a user request to a skill's description |\nDeterminism |\nDeterministic — runs every time the event fires | Probabilistic — runs when Claude judges it relevant |\nBest for |\nGuardrails, telemetry, auto-format, blocking unsafe actions | Reusable procedures, multi-step workflows, codified expertise |\nFailure mode |\nCan block the action that fired it | Claude might forget to invoke it |\nLives in |\n`settings.json` (project-local or user-global) |\nA directory with a `SKILL.md` , registered via a plugin manifest |\nCosts |\nNegligible — runs out-of-band | Eats some context per session for the skill descriptions |\n\nA Hook is a shell command registered against a lifecycle event in `settings.json`\n\n. When the event fires, the harness runs your command with relevant context as environment variables. Your command does its thing and exits — exit 0 means continue, non-zero means stop.\n\nThe event surface in 2026 (the ones I actually use):\n\n`prompt-submit`\n\n— fires when you hit enter on a prompt`pre-tool-use`\n\n/ `post-tool-use`\n\n— fires around every tool invocation`pre-commit`\n\n— fires before git commit (when Claude is committing)`session-stop`\n\n— fires when a session endsThat's most of what you need. The full list is in the docs; these five cover 90% of real setups.\n\nCloudflare Pages and a bunch of MTAs reject UTF-8 em dashes in commit messages with cryptic \"invalid commit message\" errors. I lost an afternoon to this exact problem on rikuq. Now it's a one-line hook:\n\n```\n{\n  \"hooks\": {\n    \"pre-commit\": [\n      \"sed -i '' 's/—/--/g; s/–/-/g' $CLAUDE_COMMIT_MSG_FILE\"\n    ]\n  }\n}\n```\n\nRuns every commit. Never costs context. Never fails because Claude \"forgot.\"\n\nFor FinOps tracking on Claude Max, I want a running ledger of which sessions hit which expensive tools (anything that calls an external API or runs a long process). Hook fires after every tool:\n\n```\n{\n  \"hooks\": {\n    \"post-tool-use\": [\n      \"node ~/.claude/hooks/log-tool.mjs\"\n    ]\n  }\n}\n```\n\nThe script appends one JSON line per tool call to `~/.claude/tool-log.jsonl`\n\nwith tool name, duration, exit code. Weekly I `jq`\n\nover it to see where Claude's spending time. This is the kind of telemetry you want collected automatically — making it a skill would mean Claude has to remember to log, which is a worst-of-both-worlds outcome.\n\nA loose Claude session can occasionally try to write to a sibling project's directory by mistake (especially when juggling multiple worktrees). One pre-tool-use hook closes that:\n\n``` bash\n#!/usr/bin/env bash\n# ~/.claude/hooks/no-cross-project.sh\nif [[ \"$CLAUDE_TOOL_NAME\" == \"Write\" || \"$CLAUDE_TOOL_NAME\" == \"Edit\" ]]; then\n  case \"$CLAUDE_TOOL_PATH\" in\n    \"$PWD\"/*) exit 0 ;;\n    *) echo \"blocked: write outside project root ($PWD)\"; exit 1 ;;\n  esac\nfi\n```\n\nExit 1 blocks the write. Claude sees the error and asks me what I want to do. This is the use case Hooks exist for — deterministic enforcement of a constraint that should never bend.\n\nA Skill is a directory containing a `SKILL.md`\n\nmarkdown file plus any optional helper scripts. The markdown opens with a description Claude uses to decide whether the skill is relevant to the current request. When Claude decides yes, it reads the full skill body and follows the instructions.\n\nThe trigger model is the key thing to internalize. Skills don't fire on events. They fire when Claude matches your description to a user message. So the description's specificity matters more than the body — a vague description means Claude won't reliably invoke the skill; an overly specific description means it'll be skipped when it would have been useful.\n\nI have a `content-publish`\n\nskill that lives in a shared npm package (`@ravirdp/content-ops`\n\n). Its description starts: *\"Publish an approved brief end-to-end inside the current project's repo. Reads brief from project's SQLite DB, writes MDX...\"*. When I say \"publish brief 20,\" Claude matches that to the skill and follows its body — which is a 200-line procedure: load config, verify the brief is approved, write the MDX, generate the hero image, commit, push, open PR, merge, run post-publish hooks, update trackers.\n\nIf that were a Hook, there'd be no event for \"the user wants a blog post written.\" Skills are right when the work is procedural but its invocation depends on intent.\n\nA `seo-audit`\n\nskill I use across projects. Description: *\"Run a full SEO audit on a project — GSC ranks, on-page issues, internal-link gaps, GEO citation status. Use when the user asks to audit a site or check why traffic dropped.\"* Body walks through the data pulls and writes a markdown report.\n\nI invoke it once a week per project. A Hook would be wrong — there's no lifecycle event that means \"Friday afternoon, do an SEO audit.\" Skills are right when the cadence is human-driven.\n\nA `deploy-readiness`\n\nskill. Description: *\"Pre-deployment checklist: run tests, scan for hardcoded secrets, verify env vars are set, confirm migrations apply cleanly. Use before deploying to production.\"* When I say \"I'm about to deploy, check we're good,\" Claude invokes it.\n\nCould be a Hook on `pre-tool-use`\n\nfor the deploy command? Maybe. But deploys come from many surfaces (Cloudflare dashboard, `wrangler deploy`\n\n, GitHub Action) and the checklist evolves frequently. A Skill that Claude can update over time beats a brittle Hook trying to intercept every deploy path.\n\n```\nIs the work tied to a specific lifecycle event\n(commit, tool use, session end, etc.)?\n│\n├── Yes ──> Should it run every time, regardless of intent?\n│           │\n│           ├── Yes ──> HOOK\n│           │\n│           └── No  ──> Skill (and trigger via conversation)\n│\n└── No  ──> Should Claude decide when it's relevant?\n            │\n            ├── Yes ──> SKILL\n            │\n            └── No  ──> Neither — just a regular script you run by hand\n```\n\nIf you find yourself answering \"Yes\" to both branches, the work probably wants both: a Hook for the deterministic part (telemetry, guardrails) and a Skill for the procedural part (the actual workflow Claude executes).\n\n**1. The \"Hook that requires intelligence.\"** Trying to use a Hook to do something that needs to look at the surrounding context — like a `pre-commit`\n\nhook that decides whether to bump the version number based on the commit's content. Hooks run shell commands; they don't get Claude's reasoning. If logic is needed, expose the logic as a Skill and let Claude trigger it.\n\n**2. The \"Skill that should fire automatically.\"** Defining a Skill for \"auto-format the file after every edit.\" That's a Hook (on `post-tool-use`\n\nfiltered to `Edit`\n\n). Skills run when Claude decides; you don't want format-on-save to depend on whether Claude noticed.\n\n**3. The \"Skill description that's too vague to match.\"** Writing `description: \"Helps with content\"`\n\n. Claude has no way to know when this is relevant. Descriptions need to be specific about what the skill does AND when to use it. Look at how Anthropic ships their first-party skills — every description has the shape \"do X. Use when the user asks Y.\"\n\nThe shape of my project-local `settings.json`\n\nfor rikuq, with the hooks removed for brevity:\n\n```\n{\n  \"hooks\": {\n    \"pre-commit\": [\"sed -i '' 's/—/--/g; s/–/-/g' $CLAUDE_COMMIT_MSG_FILE\"],\n    \"post-tool-use\": [\"node ~/.claude/hooks/log-tool.mjs\"],\n    \"pre-tool-use\": [\"bash ~/.claude/hooks/no-cross-project.sh\"]\n  }\n}\n```\n\nThree hooks. All deterministic, all about guardrails or telemetry.\n\nFor skills, I install one plugin globally — `@ravirdp/content-ops`\n\n— which provides:\n\n`content-research`\n\n— surface keyword opportunities, write briefs as pending`content-publish`\n\n— ship an approved brief end-to-endPlus a `seo-audit`\n\nand a `deploy-readiness`\n\nskill I maintain in a personal plugin.\n\nThat's it. Five hooks, four skills. The temptation is to add more — every new piece of Claude friction looks like a hook or skill opportunity. Most of the time, it isn't. Most friction is solved by writing a better prompt or adding a sentence to the project's `CLAUDE.md`\n\n. Hooks and skills are reserved for the small set of things that genuinely need to be codified.\n\nIf you're standing up a Claude Code setup from scratch in 2026, my unbiased starting recommendations are in [Claude Code Review 2026 — From Zero Code to 3 Live SaaS](https://rikuq.com/blog/tools/claude-code-review). If you're comparing Claude Code against Cursor, the right framing is in [Cursor vs Claude Code 2026](https://rikuq.com/blog/tools/cursor-vs-claude-code). And if you want to see what a real production stack looks like behind one of these solo-founder operations, [How I Run 3 Production AI SaaS on $5/Month of Hosting](https://rikuq.com/blog/stack/production-stack-2026) is the operational counterpart to this post.\n\nThe pattern across all of them is the same: pick the simplest abstraction that does the job. Hooks for the deterministic things. Skills for the procedural things. Everything else is a prompt.", "url": "https://wpnews.pro/news/claude-code-hooks-vs-skills-when-to-use-which", "canonical_source": "https://dev.to/rikuq/claude-code-hooks-vs-skills-when-to-use-which-ple", "published_at": "2026-05-27 07:34:49+00:00", "updated_at": "2026-05-27 07:53:09.298808+00:00", "lang": "en", "topics": ["ai-tools", "ai-agents", "large-language-models", "artificial-intelligence", "generative-ai"], "entities": ["Claude Code", "Dev.to", "rikuq.com"], "alternates": {"html": "https://wpnews.pro/news/claude-code-hooks-vs-skills-when-to-use-which", "markdown": "https://wpnews.pro/news/claude-code-hooks-vs-skills-when-to-use-which.md", "text": "https://wpnews.pro/news/claude-code-hooks-vs-skills-when-to-use-which.txt", "jsonld": "https://wpnews.pro/news/claude-code-hooks-vs-skills-when-to-use-which.jsonld"}}