Claude Code Extensions: Skills, Subagents, Hooks, and Plugins

June 23, 2026 · How Claude Actually Works (part 17)

▶ Watch on YouTube & subscribe to The Stack Underflow

Claude Code is not a monolith you have to take as-is. It ships with four distinct extension points — skills, subagents, hooks, and plugins — each targeting a different kind of problem. Understanding which bay to reach into is the difference between a tidy, maintainable setup and a settings file that nobody wants to touch.

This tutorial maps all four extension types: what they do, where they live on disk, and when to use them. Same engine throughout — four very different levers.

The one-sentence version: Claude Code has four extension bays — skills add knowledge, subagents add isolation and parallelism, hooks add deterministic lifecycle control, and plugins bundle everything into a versioned, shareable package.

The Four Extension Bays at a Glance

Before diving into each one, here is the high-level map:

Different homes, different powers. The location is the tell.

Skills — Adding Know-How

A skill is a Markdown file (skill.md) that declares a name, a description, instructions for Claude, and optional resource references. That is the entire format — it is an open standard, no proprietary binary, just text on disk.

skill.md
--------
name: pdf-processor
description: Extract, parse, and summarise PDF documents
instructions: |
  When given a PDF file path, use the read_file tool to load it,
  extract structured text, and return a summary with section headers.
resources:
  - ./prompts/pdf-system-prompt.txt

The important behavior: when a task appears that matches a skill’s description, Claude auto-pulls that skill in — no explicit prompting required. You describe what the skill is for, and the matching happens automatically.

When to reach for a skill: you have a repeatable task type (PDF parsing, code review checklists, database migration steps) and you want Claude to come pre-loaded with the right context every time that task appears, without you manually pasting instructions into every prompt.

Subagents — Isolation and Parallelism

Subagents live under include/agents/. Each one spawns as a separate session with its own small context window, independent of the main session.

include/
  agents/
    search-agent.md
    summariser-agent.md

The pitch is two things working together:

1. Isolation — a noisy search operation (lots of intermediate results, false starts, web noise) happens in a subagent’s context, not the main one. The main context stays clean and focused.
2. Parallelism — multiple subagents can run simultaneously. Two research threads, two code-generation branches, two verification passes — all in parallel, results merged back into the main session.

When to reach for a subagent: any task that is either (a) context-polluting by nature (broad searches, exploratory work), or (b) independently parallelisable (fan-out patterns, concurrent tool calls).

Hooks — Deterministic Lifecycle Control

Hooks live in settings.json. They attach to lifecycle events:

• pre_tool_use — fires before a tool call executes
• post_tool_use — fires after a tool call completes
• session_start / session_stop — fires at session boundaries

{
  "hooks": {
    "pre_tool_use": [
      {
        "matcher": "bash",
        "command": "scripts/validate-bash-call.sh"
      }
    ]
  }
}

The key word here is deterministic. Unlike a prompt instruction (“please don’t call dangerous tools”), a hook is code. It fires every single time the matched event occurs — no exceptions, no vibes. A bad tool call gets blocked before it executes. Green check, guaranteed.

This is where you encode organisational policy: “no shell commands that touch production”, “log all file writes to the audit trail”, “run a lint check after every code edit”. Policies belong in hooks, not in system prompts.

When to reach for a hook: you need a hard guarantee, not a soft suggestion. Anything that must happen on every invocation — auditing, safety gates, automatic validation — is a hook.

Plugins — Bundling Everything Together

A plugin is a versioned bundle that can contain any combination of:

• A skill
• A subagent
• A hook
• A slash command
• An MCP server

my-plugin-v1.2.0/
  skill.md
  agents/
    helper-agent.md
  hooks/
    pre_tool_use.sh
  mcp/
    server.py
  manifest.json   ← version tag lives here

Plugins install from a marketplace or a local bundle directory. The version tag (v1.2.0) makes them shareable and pinnable — a team can all run the same plugin version and know exactly what behaviour they are getting.

When to reach for a plugin: you have built a setup (combination of skill + hook + MCP integration) that works well, and you want to share it across projects or with other developers without manually copying files around.

ASCII Map: Where Each Extension Lives

Claude Code (core engine)
│
├── skill.md            ← Skills (auto-invoked know-how)
├── include/
│   └── agents/         ← Subagents (isolated parallel sessions)
├── settings.json       ← Hooks (lifecycle gates, always fires)
└── marketplace /
    local bundle dir    ← Plugins (versioned bundles of the above)

Common Misconceptions

• “Skills are just system prompt injections.” Not exactly. A skill is an open standard Markdown file that Claude picks up automatically based on task relevance — it is not the same as prepending text to every conversation. The auto-invocation logic is the key differentiator.

• “Subagents share context with the main session.” They do not. Each subagent gets its own separate, small context window. That isolation is the entire point — the main session stays uncluttered regardless of how noisy the subagent’s work gets.

• “Hooks are optional niceties.” Hooks are the only mechanism that gives you a hard, code-level guarantee that something always fires at a lifecycle event. A prompt instruction can be ignored or forgotten across turns; a hook cannot. Treat them as your policy enforcement layer.

• “Plugins are just bundles for distribution.” Plugins do enable sharing, but they also enforce versioning. That version tag means you can pin a team to v1.2.0 and know every member has identical behaviour — something loose file-copying cannot guarantee.

Frequently Asked Questions

Can I use multiple skills at the same time? Yes. Claude can pull in multiple skills if multiple task types match. If you are doing work that touches both PDF processing and database migrations, both skills can be active simultaneously.

Do hooks run for all tool calls, or only specific ones? Hooks are configured with matchers in settings.json, so you can scope them to specific tools (e.g., only the bash tool, only write_file) or apply them broadly. The guarantee — that the hook fires every matching time — holds either way.

Is there a performance cost to using subagents? Each subagent is a separate session, so there is some overhead in spinning one up. The trade-off is isolation and parallelism. For tasks that are truly parallelisable, the wall-clock time often comes out ahead despite the per-session cost.

Where do I start if I am new to Claude Code extensions? Skills first. They are the lowest-friction entry point — write a Markdown file describing what you want Claude to know for a recurring task type, put it in skill.md, and you are done. Graduate to hooks once you need policy guarantees, and subagents once you have work that is either noisy or parallelisable.

Where This Fits in the Series

This tutorial is part of How Claude Actually Works, a course that builds up a developer-accurate mental model of Claude — from tokenisation and context windows to tool use, MCP, and now the extension architecture of Claude Code. The four extension bays covered here (skills, subagents, hooks, plugins) are the building blocks you will reach for once you start treating Claude Code as a platform rather than just a chat interface.

The video also mentions the Agent SDK — available as both Python and TypeScript libraries — as the next topic in the series, which takes these same building blocks and makes them programmatically composable.

Browse all tutorials to see the full series and find the episodes that cover hooks in depth (see playlist 03 for the dedicated hook deep-dive).