Claude Code skills vs subagents vs MCP for teams

Choosing between Claude Code skills vs subagents vs MCP is not a question of which feature is most powerful. For a senior engineer designing a team workflow, the better question is where the context should live, who owns the behavior, how much permission risk is acceptable, and whether the result needs to be enforced or merely suggested.

The short version: use repo instructions and rules for facts Claude must know often, skills for reusable procedures, subagents for noisy delegated work, hooks and permissions for controls that must actually run or block, MCP for external systems, and slash commands for explicit human-triggered entry points.

That sounds simple. In practice, teams get into trouble when they use the right feature for the wrong layer. A long CLAUDE.md becomes a dumping ground. A skill becomes a hidden production policy. An MCP server gets built for a local script. A subagent is treated like a reusable procedure instead of a separate worker. Hooks are skipped because a prose instruction says "never do that," even though the brief cites Anthropic's steering guidance that deterministic controls should not live only in instructions.

This article gives you a practical selection model for Claude Code instructions, skills, subagents, hooks, slash commands, and MCP. It is written for team workflows, not solo prompting experiments.

Internal link suggestion: Link "Claude Code hooks and permissions" to an article about enforcement, permission modes, and lifecycle controls.

The decision is about context, authority, risk, and reuse

Before comparing features, separate four concerns.

• Context cost: does Claude need this information in every session, only when a task matches, or only inside a delegated worker?
• Authority: is this guidance, a reusable procedure, an external tool contract, or an enforceable control?
• Permission risk: can this touch the filesystem, shell, SaaS data, production systems, or internal APIs?
• Ownership: should the workflow be personal, project-level, plugin-distributed, or managed by the organization?

Those four questions prevent most misdesigns. They also match the shape of the official Claude Code guidance in the research brief: Anthropic's docs and steering post frame customization by load timing, compaction behavior, context cost, and authority.

Claude Code skills vs subagents vs MCP: the practical matrix

In practice, the first version of your decision tree can be this:

1. If it must always be known, put the shortest useful version in CLAUDE.md or rules.
2. If it is a repeated procedure, make it a skill.
3. If it creates lots of intermediate evidence, run it in a subagent.
4. If it needs another system, expose that system through MCP or through a purpose-built CLI plus a skill.
5. If it must be guaranteed, blocked, or audited, use hooks, permissions, managed settings, or sandboxing.
6. If a human should choose when it runs, expose it as a slash command or user-invocable skill.

Use instructions and rules for facts, not guarantees

CLAUDE.md is the right home for stable project information: common commands, test conventions, repo layout, deployment notes, or team preferences. The brief also calls out .claude/rules/ for more specific constraints, especially path-scoped file conventions.

The constraint is context. Root instructions are always loaded. Subdirectory instructions and matching rules can be more targeted, but every extra line still competes with task context. If your CLAUDE.md explains every release process, database rule, style exception, and incident response playbook, it stops being memory and becomes a tax on every task.

A good team rule is simple: CLAUDE.md should hold the facts Claude needs often, not every procedure the team has ever written. Put procedures in skills. Put deterministic checks in hooks. Put external access in MCP. Put narrow file rules close to the files they govern.

Also be honest about authority. A sentence that says "never run destructive commands" is useful guidance, but it is not a control. The brief cites Anthropic's steering post directly on this anti-pattern: deterministic always-never controls should not live only in CLAUDE.md. If the action must be blocked, configure the permission layer or a hook.

Internal link suggestion: Link "AGENTS.md and repository instruction best practices" to a guide on keeping always-on agent instructions small and maintainable.

Use skills for reusable team procedures

Skills are usually the best fit when the team keeps repeating the same workflow: release preparation, pull request review, migration planning, incident log triage, design review, test generation, or a domain-specific checklist.

The brief attributes several important properties to Anthropic's Claude Code skills docs. A skill has a name and description that load first. The body loads when invoked or selected. Skills can include supporting files, scripts, examples, assets, invocation controls, subagent execution, and distribution options. The brief also quotes the docs saying, "Custom commands have been merged into skills."

That makes skills the natural successor to many custom command files. A skill can teach Claude how your team expects a task to be done, without forcing all of that procedure into the base session context.

Good skill candidates have three traits:

• The workflow recurs often enough that copy-pasted prompting is wasting time.
• The steps need judgment, not only deterministic automation.
• The knowledge is reusable across tasks, projects, or team members.

Skills are not risk-free. The brief notes that risk rises when skills include scripts or broad allowed-tools. Treat project skills like code. Review them. Version them. Keep permission grants narrow. Do not hide production policy in personal skills that only one engineer has installed.

Use subagents when intermediate context should disappear

A subagent is not a better skill. It is a delegated worker with its own context window. The brief quotes Anthropic's subagent docs: "Each subagent runs in its own context window."

That separate context is the point. Use subagents when the useful output is a concise result, and the intermediate work would pollute the main conversation. Examples include scanning a large codebase, comparing logs, collecting references, reviewing a patch from a specific angle, or running parallel investigations.

Subagents can also have scoped tools, permission modes, MCP server availability, hooks, skills, custom system prompts, models, and optional worktree isolation. That is powerful, but it requires design discipline. A security-review subagent should not automatically have the same MCP servers and shell permissions as a deployment subagent. A log-analysis subagent may not need write access at all.

The clean pattern is to give each reusable subagent a role, a narrow tool surface, and a clear output contract. The parent should receive the conclusion, not a pasted archive of every search result.

Use MCP for systems, not for every local helper

MCP is the right primitive when Claude Code needs structured interaction with an external system: a database, SaaS product, internal API, documentation source, issue tracker, data warehouse, or service that should expose tools, resources, and prompts to multiple AI clients.

The brief cites official MCP docs describing MCP as an open-source standard for connecting AI applications to external systems. It also cites Claude Code's MCP docs for practical details: HTTP is recommended for remote servers, stdio fits local processes, resources can be referenced with @, prompts can appear as commands, and tool search can defer tool definitions until needed. The brief quotes Claude Code's MCP docs: "MCP tools are deferred rather than loaded into context upfront."

This matters because teams worry about context bloat. MCP and skills both reduce repeated prompting, but they solve different problems. Skills package knowledge and procedures. MCP exposes live capabilities and data through a protocol.

Use a local CLI plus a skill when Claude only needs to run a known workflow on local files. Use MCP when the integration needs a server-side resource model, authentication flow, reusable tool definitions, shared prompts, structured resources, or use across multiple clients.

MCP also has the largest integration blast radius in this comparison. The brief calls out authentication, data exposure, prompt injection, tool poisoning, scopes, allowlists, logging, and lifecycle management. MCP servers should be reviewed centrally, especially when they touch SaaS accounts, databases, or internal APIs.

Internal link suggestion: Link "MCP security for AI agents" to a deeper security guide covering tool poisoning, auth scopes, prompt injection, and server review.

Use hooks when obedience is not enough

Hooks are not memory. They are deterministic automation around lifecycle and tool events. Use them for work that should run whether or not the model remembers a preference.

Common examples from the brief include running a formatter after edits, blocking destructive shell commands, validating that SQL is read-only, or exporting a transcript before compaction. These are not style notes. They are controls.

The trade-off is direct. The brief quotes Anthropic's hooks docs: "Command hooks run with your system user's full permissions." That means hooks can enforce policy, but a bad hook can do real damage. They belong in reviewed configuration, with the same care you would apply to scripts that run in developer environments or CI.

For organization-wide rules, use managed settings where available. For project rules, review hooks with the repo. For risky actions, combine hooks with permission modes and sandboxing rather than relying on a single prompt instruction.

Use slash commands for explicit human entry points

Slash commands still matter because they are visible and intentional. They are a good fit when the human should decide when a workflow starts: run a release checklist, summarize a branch, prepare a PR, or execute a known session control.

The brief notes a shift in Claude Code's docs: a custom command file and a skill can both create a command-like entry point, but skills add supporting files, invocation controls, dynamic context injection, subagent execution, and managed distribution options. For new custom workflows, a skill is usually the better package.

A practical default is to keep slash commands thin. Let the command be the entry point. Put the reusable procedure in a skill. Put deterministic checks in hooks. Put external integrations behind MCP or a reviewed CLI.

How to compare the confusing pairs

Skills vs MCP

Choose a skill when the problem is teaching Claude how your team works. Choose MCP when the problem is giving Claude access to a system.

A skill can explain how to run a local deployment dry run. It can include scripts, examples, and checklists. MCP is better when Claude needs to query a deployment system, fetch live release state, inspect a database, or call a SaaS API with scoped authentication.

The brief notes a practitioner pattern: some teams treat skills as a lighter alternative to MCP for local scripts and CLIs. That is reasonable only when the task does not need a live protocol server, OAuth flow, server-side resources, or multi-client reuse.

Skills vs subagents

Choose a skill when you want the current agent to follow a reusable procedure. Choose a subagent when you want a separate worker to gather evidence, perform a bounded task, and return a summary.

A skill improves the current interaction. A subagent isolates context. They can also work together: a subagent can have access to a skill, or a skill can define when subagent execution is appropriate.

Hooks vs instructions

Choose instructions when you want Claude to know a preference. Choose hooks when the behavior must run or the action must be blocked.

"Prefer small PRs" belongs in instructions. "Reject writes to generated files" may belong in a hook or permission policy. "Validate SQL is read-only before execution" should not depend only on Claude remembering a sentence.

Rules vs nested CLAUDE.md

Use the most targeted form that stays maintainable. Repo-wide facts belong at the root. File-specific conventions belong in path-scoped rules or nearby instructions. The goal is to reduce always-on context while keeping important local conventions discoverable.

Governance patterns for teams

The governance model should follow the risk model.

Personal skills and agents are still useful. They help engineers move quickly and test ideas. They should not define hidden production workflow policy. If a procedure matters to the team, promote it into the project or managed distribution path and review it there.

Portability also deserves a real plan. The brief cites Hacker News concern about "locking your project" to the Claude Code harness. That concern is fair. CLAUDE.md, Claude Code hooks, and Claude Code subagent frontmatter are harness-specific. MCP is an open integration standard. Agent Skills are positioned as cross-tool. Teams using several agents may need adapters, parallel instruction files, or a source-of-truth process that generates agent-specific files.

Internal link suggestion: Link "multi-agent coding orchestration" to a guide on keeping Claude Code, AGENTS.md, Cursor rules, and other agent instructions aligned.

Default architecture for a senior engineering team

If you are starting from an overloaded CLAUDE.md, do not add another layer blindly. Split by responsibility.

1. Keep CLAUDE.md short: repo map, common commands, important conventions, and links to deeper workflow artifacts.
2. Move repeated procedures into project skills: release checks, PR review, migration planning, incident analysis, and domain-specific workflows.
3. Create subagents for bounded noisy work: dependency audit, log review, test failure triage, large codebase exploration, and security review.
4. Use MCP only where a real external system boundary exists: SaaS, database, API, issue tracker, documentation source, or shared data service.
5. Use hooks and permissions for anything that must be enforced: blocking commands, formatting, validation, transcript export, or read-only checks.
6. Expose common workflows through slash commands or invocable skills so humans can trigger them intentionally.

This architecture keeps context small, makes ownership visible, and puts enforcement in the right layer. It also gives your team a review path. A change to instructions is reviewed as guidance. A change to a skill is reviewed as workflow logic. A change to MCP is reviewed as an integration. A change to hooks is reviewed as executable control.

Pick the smallest primitive with the right authority

The best answer to Claude Code skills vs subagents vs MCP is usually conditional, not absolute.

Use instructions when Claude needs a fact. Use a skill when Claude needs a reusable procedure. Use a subagent when the work should happen in a separate context. Use MCP when Claude needs a system boundary. Use hooks and permissions when guidance is not enough. Use slash commands when a human should explicitly start the workflow.

The important engineering habit is to keep authority honest. Do not ask prose to enforce policy. Do not ask MCP to replace a checklist. Do not ask a subagent to be a procedure library. Do not make every team habit always-on context.

For most teams, the practical default is clear: short repo instructions, reviewed project skills, narrowly scoped subagents, centrally approved MCP servers, and hooks for controls that must not fail.