Claude Code: skills, hooks, subagents and plugins

Claude Code is Anthropic’s CLI agent. It reads your code, modifies your files, runs commands, manages your Git commits. So far, nothing dramatically different from a Cursor or a Copilot. What sets it apart is the extensibility ecosystem that has grown around it: skills, hooks, subagents, agent teams, plugins. Claude Code is not a passive assistant. It is a platform on which you build your own workflows.

Here is what each building block brings in practice.

Skills: custom capabilities on demand

A skill is a Markdown file (SKILL.md) containing reusable instructions. When Claude Code loads it, it gains a new capability: deploying, auditing, scaffolding a component according to your conventions, running a test suite with a specific protocol.

Skills live in three places:

• ~/.claude/skills/ for your personal skills (available across all your projects)
• .claude/skills/ in the repo for skills shared with the team
• Inside plugins (more on that below)

By default, a skill can be triggered two ways: you call it with a slash command (/deploy, /review, /scaffold-component), or Claude loads it on its own when the context calls for it. The disable-model-invocation: true field reserves it for the slash command; user-invocable: false reserves it for Claude, for background knowledge.

What makes skills powerful is that they are dynamic. You can use $ARGUMENTS to inject parameters, and the !`command` syntax to inject the output of a command at load time.

A concrete example, a /deploy skill:

---
name: deploy
description: Run tests, build, and deploy to production
disable-model-invocation: true
---

# Deploy workflow

1. Run the full test suite: `npm test`
2. If tests pass, build the project: `npm run build`
3. Deploy to Cloudflare Pages: `npx wrangler pages deploy dist/`
4. Verify the deployment is live by checking the production URL
5. If any step fails, stop and report the error. Do NOT continue

The advantage over a bash script: Claude Code adapts its behaviour when something goes wrong. A failing test does not produce a cryptic error message in your terminal. It produces an explanation of what broke and a proposed fix.

Hooks: automated guardrails

Hooks are actions that execute automatically at specific points in Claude Code’s lifecycle. Before it uses a tool (PreToolUse), after (PostToolUse), when you submit a prompt (UserPromptSubmit), when it stops (Stop), or when it sends a notification.

Several handler types exist, including:

• command: runs a shell command, which receives the details of the action as JSON on standard input
• http: posts the same JSON to a URL
• prompt: hands the decision to Claude in a single turn
• agent: spawns a subagent with tool access (experimental)

A command blocks the action by exiting with code 2, or by returning a deny decision.

The most immediate use case: preventing mistakes before they happen. A PreToolUse hook on the Bash tool can block a git push --force to main. A PostToolUse hook on the Edit tool can run a linter after every file modification.

Configuration example in .claude/settings.json, where each script reads the action’s JSON on standard input:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/lint.sh"
          }
        ]
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-force-push.sh"
          }
        ]
      }
    ]
  }
}

Hooks turn Claude Code from an autonomous agent into an autonomous agent with rails. It is the difference between handing someone the car keys and handing them the keys with a GPS and speed limits built in.

Subagents: delegate intelligently

When a task is too large or too specialised, Claude Code can spawn subagents via the Agent tool (called Task until version 2.1.63). Each subagent gets its own conversation, its own context, and can run in the background while the main agent continues working.

Several subagent types are available out of the box:

• Explore: read-only, fast, ideal for code search and investigation
• Plan: gathers context during plan mode before presenting a plan
• General-purpose: complex multi-step tasks combining exploration and action

You can also create custom subagents in .claude/agents/ with a YAML frontmatter. There you can restrict the available tools, set a model or fix a permission mode.

---
name: security-reviewer
description: Reviews code changes for security issues
model: sonnet
tools:
  - Read
  - Grep
  - Glob
---

You are a security reviewer. Analyze the code changes for:
- SQL injection vulnerabilities
- XSS vectors
- Hardcoded secrets
- Insecure dependencies

Report findings with severity (critical/high/medium/low) and file locations.
Do NOT modify any files.

One limit to know: by default, a subagent can spawn its own subagents up to three layers below the main conversation. This bounded depth prevents runaway loops but requires you to think carefully about how you decompose tasks.

Agent Teams: orchestrate a swarm

Agent Teams take the concept a step further: multiple Claude Code instances work in parallel, coordinated by a team lead. This is an experimental feature, off by default, enabled through the CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS variable.

The principle: a lead agent creates a team, spawns specialised teammates, and distributes tasks via a shared task list. Each agent can message the others, flag a blocker, or mark a task as done.

A typical use case: you have a full-stack feature to implement. The lead breaks down the work, assigns the frontend to one agent, the backend to another, and the tests to a third. All three work in parallel. When the backend agent finishes its endpoint, it signals the team, and the frontend agent can start the integration.

The core tools: Agent to spawn teammates, TaskCreate and TaskUpdate for the shared task list, SendMessage for communication between agents.

It is powerful, but it demands a well-structured CLAUDE.md so that each agent has the necessary context without manual intervention.

Shared context: CLAUDE.md and memory

The CLAUDE.md file is the brain of the configuration. Claude Code reads it automatically at startup and refers to it throughout the session. It exists at multiple levels:

• Project (.claude/CLAUDE.md or CLAUDE.md at the root): code conventions, architecture, tech stack
• User (~/.claude/CLAUDE.md): personal preferences, global guidelines
• Local (CLAUDE.local.md at the project root): personal preferences for this project, kept out of Git

The .claude/rules/ directory lets you modularise instructions with separate files: testing.md, security.md, style.md. Each file loads as an additional rule.

Claude Code also has automatic memory. Between sessions, it retains patterns it learns about your codebase: naming conventions, test structure, formatting preferences. This memory accumulates and makes the agent more effective over time.

Practical tip: put the conventions that everyone must follow in the project CLAUDE.md (architecture, naming, stack). Put your personal preferences in your user CLAUDE.md (message verbosity, language, how to handle ambiguity).

And Claude Cowork

Claude Cowork applies the same agentic approach to office work, on your folders and tools, and it changed deeply in 2026: merged into chat, running in the cloud, with enterprise controls. These changes are covered in our guide to Claude Cowork for business.

Plugins: bringing it all together

Plugins are the packaging mechanism. A plugin bundles skills, hooks, custom agents, and MCP servers into a single installable package. Every element is namespaced: /marketing:brand-voice, /legal:contract-review.

Anthropic maintains official plugins on GitHub for several domains: legal, sales, marketing, data. The community publishes others. You can also create your own for internal workflows.

MCP (Model Context Protocol) integration is the layer that connects plugins to the outside world: databases, APIs, SaaS tools. An MCP server turns any data source into a tool that Claude Code can use natively.

When to use a plugin versus a standalone .claude/ configuration? If your skills and hooks are specific to one project, keep them in the repo. If you reuse them across multiple projects or want to share them with other teams, package them as a plugin.

How we use it

We use Claude Code daily on client projects. Our custom skills handle deployment workflows, technical documentation generation, and component scaffolding tailored to each project’s conventions. Our hooks enforce code quality before every commit. Subagents parallelise code reviews and security audits.

This is also what we teach in our training sessions. Not the theory of agentic AI, but the hands-on setup: how to structure an effective CLAUDE.md, which hooks to put in place from day one, how to break a project into tasks for Agent Teams.

The Claude Code ecosystem is evolving fast. But the fundamentals are stable: skills for capabilities, hooks for guardrails, subagents for parallelisation, and plugins for sharing. If you work with code every day, the investment pays for itself within a few days.

Sources

• Claude Code: Anthropic documentation
• Hooks: Anthropic documentation
• Subagents: Anthropic documentation

---

Train your teams on Claude Code. 2 days, full setup included →

Claude Code versus Gemini CLI, Codex, Hermes and OpenClaw: our 2026 comparison →