Prompt, skill, workflow, recipe, template, agent: a working taxonomy

Ask five practitioners what a "skill" is and you'll get five answers, three of which describe a prompt. The vocabulary in this space grew by accretion — every vendor coined a term for the artifact their product happened to load — and the result is that people trade tips past each other.

It's worth fixing, because the categories aren't cosmetic. Each one has a different failure mode, a different way of being tested, and a different answer to "why isn't this working?" Here is a taxonomy that holds up in practice.

The distinguishing questions

Three questions separate all six:

1. Who executes the control flow — you, or the model?
2. Is it invoked deliberately, or loaded ambiently?
3. Does it carry files and tools, or only text?

Prompt

One instruction, one turn, you supply the input. The model does the work in a single pass and returns a result.

A prompt is a function call. Its quality is judged by output quality on a fixed input, it is trivially testable, and its characteristic failure is under-specification: you left something in your head.

"You are a ruthless line editor. Cut every word that doesn't earn its place while preserving the author's voice… Text to edit: {…}"

If you can paste it into an empty chat window and get value on the first turn, it's a prompt.

Template

A prompt with holes in it, meant to be filled before use. The distinction from a prompt is that a template is explicitly parameterized — {target_language}, {glossary}, {tone} — and the parameters are the interface.

Templates are what you build when the same task recurs with different settings. Translation with a per-project glossary, an incident report with a per-service escalation path, a code-review pass with a per-repo convention list. The failure mode is a parameter you forgot to expose, so users edit the body and fork it silently.

A good template documents each slot: what goes in it, what happens if you leave it empty, and what a sensible default is.

Recipe

A short, ordered procedure for one tool, where the ordering is the value. A recipe tells a person which buttons to press and which prompts to send in what sequence.

The line against "workflow" is fuzzy in casual use, so here's a sharp one: a recipe is tool-specific and tactical; a workflow is tool-agnostic and strategic. "Refactor with Cursor: pin behavior with a characterization test, commit the test alone, then use Cmd+K for one structural change at a time" is a recipe — move it to another editor and the keystrokes are wrong. The idea survives; the recipe doesn't.

Recipes are the most undervalued category. They encode the thing that's genuinely hard to discover: not what the tool can do, but the order that avoids the pothole.

Workflow

A multi-step process with checkpoints, where you own the control flow. Each step's output is inspected before it feeds the next.

Workflows exist because a single prompt has one chance to be wrong and no chance to be corrected. Splitting the task lets you catch a bad assumption at step one — where it costs a sentence — instead of at step four, where it costs a rewrite.

The tell is a stop: "restate the requirements and wait", "produce the test list and stop". If your document says "then… then… finally" but never asks you to look at anything, it isn't a workflow, it's a long prompt with paragraph breaks.

Characteristic failure: too many steps. Every checkpoint costs attention, and a fourteen-step workflow gets skimmed, which is worse than a four-step one that gets read.

Skill

A packaged capability the model loads on its own when the task calls for it. In the current tooling this is typically a folder with an instruction file — a name, a description of when to use it, and a body — plus, optionally, scripts, reference documents, and templates it can open.

Two properties separate a skill from a prompt, and both matter:

• Ambient invocation. You don't paste a skill. It sits in a directory and the model picks it up when the description matches what you're doing. That makes the description field the most important line in the file — it's the retrieval key, not the marketing copy. "Use when reviewing a diff for security issues before merge" beats "A great security helper" by a wide margin.
• Progressive disclosure. A skill can be larger than its context cost, because the model reads the body only when it's relevant and opens the bundled files only when it needs them.

Characteristic failure: a skill that's really a prompt in a folder — no bundled resources, no trigger discipline — so it either never fires or fires constantly.

Agent

A role definition the model adopts, usually running with its own context and its own tool permissions. In practice, a markdown file with name and description frontmatter and a system prompt as the body, dispatched as a subagent.

An agent is distinguished from a skill by who runs it. A skill augments the current session; an agent gets its own. That's why agents are the right unit for work that would otherwise blow up the main context — read forty files, come back with a paragraph — and for work that should run with narrower permissions than the session has.

Characteristic failure: an agent whose description overlaps three other agents, so dispatch becomes a coin flip. Agents should partition the space, not tile over it.

The cheat sheet

Why the boundaries earn their keep

They tell you what to fix. A prompt that produces mediocre output needs better constraints or an example. A skill that produces mediocre output may have a perfect body and a bad description — it's firing on the wrong tasks, and no amount of editing the instructions will help. Misdiagnosing the category means editing the wrong file for an afternoon.

They tell you how to test. Prompts and templates get a fixed input set. Recipes and workflows get walked end to end on a real task, watching for the step people skip. Skills get tested on invocation first — does it fire when it should, stay quiet when it shouldn't — and only then on output. Agents get tested on the handoff: does the summary it returns actually contain what the caller needed?

They tell you what to publish. A recipe with three obvious steps is not worth a listing. A recipe encoding an ordering constraint that cost you two hours to discover is worth more than most prompts.

Borderline cases, resolved

• "It's a prompt, but I always paste three files with it." — That's a skill trying to be born. Package it.
• "It's a workflow, but the model does every step without stopping." — Then it's a long prompt. Either add real checkpoints or admit it and optimize it as one prompt.
• "It's a skill, but it only ever fires when I name it explicitly." — The description is wrong. Rewrite it as a when, not a what.
• "It's an agent, but it needs the main conversation's context." — Then it shouldn't be an agent. The isolation is the feature; if you need to defeat it, use a skill.

When you submit to the directory, the type you pick is the first thing a reader uses to decide whether your artifact is for them. Picking the honest one is worth more than picking the impressive one.