If I hand a Skill directly to a Subagent, will the two sets of instructions conflict?
No, because they operate at different layers. A Skill defines what steps this type of task should follow — that definition itself is neutral and not tied to a specific execution environment. A Subagent provides the execution space and the scope of tool permissions. When a Subagent uses a Skill, it's simply that independent instance applying those step-by-step instructions within its own context — much like the same recipe can be followed in different kitchens; the recipe doesn't contradict itself just because the kitchen changed.
The thing actually worth watching for is different: a Subagent has its own scope of tool permissions, and if the steps described in a Skill require a tool the Subagent hasn't been granted, the step will get stuck. That's not "the two instructions conflicting" — it's a permission scope mismatch. When designing the setup, confirm the Subagent's tool permissions actually cover what the Skill will need to use.
Why did Anthropic split "knowing how to do it" from "who does it" into two separate mechanisms instead of just building it all into Subagents?
If you hardcoded step-by-step knowledge directly into every Subagent, you'd end up with massive duplication — if several different Subagents all need to follow the same code review standard, you'd have to copy-paste that same content into each Subagent's configuration, and whenever the standard gets updated, you'd have to remember to sync the change across every copy, which makes it easy to miss one.
Extracting the knowledge into a standalone Skill makes it portable: write the standard once, and it can be used by the main conversation, by this Subagent, and by that Subagent too — updating it means changing just one place. This follows the same logic as "don't repeat yourself" in software engineering. Anthropic's own documentation explicitly describes this division as "Skills provide portable expertise, Subagents provide isolated execution space" — it's a deliberately orthogonal design, not layered functionality bolted together.
When would I have a fixed process but not need to package it as a Skill or use a Subagent at all?
If this is something you'll likely only do once or twice in your lifetime, or the process is fixed in principle but the details vary so much each time that it's hard to abstract into generic steps, just stating it clearly in a single prompt might actually be more cost-effective. The value of packaging something as a Skill comes from expecting to reuse it — if there's no expectation of repeated use, the upfront investment in writing a SKILL.md and designing the description's trigger conditions may outweigh the time it saves.
Similarly, if the task doesn't generate much intermediate process and you don't mind it showing up in your main conversation, using a Subagent is overkill — spinning up a separate instance carries its own coordination overhead, and when a task is simple enough that it doesn't need isolation, handling it directly in the main conversation is more straightforward. The test is simple: first ask "will this repeat," then ask "does executing this need isolation." When neither is true, the simplest approach is usually the best one.
I'm a complete beginner — should I learn Skills first or Subagents first?
Start with Skills. The mental model for a Skill is simpler — it's just writing down the steps you keep repeating to Claude, without involving concepts like "separate instance" or "context isolation" that require extra understanding. The learning curve is much lower, and most everyday recurring work (a fixed-format report, a routine data-cleaning process) can be solved with a Skill alone, without needing to reach for a Subagent at all.
The value of a Subagent only really becomes apparent once you actually hit a situation where "the workload is large enough to clutter the main conversation" or "you need to parallelize several independent tasks at once." Rather than learning it just to learn it, get comfortable with Skills first — and once you notice your main conversation getting long and messy because of the noise a particular task generates, that's the natural moment to look into Subagents, rather than trying to learn both systems at once from the start.
You already know what a Skill is — a SKILL.md with fixed steps that applies automatically when the situation matches. After using one for a while, beginners often run into the next question: if I need Claude to do a complex multi-step job and I don't want the process to clutter my current conversation, should I use a Skill or a Subagent? The answer isn't either/or — it's understanding that the two solve different problems in the first place, and most mature setups actually combine them.
A Skill is portable knowledge — it defines what steps or standards a task should follow. A Skill has no execution environment of its own; it runs inside whatever context calls it. If the main conversation invokes it, it runs in the main conversation's context; if a Subagent invokes it, it runs in that Subagent's own context. This is also why the official description calls Skills "portable expertise": the same code review standard can be used by the main conversation or by any Subagent, without writing a separate copy for each execution environment.
A Subagent is a separate Claude instance with its own Context Window and its own tool permissions. It solves an entirely different problem from a Skill: when you need to do something that generates a large volume of intermediate process (combing through dozens of files, running a pile of search commands) but you only care about the final conclusion, handing that off to a Subagent keeps all that noise in the Subagent's own context, without eating into your main conversation's space. This is especially useful when parallelizing multiple independent tasks — for example, auditing the security of four different modules at once, with four Subagents each carrying the same "security audit" Skill, working in parallel without polluting each other's context.
The official documentation states this division of labor plainly: a Skill defines what to do, a Subagent defines who does it and within what isolated scope — the two aren't competing options, they're complementary. A common combination pattern is having a code-review Subagent carry a "language-specific best practices" Skill to run its review, giving you both the Subagent's independence (not polluting the main conversation) and the Skill's portable expertise (the same standard is reusable across other Subagents or the main conversation).
If your question is "what fixed process or standard should this follow," the answer is usually a Skill. If your question is "will executing this generate a lot of intermediate noise I don't want to see, and does it need isolation from the main conversation," the answer is usually a Subagent. If both questions apply — there's a fixed standard AND it needs isolated execution — the answer is using both together: write the standard as a Skill, and have a Subagent carry that Skill while it runs.
Leaving work that should be isolated in your main conversation costs you a main context stuffed with intermediate process, which every subsequent turn then has to carry around as noise it never needed — a real, ongoing Token cost. Conversely, forcing a simple task that doesn't need its own execution environment into a Subagent adds the extra overhead of spinning up a separate instance. The actual money-saving move is thinking through whether a task has a fixed standard and whether it needs isolation before deciding between a Skill, a Subagent, or both together — rather than reflexively reaching for a Subagent every time a task looks complex, or trying to solve everything by writing a Skill.