Prompt, Skill, Agent, Plugin: You're Probably Asking the Wrong Question

These four aren't a menu you pick one item from. They're layers that stack — and once you see that, "which should I use?" mostly answers itself.

When people start building with AI beyond the chat box, they hit a fork that feels like a decision: Should this be a skill or an agent? Do I need a plugin, or is a good prompt enough? It feels like choosing one tool out of a drawer.

It isn't. Prompts, skills, agents, and plugins aren't four competing options — they're four layers, and they compose. A plugin bundles skills. A skill can delegate to agents. An agent, underneath, runs a prompt. Once you stop treating them as alternatives and start seeing them as a stack, the question changes from "which one?" to "which layer am I working at?" — and that one you can actually answer.

The four, plainly

A chat prompt is a single instruction in a conversation. It's the fastest, cheapest, most flexible thing you can do — and it evaporates when the conversation ends. That's a feature: most of what you ask an AI is genuinely one-off.

A skill is a prompt you've promoted to a named, reusable procedure. Write your code-review checklist down once, and the AI pulls it in when the moment calls for it — loaded only when relevant, so you can have dozens installed and pay full freight only for the one in play. A skill codifies how to do a recurring task so it comes out consistent every time.

An agent is a separate worker you hand a job to. It runs in its own context, does the work, and reports back a result — you never see its scratch paper. Reach for one when you need isolation (a big read you don't want cluttering your main thread), parallelism (fan out ten workers), or a bounded role (a reader you've scoped to look but not touch). A skill is what procedure to follow; an agent is who does the work, and in whose context.

A plugin is the shipping container — skills, agents, commands, and config bundled into one versioned, installable unit. Build one when you have a coherent set of capabilities to install once and keep in sync.

One task, all four layers

Take reviewing a pull request.

The first time, you just ask: "review this diff for bugs." A prompt. It works, you move on, it's gone. Right call — you'll never run that exact review again.

By the tenth PR you're tired of re-typing what "review" means to you — check the error handling, flag the untested paths, don't nag about formatting. So you write that down once as a skill. Now "review this PR" pulls in your checklist automatically, and every review comes out the same shape. Same task, promoted a layer.

Then a 4,000-line PR lands. You don't want that whole diff sitting in your main thread — you'd pay to re-read it every turn for the rest of the session. So your review skill hands the heavy read to an agent: it reads the entire diff in its own context and passes back a one-paragraph list of problems. The diff dies with the agent; only the findings come home. Notice you're now running a skill and an agent on a single task — that's the "skill or agent?" question dissolving in real time. The skill is the procedure; the agent is the worker it delegated the heavy part to.

Finally your team wants your review flow too. You bundle the skill, the reader agent, and a /review command into a plugin, push it, and everyone's on the same reviewer by lunch.

One task. Four layers — each entered when the job actually called for it, not picked off a menu.

The two axes that actually decide it

1. Codification — how permanent? It slides from one-off (prompt) up through reusable procedure (skill) to versioned bundle (plugin).
2. Execution locus — where does it run? Main conversation (prompt/skill) or an isolated worker (agent)?

That's it. Codification tells you how far to promote the instruction; execution locus tells you where the work runs. The two are independent — which is exactly why "skill or agent?" is a false choice.

It's also a cost decision

The bill for AI is tokens, and tokens are compute you pay for on every turn — electricity, and in a lot of data centers, cooling water too. So every one of these choices is quietly an efficiency choice (and, at scale, a small environmental one).

• Reaching for an agent is often a context decision. A long-running assistant re-reads its whole conversation every turn, so a big blob you pull into the main thread gets paid for again and again. Delegate the heavy read to an agent, and the bulk dies in its throwaway context — only the small answer comes back.
• Skills + load-only-when-relevant let you keep a big toolkit on hand for a tiny fixed idle cost — the weight loads only when a skill actually fires.
• Plugins save you from re-deriving your setup every time you start fresh.

The rule of thumb

• Will I do this again? No → prompt. Yes → skill.
• Is the work too big, parallel, or risky to run in the main thread? → agent.
• Ready to hand it to others (or future me)? → plugin.

The layers compose. The skill of building with AI isn't picking the right box — it's knowing which layer you're standing on.

FAQ

Skill or agent — which should I use?
Usually both. A skill is the reusable procedure (what to do); an agent is an isolated worker (who does it, and in whose context). Most real tasks use a skill that delegates to an agent.

When is a plain prompt enough?
When you won't do it again. For a genuine one-off, a prompt is the fastest, cheapest option — promote it to a skill only once it recurs.

When do I actually need a plugin?
When you have a coherent set of skills, agents, and commands to install once and keep in sync — especially to share with a team or your future self.