How Claude Code Fits Together: Skills, Subagents, MCP, Hooks, Plugins

What Claude Code is, architecturally

Claude Code works best when it's understood as an agentic software engineering orchestration system, not a code generator you prompt. It gathers project context, works out what's needed, uses tools, hands pieces to specialized subagents, talks to outside systems, carries out actions, checks the outcome and goes around again if something's off.

In one line, the behavior is a loop of gathering context, taking action and verifying results. The language model is only one component. Context management, reusable workflows, specialized workers, tools, integrations, deterministic automation and verification surround it.

Compare the two flows. A traditional coding assistant goes prompt, generate code, return a response. An agentic setup goes requirement, understand context, select capabilities, execute, validate, iterate, deliver. Take a request for a test file. An agentic workflow could look through the repository, spot the existing testing conventions, find the affected API, write tests, run them, analyze what failed, change the implementation, validate again and finish with a summary. The big shift is from producing code to executing and verifying tasks.

CLAUDE.md: persistent project context

CLAUDE.md is the project's persistent context layer. It holds things like coding conventions, architecture decisions, repository structure, build and test commands, testing standards, security rules and what counts as done. A small slice might read:

• Framework: Playwright with TypeScript
• UI tests run through npm run test:e2e, API tests through npm run test:api
• Credentials are never hardcoded
• Each new API endpoint needs negative tests

That spares engineers from explaining the same conventions again and again. Think of the file as the answer to "how does this project work?"

The file should hold stable knowledge that Claude needs over and over: repository conventions, what testing requires, architecture principles, build commands, naming rules, security requirements and team habits. It shouldn't grow into a sprawling manual of step-by-step instructions for every possible task. A handy dividing line is that CLAUDE.md says what Claude should know about the project, while a Skill says how to carry out a given kind of work. Keeping them apart makes upkeep easier and the context tighter.

Skills: reusable expertise

A Skill captures reusable expertise as a workflow. It can include instructions, scripts and supporting resources for a specialized activity: API testing, code review, security review, refactoring, documentation generation or regression testing. Writing the workflow once saves explaining the same task to Claude repeatedly. A Skill answers how this kind of work gets done.

An API testing Skill, for example, could walk through these stages in order:

1. Identify the API contract.
2. Inspect the tests that already exist.
3. Generate positive scenarios.
4. Generate negative scenarios.
5. Generate boundary cases.
6. Execute the tests.
7. Analyze failures.
8. Produce a report.

Given a request like "add regression coverage for the payment API", the Skill doesn't jump to writing test code. It applies a standard testing methodology, so each API gets tested to the same organizational standard.

CLAUDE.md versus Skills

The distinction is context versus procedure. CLAUDE.md describes the project: API tests use Playwright, every endpoint needs negative testing, credentials come from environment variables. An API testing Skill describes the procedure: inspect the contract, generate positive, negative and boundary tests, run them and classify the failures. One covers what the agent needs to know, and the other covers how it should do the work.

Subagents: delegating focused work

Subagents are specialized workers that take on a focused task inside their own context and send results back to the main agent. A main agent might delegate to a UI testing subagent, an API testing subagent and a security subagent. Each investigates its own area independently, and the main agent merges their outputs into a final result.

Why not one big agent?

Complex engineering work often has several independent concerns. A new payment feature may need UI validation, API regression testing, security analysis and database verification. One agent could try all of it, but context swells and unrelated material gets mixed together. Subagents bring four advantages:

• Context isolation: each one receives only the information that's relevant to it.
• Specialization: each can follow different instructions.
• Parallel investigation: independent tasks can be analyzed separately.
• A cleaner main context: intermediate logs don't need to stay in the orchestrator's primary context.

Skill versus subagent

A Skill describes how work should be done, and a subagent is who does a specialized share of it. The API testing Skill spells out the organization's methodology. The API testing subagent receives one particular API and analyzes it using suitable instructions and tools.

Subagents and the context window

Agentic tasks generate plenty of intermediate output. A security review might produce dependency analysis, authentication and authorization findings, security logs, code searches and test output. Feeding all of it into the main agent makes orchestration harder over time. A security subagent can do the digging on its own and return a compact result, such as two critical findings, four medium ones, recommended changes and the tests required. The main agent gets the outcome and not every step along the way. Context isolation is therefore an architectural benefit as much as a convenience.

MCP and tools

What MCP is

MCP stands for Model Context Protocol. It's the integration mechanism through which an agent talks to external systems and data sources. Claude Code sits on one side, and on the other are GitHub, Jira, databases, APIs, browsers and monitoring systems. That moves the agent beyond the local coding environment into the systems used across the whole development lifecycle.

Software engineering rarely stays inside an editor. A developer may need Jira for requirements, GitHub for source and pull requests, databases for validation, monitoring for production errors and APIs for application behavior. With MCP, a workflow could read a Jira ticket, inspect the affected repository, identify the API, generate tests, run them and open a pull request. The coding agent becomes part of a wider engineering process.

MCP versus tools

They aren't the same thing. MCP is the protocol or integration layer, and a tool is the specific capability the agent can call. A Jira MCP server might expose get_issue(), search_issues() and create_comment(). Those functions are tools, and MCP is how they become reachable. In short, MCP is how the agent connects, and a tool is what it can do.

What tools give an agent

Tools let an agent take actions. Without them an LLM mostly reasons and writes text. With them it can read a file to understand an implementation, search the repository to find relevant code, edit a file to change behavior, run a command to execute a test, read the output to diagnose a failure, edit again to fix it, and rerun validation to confirm. Tools turn a response generator into an active participant in engineering work.

Kinds of tools

Claude Code has built-in abilities for reading and editing files, searching code, running commands, interacting with resources and spinning up specialized subagent workflows. MCP can expose more. It's useful to sort them by purpose:

• Observation tools read, search and inspect.
• Action tools write, edit and execute.
• Integration tools reach external platforms.
• Delegation tools call on specialized agents.

Together they let the system observe its environment, decide, act and check the result.

Hooks, commands and plugins

Hooks

Hooks supply deterministic, event-driven automation. A Skill may tell Claude to run regression tests when testing an API. A hook works differently: whenever a given event occurs, a validation runs automatically. After code is modified, for example, the hook could trigger the formatter, then lint, then targeted tests, and return the validation results. That's valuable when certain engineering controls must happen every single time.

Skills are workflows the model can use, while hooks are automation triggered by events. A Skill describes the recommended process for a code review. A hook runs lint validation right after any file changes. Skills help the model understand how to work, and hooks make sure key actions happen when specific events occur.

Why hooks matter in production

Generative AI is probabilistic, so teams shouldn't rely on the model to decide whether an important control runs. If every change has to pass formatting, linting, security scanning and unit tests, those steps can be tied to deterministic automation and not left to model judgment. The principle is to use AI reasoning for flexible decisions and deterministic automation for mandatory controls, and the split matters most in enterprise settings.

Commands

Commands are explicitly triggered workflows, such as /review, /test and /debug. Typing /review starts a predefined code-review workflow on purpose. A command says "I explicitly want to run this workflow."

Commands are user-initiated while hooks are event-initiated. Typing /test is an explicit command. Source code changing and tests running automatically in response is event-driven automation. So a command is human-triggered, and a hook is event-triggered.

Commands and Skills also overlap, because a reusable Skill may expose a workflow that people invoke on purpose. A review capability could live in a Skill and be started with /review. A Skill holds far more than a prompt, however: instructions, supporting resources, scripts and configuration wrapped around a reusable engineering capability.

Plugins

Plugins package and distribute extensions. Imagine a testing organization that has built an API testing Skill, a security testing Skill, an API subagent, a security subagent, validation hooks and MCP integrations. Rather than having every developer recreate that environment, the pieces ship together as one plugin.

This is why plugins matter to enterprises. They lift agentic engineering from personal productivity to organizational capability. When there's no shared packaging, every engineer ends up configuring the AI environment differently. A standard plugin can bundle engineering standards, testing methods, specialized agents, automation rules and integrations, so each project gets identical capabilities. In architecture terms, plugins belong to the governance and standardization layer.

How the components fit together

One compact picture assigns each component a job:

• CLAUDE.md knows the project.
• Skills know how to work.
• Subagents take delegated, specialized work.
• Tools perform actions.
• MCP connects to external systems.
• Hooks automate lifecycle events.
• Commands trigger workflows on demand.
• Plugins package and distribute capabilities.

Claude Code sits in the middle and orchestrates them. They address different architectural problems and aren't interchangeable features.

One workflow from start to finish

Take the requirement "add regression coverage for the new payment API." A plausible run goes like this:

1. Requirement. Claude Code receives the request.
2. Project context. CLAUDE.md supplies testing standards, commands, repository conventions and security expectations.
3. Skill selection. An API testing Skill provides the organization's methodology.
4. Delegation. Specialized subagents analyze API functionality, security concerns and regression impact.
5. Integrations. MCP-connected systems give access to the relevant external platforms.
6. Tools. Claude Code reads code, searches files, writes tests and runs commands.
7. Validation. Hooks run linting, formatting, targeted tests or other checks.
8. Verification. Claude assesses the results and decides whether more work is needed.
9. Final output. The agent hands back the tests, their results, documentation and a wrap-up of what was done.

It's a full agentic engineering workflow, and quite far from simple code generation.

The agentic loop

To restate the core model: gather context, take action, verify results. Gathering covers understanding the requirement, the repository, architecture, conventions, dependencies and the current implementation. Acting covers using tools to search, change, run, integrate or delegate. Verifying covers running tests, reading outputs, spotting failures and judging whether the requirement was really satisfied. A failed verification sends the system back to gathering or acting.

In practice the flow is closer to context, action, verification, correction, verification again, then completion. That iteration is what separates a dependable agent from one-shot code generation.

Designing an AI test-engineering setup

A strong SDET architecture on Claude Code could combine:

• CLAUDE.md with testing frameworks, architecture, test conventions, security rules and the definition of done.
• Skills for API testing, UI testing, regression testing and failure analysis.
• Subagents for UI, API, security and regression work.
• Tools for repository search, file editing, command execution and test runners.
• MCP connections to GitHub, Jira, databases, APIs and monitoring.
• Hooks that run formatting, linting, tests and validation after changes.
• Commands such as /api-test, /regression, /security-review and /debug.
• A plugin that packages the whole thing so several engineering teams can reuse it.

The orchestrator coordinates these parts according to the requirement.

Choosing the right mechanism

Five questions point to the right building block.

• Is it reusable knowledge about performing a task? Use a Skill.
• Does it need a specialized, independent worker? Use a Subagent.
• Does the agent have to carry out an operation? Use a Tool.
• Does the action rely on an outside platform or data source? Look at MCP.
• Should something run automatically each time a lifecycle event fires? Use a Hook.

A final question covers distribution: if the capability has to be packaged and shared, use a Plugin. This framework shows an understanding of each layer's responsibility, which is why it comes up in architecture discussions.

The central lesson

Successful agentic engineering isn't mainly about a bigger or smarter LLM. A working system needs several capabilities coordinated:

• Context, so the agent understands the project.
• Skills, for repeatable expertise.
• Delegation, because complex tasks may need specialized workers.
• Tools, so the agent can act.
• Integration, for access to outside engineering systems.
• Automation, so mandatory processes fire reliably.
• Verification, to find out whether actions actually worked.
• Packaging, so capabilities can be reused across teams.

The evolution then reads: AI chatbot, AI coding assistant, AI agent, agentic engineering workflow, and finally an agentic software engineering platform.