Claude Skills vs Subagents: 70-Skill Decision Tree

Two months into building my studio’s agent stack, I hit a wall. Thirty-four skills in, every new task landed on the same question: skill, or subagent? I kept picking wrong. A competitor teardown skill leaked context so hard my main session went brain-dead after three calls. Rebuilt as a subagent in an afternoon. The reverse happened too. I subagented a monthly task with clear steps, and every time I ran it I had to re-remember the invocation.

By skill #70, I had a decision tree I trust. Three questions. Works across event production, cold outreach, video breakdowns, quote drafts, and a dozen other jobs I used to hand-hold.

Here’s the tree, plus three real examples where I got it right or wrong.

What each one actually is

Skills are procedures with an owner. You write a SKILL.md (plus supporting files) that tells Claude how to handle a recurring task like a cold email sprint, quote draft, or video teardown. Claude auto-loads it when the trigger fires. Lives in main context.

Subagents are Claude instances you spawn with a fresh context window. Hand one a task, it works in isolation, returns a summary. Your main session sees only the final report, never the raw work. Perfect for heavy jobs (reading 30 files, crawling a repo, batch processing) that would blow your primary context inline.

Plugins are packaged capabilities you install once and get everywhere. MCP servers, hooks, shared skills that stick around across every session and project. Think OS layer. Not invoked per task; always available.

These aren’t competing tiers. Different axes. One workflow can involve all three: a plugin exposes an MCP tool, a skill orchestrates a procedure using it, one step dispatches a subagent for a heavy read.

The decision tree

Three questions, in order. Stop at the first yes.

1. Is this a persistent capability I want in every session on every project? Plugin. A Notion MCP server. A git hook that lints commit messages. A shared skill library. If it’s not “when this task comes up I want this” but “this should always be there,” it’s plugin territory.

2. Is this a repeated procedure with clear triggers and steps, that fits in main context without eating it alive? Skill. Triggers like “quote this client,” “draft a cold email batch,” “run a video breakdown.” Anything I do more than once a month with a discoverable pattern. Cheap to write, easy to update, and they compose. One skill can dispatch another.

3. Is this a one-shot heavy task that needs isolation, batch work, or would pollute main context? Subagent. Reading 40 files for one answer. Crawling a competitor’s site. Processing a folder of raw footage. Anything where the work is much bigger than the answer.

If none fit, the task doesn’t need special treatment. Do it inline.

Two rules I use daily:

• Between skill and subagent, pick subagent first. Failure cost is lower. A bad subagent wastes tokens; a bad skill pollutes every future session that trips its trigger.
• Between skill and plugin, pick skill. Plugins are heavier to change; skills you edit in a minute.

Example 1: Skill over subagent (right call)

Quote drafts. Clients ping me on LINE with “hey, can you quote a two-day shoot in Taichung for a dental clinic?” Eight to twelve times a week. Same shape every time: pull the rate card, check my hourly-rate floor, draft a reply in my voice, flag anything that needs my judgment before I hit send.

I built it as a subagent first, because the pricing logic felt “heavy.” Wrong instinct. Actual work was maybe 30 seconds of Claude time. What I needed was consistency (my voice, hourly-rate rules, the “always add a specific example in parentheses” quirk) and low friction: say “quote this” and go. Subagent invocation was too ceremonial for something this frequent.

Rebuilt as a skill in about 40 minutes. Triggers: “quote,” “draft a reply,” “help me price this.” Auto-loads voice rules, hourly-rate floor, one-page rate card. I fire off a quote in the same conversation where the client message came in, no context switch. Ten times faster, and drafts got more consistent because the skill enforces rules I kept forgetting to hand-write (no CTA at the end, use “we” with clients).

Example 2: Subagent was right

Video breakdowns. A client sends me a competitor’s IG Reel and asks “can we make something like this?” To answer well I download the video, split it into shots, extract keyframes, run color analysis, transcribe audio, then have Claude write per-shot descriptions and reverse-engineered prompts.

That’s a lot of file-reading, tool-calling, and image analysis. Inline, my main context would be 60% consumed by keyframe base64 blobs and shot metadata before I got to the analysis. Every follow-up in that session would then be slower and dumber.

Subagent, obvious. I dispatch with the URL, it works in isolation for two to five minutes, and returns a clean summary: shot breakdown, color palette, reverse-engineered prompt structure. Main session sees only the summary. Wrong breakdown? Re-dispatch with a corrected brief. Right? Straight to the creative response.

Rule of thumb: if the workspace is much bigger than the answer, subagent. If workspace and answer are roughly the same size, skill or inline.

Example 3: Mistakenly used skill (and paid for it)

Early on I built a “competitor teardown” skill. Give Claude a URL, have the skill fetch the site, extract positioning, pricing, and content strategy, then write a one-page summary. Fit the “repeated procedure” test cleanly.

Problem: every teardown pulled in 15 to 40 KB of raw HTML, product page text, and screenshots. All of it landed in my main context because that’s where skills execute. After three teardowns in one session, context was 40% eaten and unrelated conversations felt sluggish. Claude was forgetting things I’d said two turns ago.

The task fit the skill shape (repeated, clear steps) but violated the “fits in main context” clause. Rebuilt as a subagent. Raw scrape now lives in the subagent’s isolated context; main session sees only the structured teardown. Same UX from my side (I still just say “tear down this competitor”), context stays clean.

Lesson: “repeated procedure” is necessary but not sufficient for skill. If the procedure eats context, subagent it.

Where to go from here

Want to see these decisions in real code? Browse the claude-code-skill-stack repo. Four production skills from my studio with the exact structure above. Star it to track updates.

Starting from zero and want a template with folder structure, trigger patterns, and safety rails baked in? Fork claude-skill-starter. Same skeleton I use for every new skill.

Skills are the third layer of the Solo Stack Method. Signal decides what to work on, Strategy decides how, Skill is where you encode the how so you don’t rebuild it every time. Subagents and plugins are supporting infrastructure. The tree above is how I decide which layer catches which piece of work.

FAQ

When should I use a Claude subagent? One-shot heavy jobs, tasks needing isolated context (batch processing, deep research, many files), or when raw work would pollute your main session. Also good for anything you want running in the background while your main conversation continues. Bad fit for high-frequency tasks with fast turnaround, where invocation overhead becomes friction you’ll route around.

Can skills dispatch subagents? Yes, and this is where the architecture gets powerful. A skill encodes the “when and how” (triggers, prompt shape, output format) while offloading heavy work to a subagent. My video breakdown skill does exactly this: skill as orchestrator, subagent as worker. Consistency of a skill with the context isolation of a subagent.

What’s the difference between a skill and a plugin? Skills are per-project procedures that auto-load when triggered. Plugins are persistent capabilities across every session and project: MCP tools, hooks, shared skill libraries. Only need it in my studio’s work? Skill. Want it everywhere I open Claude Code? Plugin. Scope, not power.

Do I need all three to build a serious agent stack? Not to start. My first 20 skills got me to double throughput with zero subagents or plugins. I added subagents around skill #25 when context bloat became real. Plugins came later, mostly for MCP servers I wanted across projects. Start with skills, add subagents when a skill starts eating context, reach for plugins only when a capability needs to travel across projects.