From Prototype to Production

What Changes at Scale

Nothing about the SKILL.md format changes between a skill you wrote for yourself last night and a skill three thousand people at your company rely on tomorrow. The file format is identical. What changes is everything around it: who wrote it, who can change it, who tests it, what happens when it’s wrong, and how anyone finds out it exists in the first place.

A personal skill fails safely — you notice, you fix it, nobody else was affected. A production skill failing silently for a week before anyone catches it is a fundamentally different kind of risk, and it’s the reason this course exists. Concretely, production changes five things about a skill that a beginner course doesn’t need to cover:

• Authorship becomes a team activity, not a single person’s judgment call — which means a skill needs to be reviewable by someone who didn’t write it.
• Failure has to be engineered, not discovered — retries, fallbacks, and validation stop being nice-to-haves once a skill runs unattended at volume (lesson: Skill Engineering).
• Quality has to be measurable, not just “it worked when I tried it” — a real evaluation practice replaces a few manual tries (lesson: Testing and Evaluation at Scale).
• Trust has to be explicit, not assumed — who can publish a skill, what it’s allowed to touch, and how a supply-chain risk gets caught before it ships (lesson: Security and Governance).
• Change has to be tracked, not silent — a skill used by many consumers can’t just be edited in place the way a personal one can (lesson: Skill Lifecycle and Versioning).

Every remaining lesson in this course is really just one of those five ideas, engineered properly.

Four Words People Use Interchangeably (and Shouldn’t)

Before any of that, there’s a vocabulary problem worth fixing first: Skill, Tool, MCP, and Agent get used almost interchangeably in casual conversation, and that looseness causes real design mistakes — teams build a Tool where they needed a Skill, or an Agent where a Skill would have been enough. Here’s the precise distinction.

Tool

A tool is a single function call with a defined interface: a name, a description, and a parameter schema. search_flights(origin, destination, month) is a tool. A tool does exactly one thing, takes structured input, and returns structured output. It has no opinion about when it should be used or how to sequence it with other actions — that judgment lives entirely outside the tool, in whatever calls it.

MCP (Model Context Protocol)

MCP is a transport and connection standard — a way for an agent to discover and call tools (and read resources) exposed by an external server, over a standard protocol, regardless of what language that server is written in or where it runs. An MCP server is fundamentally a tool provider: it exposes one or more tools (and sometimes resources or prompts) through a consistent interface, so an agent doesn’t need custom integration code per server. MCP answers “how does an agent reach a tool that isn’t built into it?” — it does not, by itself, tell the agent when to use that tool or how to approach a class of problem.

Skill

A skill is procedural knowledge — instructions, not a callable function. It tells an agent how to approach a task, potentially using tools (including ones reached over MCP) as part of doing so. Where a tool has a rigid interface, a skill has a body of Markdown the agent reads and follows with judgment. A skill can call zero tools (pure instructions), one tool, or orchestrate several — the skill’s job is to supply expertise about when and how, not to be the mechanism of action itself.

Agent

An agent is the thing making decisions — the loop that observes, reasons, and acts, deciding at each step which skill’s instructions apply and which tool to call to execute them. Skills and tools are resources an agent draws on; the agent is the actor doing the drawing.

Making the Distinction Concrete

A common design mistake: writing a skill when what’s actually needed is a tool — cramming a rigid, deterministic operation (“convert this exact JSON schema to this exact CSV format, byte for byte”) into instructions an agent has to interpret with judgment every time, when a small script or MCP-exposed function would do it identically and more cheaply every time. The reverse mistake also happens: building a narrow, single-purpose tool for something that’s actually a judgment call (“decide whether this expense report needs manager approval”) — a decision that depends on context, exceptions, and edge cases a rigid function can’t hold, and that a skill’s instructions are much better suited to carry.

A rule of thumb that resolves most of these arguments: if the operation has one correct output for a given input, every time, it’s a tool. If it requires judgment, context, or a policy that has exceptions, it’s a skill — and the skill’s instructions should tell the agent which tools to reach for along the way.

Where This Course Sits

You’ll come back to this exact vocabulary in Where Skills Fit: Agent Architecture, where these four pieces get placed into a full pipeline diagram together. For now, the goal is just precision: when someone on your team says “let’s build a skill for this,” you should be able to ask, correctly, whether they actually mean a skill, a tool, or both.

Summary

• The SKILL.md format doesn’t change between personal and production use — everything around it does: authorship, failure handling, measurable quality, explicit trust, and tracked change
• A tool is a single, rigid, callable function
• MCP is the protocol an agent uses to reach tools (and resources) exposed by an external server
• A skill is procedural, judgment-driven instructions that may use one or more tools along the way
• An agent is the decision-making loop that draws on skills and tools to get something done
• The fastest way to misdesign a system is to build a skill where a tool belongs, or a tool where a skill belongs — the deciding question is whether the task has one correct output every time, or requires judgment

Next, you’ll learn the vocabulary for how a skill is written — six recurring design patterns that cover the overwhelming majority of what skills actually need to do.