Claude Code Extensions: Skills, Hooks or Subagents?

When I extend an agent, the first question is not “Can it do this?” It is “What should own this behavior?” A reusable procedure, a delegated review and a rule that blocks an action need different homes.

In Claude Code, the four mechanisms I reach for are skills, subagents, hooks and MCP. They can compose, but they do not provide interchangeable guarantees.

Choose the mechanism by the responsibility you need, not by which extension is newest. Procedures need instructions, independent work needs a handoff, event checks need lifecycle integration, and external capabilities need an interface. A single workflow may need more than one.

This table is a design aid, not a taxonomy of everything the tools can do. A skill can use MCP tools and run in a subagent. A hook can invoke a model-backed check. That last case is event-triggered, but its judgement is not deterministic simply because it is called a hook.

For the repository-wide context at the bottom of the table, see the instructions I would put in CLAUDE.md. Keep those facts separate from the procedure for a particular task.

A good skill describes a task-specific procedure, the evidence it needs and the condition for stopping. It saves repeating instructions while leaving judgement with the agent. The most valuable content is often the exception or failure case, not the happy-path checklist.

For a portfolio visual review, I would specify routes, viewports, important interactions and the difference between an accepted screenshot and a convincing result. An image existing on disk proves capture worked; it does not prove a button is readable or that an article is comfortable to scan.

The skill should also name what not to do. A visual review should not subscribe a real email address, send a contact message or deploy a change merely to exercise a control.

Claude Code's skills documentation explains discovery and invocation, including skills that run in a forked context. Keep the body focused and move long reference material into files loaded only when needed. Context cost depends on the session and caching; it is not a fixed invoice per line.

A subagent is worth the handoff when the task is independently useful and its result can be checked without replaying every intermediate step. Good examples include reviewing a fixed article set or tracing one failure path. A vague “make everything better” delegation usually creates rework.

A useful brief names:

• The exact files or system in scope.
• Whether edits are allowed.
• The standard the work should meet.
• What must be preserved.
• The evidence to return, including unresolved questions.

For example, an editorial reviewer should return the sentences changed and the claims that could not be verified, not just “the voice looks good.” The parent still owns integration and final checks.

The subagent documentation distinguishes fresh-context agents from forks that inherit conversation history. Choose deliberately. Independence is helpful only when the agent receives enough context to solve the right problem.

A correctly configured hook can run a check at a supported event and, for blocking events, prevent the action from proceeding. The guarantee depends on the handler, event and failure behavior. It does not extend automatically to every command, timeout or alternate path.

Claude Code documents that a command hook exiting with code 2 at PreToolUse blocks that tool call. A PostToolUse check runs after the action, so it cannot undo it. The hooks reference also documents non-blocking failure cases, including a command hook that cannot start or times out on PreToolUse.

That makes testing the negative path essential:

A regex that rejects one shell command is not a sandbox. For security boundaries, use tool permissions, operating-system isolation and authorization in the service performing the action.

For content quality, a script is a better fit. This portfolio's post linter can verify frontmatter and internal links. Whether the writing makes a useful argument still needs a reader. The distinction mirrors validating a generated diagram: a valid structure is necessary, not sufficient.

An integration belongs in MCP when a standard tool-and-data interface is useful across agent clients. The backing system can be local or remote. MCP supplies the interface; it does not make the source trustworthy or grant permission to act on everything it exposes.

A skill might explain how to triage an issue. An MCP tool can retrieve that issue. An HTTP client or CLI could also retrieve it; MCP is one integration choice, not the only route to authenticated data.

Claude Code supports MCP tool discovery and configuration, including on-demand tool search under supported configurations. That can reduce eager schema loading, but narrow results still matter. Retrieving ten relevant issues is usually more useful than asking for an entire workspace.

The MCP tool specification treats tool annotations as hints, not a substitute for trust decisions. A tool calling itself read-only is a claim to verify. That evidence gap is part of the reasoning behind ResolveMesh.

A reliable workflow assigns each mechanism one clear responsibility and makes the handoffs visible. The skill defines the method, the subagent handles bounded work, the integration retrieves evidence, and checks validate the result. None should silently expand the user's authorization.

For a release review, I would use this sequence:

1. A skill describes the release criteria and permitted checks.
2. A subagent reviews a clearly bounded change.
3. A tool reads the deployment and commit status.
4. Tests and build checks validate the artifact.
5. The main agent compares the evidence with the user's request before reporting completion.

A deployment record is not a live page check. A passing build is not proof that the correct commit reached the production alias. Keeping those claims separate matters more than how many extensions are installed.

Start with the repeated failure you can name, then add the smallest mechanism that addresses it. A short repository rule may be enough. If the work is procedural, make a skill. If it is a check, implement the check before choosing where to attach it.

The documentation linked here was reviewed on September 7, 2026. Exact events, settings and context behavior will continue to change; follow the relevant client documentation rather than copying a version-specific limit from a blog post.

The durable rule is simpler: instructions explain the work, delegation divides it, integrations expose capabilities, and enforcement needs a tested boundary.