The four types of AI skill, and how to build each one

Two things get called a "Claude skill" today, and they generally aren't close to the same thing.

One is a saved prompt with a tidy label, rebuilt in 10 minutes if it were deleted. The other is a system that interviews its owner, keeps its own memory, runs on its own, and improves over time without being asked.

Most people building skills cannot see the range between those two extremes, so they make one of two mistakes.

Both mistakes come from the same gap: no map of the different types of Skills.

There are four, and each one is a real jump in what the skill can do. The rest of this piece walks through them with one consistent example per function, so the same job can be seen getting more capable as it climbs. Before that, four dimensions are worth understanding because they shape each build decision.

A skill is close to an agent, just pitched at a slightly more abstracted layer. The same questions apply, and the way I think about it, four of them matter most when deciding what to build.

One more thing runs through all four types rather than belonging to any single one: thinking. Every skill reasons before it acts, and the harder builds simply give that reasoning more to work with, more memory, more tools, more reach. With those four dimensions in mind, here are the four types.

This list isn't meant as exhaustive, but as a guide for any working to understand how they can use Skills.

Each type is shown through one running example per function: a sales deal, a marketing campaign, and an operations incident. The same job appears at every rung, doing more each time. The four, from simplest to most serious:

There is also a pattern in how they get built. The first two are finished in one sitting, whereas the last two are not so much built as grown: a rough first version, then weeks of testing and correction before they are worth trusting.

The simplest type is a single instruction with a good description wrapped around it. No memory, no files, no tools. The operator supplies the input, and the packaged instruction does the rest.

Two things make even this simplest type more than a saved prompt.

This makes the description the most important part of the skill. A skill with a vague description never gets picked, so it sits unused while the users solves the same problem by hand, unaware the skill was there. About 10 minutes to build, and the payoff is a reliable instruction that triggers itself. Its signature is that it behaves the same on the first run and the thousandth, because it has no memory to change (until models change and prompt drift kicks on, altering the expected result). Most skills sit in this bucket, which is fine, because it is a shortcut rather than a system. The only mistake is confusing this with an agentic workflow.

The second type works with information rather than just words. It reads the operator's own files, writes new files that persist, and searches the web for what it does not already have.

This is a real jump, but the hard part is not reading, writing, or searching on their own. It is feeding the skill the right information and nothing else. An AI has a limited working memory, and the fastest way to ruin its answer is to dump everything at it (see more on what context rot is to understand how outputs degrade as a context window clogs), dozens of documents the length of novels, and hope it finds the point. A good Type 2 skill is told where it can look and what it can grab: this account's record, not the whole CRM; the current brand guide, not last year's; the one runbook for this fault, not the entire library.

The payoff is a grounded, durable output: answers built on the actual deal and the actual incident, left behind as files other people and the next run can pick up. The clearest sign a skill has reached Type 2 is that it can refuse, stopping to ask for a missing input rather than guessing.

Still, it has no memory between runs. The second debrief on the same buyer does not know the first one happened. It produces good work and forgets it the moment it finishes.

The third type stops being something that only handles information and starts doing things inside other systems. It reaches into the tools a business already runs and acts in them.

The capability that defines this type is access to real tools, often through something called MCP, a standard way to plug an AI into outside systems so it can act in them rather than just talk about them. The reason to use it is simple. The moment a job needs the skill to touch a real system, a billing platform, a calendar, a database, MCP is how it reaches that system safely instead of the operator copying data back and forth by hand.

Using tools well depends on a couple of things because two kinds of work exist in any job.

So a Type 3 skill does not ask Claude to do the exact parts. It calls a tool that does them (often using code and a script), and Claude just reads the result. Judgement decides what to do; the tools (or scripts) do the parts that have to be precise.

This is also the first type built by iteration rather than in one pass. The first version is a rough draft of the flow, and the real one emerges after running it on messy inputs and fixing what breaks. The payoff is a job that used to take an afternoon, done in minutes and the same way every time. The trap is letting Claude do the exact work in its head when that work belongs in a tool.

The fourth type stops being a skill the operator runs and becomes a system that runs itself and remembers. Three parts make it work: a setup interview that captures how the operator works, a running log of everything it sees, and a background agent that acts on that log without being asked.

This is the type where "runs on its own" deserves a plain explanation, because it sounds like magic and is not. A skill runs autonomously in one of two ways.

Either way, a background version of the skill is set running once, and from then on it works without a human starting it each time.

The capability that no lower type has is memory that compounds. It does not just give a better answer each time, it becomes a better system each time, because it holds a history of its own work and improves on the back of it. The plainest test is whether the second time the operator corrects it for the same thing, it should have already learned. Tell it once that a warning does not apply to a certain kind of deal, and it stops raising it. A lower type forgets the correction the moment the run ends whereas a practice keeps it.

This type takes weeks to stand up and is never truly finished, earning its value slowly as the log fills and the agent starts catching real patterns. It is the only payoff on the map that grows, worth more after months of history than on the day it launches.

Anthropic's commercial-legal plugin is the clearest public example: a setup interview writes the firm's playbook, a background agent surfaces contracts that broke from it, and a second agent proposes updates once a pattern is clear. The legal team did not build a skill, they built a category. The same shape scales as a team wires one person's practice across a whole team, sharing one profile and one set of connections, and it becomes a platform owned and maintained like a product. That is a job for an AI engineer, not an individual, but it is the same idea at company scale.

Review the four types and the pattern shows itseld.

So before building the next skill, place the job on the map first. Read it on the four dimensions, be honest about how much it needs to remember, and match the type to the job rather than to the excitement of building something clever. A Type 1 dressed up as a system wastes a weekend. A Type 4 job left at Type 2 leaves a year of compounding on the table. Pick one skill that already exists and place it on the map to name its type, name the one dimension holding it back, and decide whether the job actually needs it to climb.