Governed Vibecoding vs Unmanaged AI CodingRead Now →
Skip to main content

Skills vs Agents vs MCP

A practical map of agent skills, AI agents, MCP servers, prompts, AGENTS.md, CLAUDE.md, plugins, hooks, commands, and subagents - and when to use each layer.

12 min read
Axiom Studio Team· Engineering

The Short Version

Agents are the workers. Skills are reusable task knowledge. MCP servers expose tools and data. AGENTS.md and CLAUDE.md give standing project instructions. Plugins, commands, hooks, and subagents package or enforce parts of that system.

These concepts are easy to blur because they all influence what an AI coding agent does. The useful way to separate them is by job: who reasons, what knowledge gets loaded, what external systems can be called, and what governance layer records or blocks actions.

A practical rule

Put durable repo-wide facts in project instructions. Put repeatable task procedures in skills. Put live external access behind tools or MCP servers. Put independent judgment in agents or subagents.

The Architecture Map

In a governed AI engineering stack, the layers are complementary. A single agent task might read AGENTS.md, load a code-review skill, call an MCP server for pull request context, run a command, and hand the result to a security subagent for review.

Layer 1

Project instructions

AGENTS.md, CLAUDE.md, repo rules

Layer 2

Reusable know-how

Skills, commands, review checklists

Layer 3

Runtime workers

Agents, subagents, reviewers, planners

Layer 4

Executable access

Tools, MCP servers, shell, APIs

Layer 5

Governance layer

Approvals, logs, policies, audit trail

The mistake is treating one layer as a replacement for every other layer. A skill does not make an agent safe. An MCP server does not teach the agent your review policy. A subagent does not remove the need for project context. Governance comes from designing the whole stack, not from naming one component.

Concept-by-Concept Comparison

The table below uses implementation-neutral language. Claude Code, Codex, OpenCode, OpenClaw, and other runtimes may support these concepts with different file paths, frontmatter fields, invocation models, or permission controls.

Concept
What it is
Primary job
Good fit
Prompt
One conversation instruction
Fast, flexible, disposable
Ad hoc task direction
AGENTS.md / CLAUDE.md
Standing repo or project context
Global conventions and boundaries
How this codebase works
Skill
Reusable workflow package
Task-specific know-how plus references
Review a PR, write docs, run a check
Command
User-invoked shortcut or procedure
Explicit action trigger
Run a deploy or summarize a diff
Hook
Event-triggered automation
Deterministic enforcement around agent events
Block risky shell commands
Plugin
Packaged extension bundle
Distribution and integration
Ship skills, hooks, tools, or UI together
MCP server
External tool/data interface
Live capability or system access
Fetch tickets, query docs, call an API
Subagent
Specialized worker
Delegated reasoning or review
Security reviewer, planner, QA checker
Agent
The runtime that reasons and acts
Chooses tools/skills and produces artifacts
Codex, Claude Code, Cursor agent mode

Skills vs Prompts

A prompt is the fastest way to steer a model in the current turn. It is also easy to lose, copy inconsistently, or forget to include when the next task starts. A skill is for the prompt that keeps coming back.

Use a skill when the workflow has a predictable shape: review a diff, write release notes, update documentation, verify a frontend change, or inspect a security-sensitive path. A skill can carry the instructions, examples, checklists, and scripts that make the workflow repeatable without pasting a long prompt every time.

For the category overview, start with what are agent skills.

Skills vs AGENTS.md and CLAUDE.md

Project instruction files describe the terrain: repository conventions, test commands, ownership boundaries, review process, style rules, and standing policies. They should be read before the agent does any work in that project.

Skills describe repeatable moves inside that terrain. A code-review skill might apply across many repositories. A repo's AGENTS.md explains the local rules that change how the skill should behave in this repository. The two are strongest together: the skill supplies the workflow, the project instructions supply the local constraints.

Do not hide policy in a skill

If a rule must apply to every agent task in a repository, put it in the project instructions or enforcement layer. Skills are conditional; standing safety rules should not depend on whether a model chooses the right skill.

Skills vs MCP Servers and Tools

Skills tell the agent how to do something. MCP servers and tools let the agent do something outside the model: search a code index, fetch a Jira ticket, query a database, read docs, create a pull request, or call an internal API.

A skill can instruct the agent to use an MCP tool, but it should not be confused with that tool. The skill is the procedure. The MCP server is the external interface. The agent is the runtime that decides, under policy, whether and how to use both.

For MCP fundamentals, see what is Model Context Protocol.

Plugins, Hooks, Commands, and Subagents

These concepts often appear in the same product docs as skills, but they serve different jobs.

  • Plugins package extensions so they can be distributed or enabled as a bundle.
  • Commands give users an explicit trigger for a known workflow.
  • Hooks run at event boundaries, which makes them useful for deterministic enforcement.
  • Subagents delegate work to a specialized role or separate reasoning context.

A single plugin might include skills, commands, hooks, and MCP configuration. A command might invoke a skill. A hook might block a risky command before the skill can execute it. A subagent might use the same skill with a narrower role.

Decision Guide

Pick the smallest layer that solves the problem. If a rule needs enforcement, a skill is too soft by itself. If a workflow needs reusable judgment, a shell script is too narrow by itself. If a task needs external data, prompt text alone will stale quickly.

Use a prompt

The task is one-off, low risk, and does not need durable reuse.

Use project instructions

The rule applies across the repo or team, not just one task type.

Use a skill

The workflow repeats and needs checklists, examples, references, or templates.

Use MCP or a tool

The agent needs live access to a system, API, database, or external source.

Use a hook

The rule must run automatically at an event boundary, such as before shell execution.

Use a subagent

The task needs a separate role, independent review, or bounded specialist reasoning.

The Axiom Approach

Once these layers multiply, the real problem becomes visibility. Which instructions were active? Which skill loaded? Which MCP tool was called? Which subagent reviewed the diff? Which human approved the result?

Make the agent stack observable

VibeFlow connects work items, context, execution logs, commits, security review, and QA gates so teams can trace AI-agent work across prompts, skills, tools, and review roles. That audit trail is what turns a powerful agent stack into an accountable engineering system.

See VibeFlow

Ready to get started?

See how Axiom Studio can transform your AI infrastructure with enterprise-grade governance, security, and cost optimization.

Contact Us