Tool
Does the work.
"Run git status."
The short version
Skills, hooks, and wrappers are three ways to change what a host does.
One teaches the host useful know-how. One steps in automatically at key moments. One hides a clumsy interface behind a cleaner one. Same neighborhood, different jobs.
If the names blur together at first, fair. I think the cleanest way to separate them is to ask what problem each layer is solving around the host.
A tool can act. A skill can teach. A hook can enforce. A wrapper can adapt.
Skill
Explains how and when to use tools.
"When reviewing a PR, inspect diff, tests, risky files, and CI."
Hook
Runs automatically at a lifecycle point.
"Before commit, scan for secrets."
Wrapper
Changes the interface to something easier to call.
"Expose this CLI as an MCP tool."
In practice
These layers make raw tools usable by agents.
Tools do the action. These layers make the action repeatable, safer, and easier for a host to reach without improvising every time.
Current default
Skill
ELI5: A recipe card that tells the apprentice how to do one kind of job well.
What it actually is: Reusable procedural knowledge: when to start, which tools to use, what order to follow, and how to check the result.
Try it: Read and adapt lab 04.
Real tools: Claude Code or Copilot-style skill files, runbooks, repo instruction files, code-review procedures.
Current default
Hook
ELI5: A motion sensor that turns the light on whenever someone enters the room.
What it actually is: A lifecycle callback that runs automatically before or after key events so policy does not depend on the model remembering every rule.
Try it: Follow lab 05.
Real tools: Git hooks, pre-commit, CI checks, approval hooks in tools like Cursor or Claude Code, secret scanners.
Current default
Being absorbed
Wrapper
ELI5: Put a weird machine behind a cleaner front panel so the next person only has to push one labeled button.
What it actually is: A layer that reshapes an existing tool into a cleaner schema, protocol, or host experience.
Try it: Compare lab 02 and lab 03.
Real tools: JSON CLI wrappers, MCP adapters, LiteLLM gateways (one API over many model providers), host-specific tool shims.
Procedural memory
Skills are procedural memory.
A skill is not just a prompt with better branding. A good one captures a repeatable way of doing the work: when to start, what context to gather, which tools to use, how to validate, and where the usual mistakes happen.
When skills help
Use a skill when the same kind of task comes up repeatedly and the agent benefits from domain-specific instructions.
What skills contain
Instructions, examples, scripts, templates, checklists, tool-routing guidance, and validation criteria.
What skills are not
They are not necessarily executable by themselves. They may call tools, but their main job is to package know-how.
Lifecycle automation
Hooks are lifecycle automation.
Hooks fire before or after something important happens. They are useful when you want consistent behavior without depending on the model to remember every rule.
Security companion: API key security explains why hooks help at the boundary but do not replace a real secret split.
Concrete example: when Cursor or Claude Code asks you to approve a shell command or file write, that approval gate is the hook pattern at work at the host boundary. The model did not suddenly become safer; the product wrapped the action with a policy check.
| Hook point | Possible use | Risk to manage |
|---|---|---|
| Before a tool call | Block dangerous commands, require approval, add credentials safely. | Over-blocking legitimate work or leaking policy details. |
| After a file edit | Format, lint, run targeted tests, update generated files. | Unexpected edits or slow feedback loops. |
| Before commit or deploy | Run tests, scan for secrets, check changelog, enforce policy. | False confidence if checks are too shallow. |
| When context loads | Inject project instructions, fetch docs, add relevant memory. | Context bloat or stale instructions. |
Interface reshaping
Wrappers reshape one interface into another.
Thin wrapper
Adds a friendlier command, schema, or output format around an existing capability.
Example: a script that converts messy CLI output into JSON.
Thick wrapper
Adds state, retries, permissions, caching, routing, or an agent loop around existing tools.
Example: Goose, an open-source AI CLI, wrapping shell tools, memory, and approvals into one host experience.
A protocol like MCP is one kind of wrapper, but it is not the same as a skill. MCP vs skills walks through when each one fits.
How it got this shape
Why AI hosts ended up borrowing extension patterns
This did not start in AI. Browsers had extensions, editors had plugins, shells had aliases and startup files, and IDEs built whole ecosystems out of small pieces that changed behavior without rewriting the core product.
AI hosts ran into the same problem almost immediately. Raw model output was too generic, so builders started packaging know-how, guardrails, and interface shims around the model. The result looks less like a brand-new invention and more like old extension habits meeting a new runtime.
That is basically what skills, hooks, and wrappers are. One teaches a recurring procedure, one intercepts a lifecycle moment, and one reshapes an awkward interface into something the host can actually use.
Go deeper See how these categories start to blur together
Category drift
Tool categories often absorb each other.
| Pattern | What happens | Example |
|---|---|---|
| CLI becomes MCP | A server wraps shell commands and exposes them as typed tools. | rg or gh behind tools/call. |
| Skill becomes workflow | A skill starts as instructions, then gains scripts, checks, and reusable state. | A release skill that tests, updates a changelog, tags, and publishes. |
| Hook becomes policy engine | Lifecycle callbacks grow into approvals, linting, logging, and enforcement. | Block destructive shell commands or secrets in commits. |
| Host absorbs protocol features | A CLI suite ships native tools that overlap with what MCP servers provide. | Built-in file read, search, shell, and GitHub tools. |
| Persistent agent wraps other agents | A daemon delegates work to specialized CLI agents or subagents. | A long-running assistant launching coding agents for isolated tasks. |
Go deeper Follow one command through four extension layers
One test command, four layers
1
Tool: npm test runs the test suite. It does the work directly.
2
Wrapper: a script runs only affected tests and returns stable JSON for an agent.
3
Skill: instructions tell the agent when to run tests, how to interpret failures, and when to stop.
4
Hook: the test command runs automatically before commit or after a file edit.
Ready to build
Try each layer with a real artifact.
One command is enough to make the distinction concrete. The labs let you build each layer instead of memorizing the labels:
Lab 04 — write a skill file that teaches the agent a repeatable procedure.
Lab 05 — add a hook that runs a check automatically before or after an action.
Lab 02 — build the wrapper that the skill and hook sit on top of.