Yes. A Claude Code subagent can use skills, and Anthropic now says so in plain language. The skills-explained post puts it directly: "In Claude Code and the Agent SDK, subagents can access and use Skills just like the main agent" (claude.com/blog/skills-explained). So if you came here to settle a bet, that is the answer. The part worth your time is how the two compose, because there are two distinct wiring patterns and people keep conflating them.
I want to set the conceptual split first, because most of the confusion about claude skills and subagents comes from treating them as competitors when they are not.
A skill is a job. A subagent is a worker.
A skill is a reusable job definition: a SKILL.md file holding instructions, a checklist, or a multi-step procedure that Claude loads only when it is relevant. You write the deploy steps once, and any agent that needs them pulls them in. If you want the full definition, I wrote it up separately in what is a Claude skill.
A subagent is an isolated worker. It runs in its own context window with its own system prompt, its own tool access, and its own permissions, and rather than dumping logs into your main conversation it hands back a summary (code.claude.com/docs/en/sub-agents). The point of a subagent is context hygiene and constrained permissions. The basics of running one are covered in how to use subagents in Claude Code, and defining a reusable one lives in Claude Code custom subagents.
Here is the analogy I keep coming back to. The skill is the recipe. The subagent is the cook you send off to a separate kitchen so they don't splatter sauce all over your counter. You can hand the same recipe to any cook, while the cook stays a fixed role you keep rehiring.
Can Claude subagents use skills they did not inherit?
This is the question that trips people up, and the honest answer has a wrinkle in it.
A subagent does not inherit your live session. It "does not see your conversation history, the skills you've already invoked, or the files Claude has already read" (code.claude.com/docs/en/sub-agents). So in the sense people usually mean, "do subagents inherit skills" from the parent turn, the answer is no. It starts fresh.
Starting fresh does not mean starting blind, though. By default the subagent can still discover and invoke project, user, and plugin skills through the Skill tool during its own run. The docs are explicit that the skills frontmatter field "controls which skills are preloaded, not which skills the subagent can access: without it, the subagent can still discover and invoke project, user, and plugin skills through the Skill tool during execution" (code.claude.com/docs/en/sub-agents). If you want a subagent that genuinely cannot touch skills, you remove Skill from its tools list or add it to disallowedTools. So the available skills follow the agent even though the invoked ones do not, and that one distinction is most of the answer.
Two ways to combine skills and subagents
There are exactly two supported directions, and they run inverse to each other.
The first is a subagent that uses skills as reference material. You define a custom subagent and give it a skills: field, which injects the full skill content into that subagent's context at startup (code.claude.com/docs/en/sub-agents). The example Anthropic ships is a python-developer subagent that uses a pandas-analysis skill to reshape data following your team's conventions (claude.com/blog/skills-explained). The subagent owns the system prompt and the role, and the skill supplies the portable procedure that drops into it.
The second direction runs the skill itself inside a forked subagent. Add context: fork to a skill's frontmatter and the skill content becomes the prompt that drives a subagent, with the agent type you name supplying the tools and system prompt (code.claude.com/docs/en/skills). A research skill with agent: Explore runs in a read-only Explore agent and sees only the SKILL.md content plus that agent's own prompt, skipping CLAUDE.md to stay small. The machinery underneath is the same in both cases, and only the direction of control flips: with the skills field the subagent loads the skill, and with context: fork the skill spawns the subagent.
One caveat from the docs will save you a confused afternoon. context: fork only works for skills that contain an actual task. A skill that is pure guidelines ("use these API conventions") with no instruction hands the subagent a reference sheet and no job, so it returns nothing useful (code.claude.com/docs/en/skills).
When the pairing earns its keep
Reach for both when you have a procedure that more than one worker needs and a worker whose context you want walled off. Security review is the canonical case. Write the review steps as a skill so every agent applies the same checks, then run them in a code-review subagent so the diff, the grep results, and the whole chain of reasoning stay out of your main thread. You get the portable procedure and the isolation in a single move.
Anthropic frames the choice the same way. If multiple agents need the same expertise, build a skill instead of baking the knowledge into each subagent, because skills are portable and reusable where subagents are purpose-built (claude.com/blog/skills-explained).
Now the part nobody really says out loud: most of the time you do not need both.
If you just want a repeatable procedure in your normal conversation, a plain skill is enough, and wrapping it in a subagent only buys you a fresh context window you did not ask for. If you just want a side task done without flooding your thread, a bare subagent with a good description works fine on its own. The pairing pays off at one specific intersection, where you have a procedure that is genuinely reused across workers plus a real reason to isolate context or clamp down tool permissions. Below that bar you are adding a layer of indirection for the aesthetic of having done it, and you should skip it.
The skill is the thing worth investing in, because it is the unit that travels. That same SKILL.md runs in your main session, in a subagent, in Claude Code, and in the other tools that read the open Agent Skills format. That portability is exactly why we built Knack: you answer a short interview, and it produces a real SKILL.md folder that any agent, subagent included, can run. Write the job once, and decide later which worker does it.