IndyDevDan — I finally CRACKED Claude Agent Skills (Breakdown For Engineers) (Transcript)
Source: https://www.youtube.com/watch?v=kFpLzCVLA20 Title: I finally CRACKED Claude Agent Skills (Breakdown For Engineers) Channel: IndyDevDan Duration: 27m 13s Published: 2025-10-27
For the past week, I’ve been working through agent skill issues. Now you have agent skills, sub-agents, custom slash commands, output styles, plugins, hooks, memory files, and MCP servers. What is this all for?
I’ve been using Claude Code since it was first available in February. Since its release, I’ve generated more code than in my previous 15 years as an engineer. This tool has changed engineering. But this once simple tool has gotten complex over the year. So let’s simplify it. Skills are simple, but they’re so similar to MCP, sub-agents, and custom slash commands, it’s hard to know when to use a skill. There’s a right way to think about skills, and there’s a wrong way. I want to show you both to make it absolutely clear what this feature can do for your engineering. Skills are powerful, but you should not always build a skill.
Let’s first look at the wrong way to use skills to solve an engineering problem. Here we have a skill on the left, a sub-agent in the middle, and a custom slash command on the right. If you’re parallel agent decoding, generating multiple solutions at the same time, you’ve likely created Git worktrees. Here’s a question: which one of these three ways is the right way to create your Git worktrees or manage your Git worktrees?
To answer this, we need to understand how these features really differ. Let’s start with the three most important capabilities. Skills stand out right away because they’re triggered by your agents. If you give your agent some direction, they will trigger the right skill. Sub-agents are very similar in this way — unlike slash commands where you’re explicitly kicking this off. We then have context efficiency. This is a huge selling point of skills. Unlike MCP servers, which explode your context window on bootup, skills are very context efficient. They have three levels of progressive disclosure: the metadata level, the actual instructions of your skill.md file, and then all of the resources that your agent pulls in from your skill when it needs. The last thing here is context persistence. The only loser here is sub-agents — but of course, this is what makes sub-agents great. Sub-agents isolate and protect your context window.
Shareability is not that important. You can use Git, you can use plugins, you can share these. Sub-agents are the big winner if you’re looking to parallelize your workflows. You would think that specialized ability is unique to skills. It’s not. You can specialize any one of these features. And of course, you can share all of these any way you want.
Now what is important is modularity. This truly differentiates skills. Skills are just like MCP servers in that you have a dedicated solution. It’s even more modular than MCP servers, frankly, because skills have a dedicated directory structure. The most important thing here is that we have a dedicated structure for building out repeat solutions that our agent can invoke. That is the primary benefit of skills. The modularity here is really important. Unlike sub-agents and slash commands, where you kind of had to roll this capability out yourself.
And then things get interesting at the last level, where we start thinking about composition. This is where I think a lot of the confusion comes when we talk about skills, MCP servers, sub-agents, and slash commands. Specifically, skills and slash commands are very, very composable. In fact, you can circularly compose all of these items together, minus sub-agents — because a sub-agent cannot use a sub-agent. But when it comes to skills: skills can use prompts, skills can use other skills, skills can use MCP servers, and of course, skills can use sub-agents.
So this is the feature breakdown. There’s a ton of overlap. This is important to call out. It’s the approach that’s new — we get a dedicated modular directory structure, efficient context (which we had with sub-agents), but these are triggered by our agents. So this is the distinguishing pattern of when you would use a skill over MCP, sub-agent, and slash command.
Let’s look at some dedicated, specific use cases. Skills are truly for automatic behavior. MCP is built for external integrations. Sub-agents for isolated workflows that you can also parallelize. Slash commands are manual triggers — manual units of compute that you can deploy when you need them. The big battle I see is between skills and slash commands.
Use cases:
- “Automatically extract text and data from PDFs” → keyword “automatic” → skill.
- “Connect to Jira” → external source → MCP server.
- “Run a comprehensive security audit” → tricky, but you want this to be able to scale, you don’t really need this in your context window, and you don’t want this to be automatic — you want it at a specific point in time → sub-agent.
- “Generalized Git commit messages” → simple one-step task → slash command.
- “Querying your database” → classic MCP.
- “Fix any bugs and failing tests at scale” → throw inside a sub-agent.
- “Detect style guide violations” → repeat behavior, encoded → skill.
- “Fetch real-time weather data from APIs” → MCP, third-party service.
- “Create a component” → simple one-off task → slash command.
Whenever you see “parallel,” just jump to sub-agents. Nothing else supports parallel calling.
What’s more confusing is skills versus slash commands. Skills versus MCP is very distinct. Skills can use MCP servers, you can compose everything into a skill, but you can also compose everything into a slash command. The only exception between slash commands and skills is the modularity and who is triggering it.
There are a lot of engineers right now that are going all in on skills. They’re converting all their slash commands to skills. I think that’s a huge mistake. I see slash commands as the primitive of agent coding, of AI coding, and really of language models. So you want to be very careful to get rid of your prompts.
Our agents use the prompt, sub-agent, and skill to do the exact same work. This is the wrong way to think about skills. If you can do the job with a sub-agent or a custom slash command, and it’s a one-off job, do not use a skill. This is not what skills are for.
In engineering, you don’t want many ways to do the same thing. You want one dedicated way to get the job done. So this is getting confusing. Claude Code is becoming a larger and larger tool. Successful things tend to grow, and at some point, it loses its originality. I don’t think Claude Code is there. I like this feature. I think it’s a net positive for the ecosystem.
Remember, I asked: what’s the right way to create a Git worktree? Very clearly, you can do this in three distinct ways. The true answer is you probably want a prompt to create a Git worktree. Unless you need to create many of these, we don’t need to parallelize. But if you do need to parallelize, use a sub-agent. That’s a perfect branching point to go from custom slash commands to sub-agents. If you need to parallelize, you can take your existing custom slash command and throw it in a sub-agent.
If you actually dial into this sub-agent prompt, you can see I’m having the sub-agent compose a prompt with the slash command tool. It is calling our prompt. So we’re starting to get into a composability chain — the base level unit being a prompt, aka a custom slash command. And in our skill, guess what we’re doing? Instructions: use the slash command tool. So here we are looking at the prompt as the primitive for all the existing features.
I’ve been saying this for years, ever since the generative AI revolution kicked off: do not give away the prompt. The prompt is the fundamental unit of knowledge work and of programming. If you don’t know how to build and manage prompts, you will lose. Why? Everything comes down to just four pieces now. There are four pieces of agentic coding: context, model, prompt, and tool. If you understand these, if you can build and manage these, you will win. Every agent is the Core 4, and every feature that every one of these agentic coding tools is going to build is going to build directly on the Core 4.
This is why it’s so important to always lead with a custom slash command. When you’re starting out, I always recommend you just build a prompt. Don’t build a skill. Don’t build a sub-agent. Don’t build an MCP server. Keep it simple. Build a prompt. Everything is a prompt in the end. Tokens in, tokens out. If we want to parallelize, we can go to sub-agent. Now, when do we go to a skill? This is the critical question.
For creating Git worktrees, we can easily use just a prompt. One prompt solves the problem. But if we want to solve the problem of managing our Git worktrees — because dealing with Git worktrees isn’t just about creating them — we need a skill. We need a skill to manage our Git worktrees. This is where one prompt is not enough. You want to scale it into a reusable solution. We need a skill. This is what skills were built for: reusable file-system-based resources, Claude domain-specific expertise, workflow context, best practices, into specialists. This is what skills are all about. Skills offer a dedicated solution, an opinionated structure on how to solve repeat problems in an agent-first way.
We have a worktree manager skill. Much more built out. We can do something like “list skills.” We have a meta skill and a video processor skill. Four available skills. This is the right way to think about skills. We have a skill that is a manager of a specific problem set — a repeat solution for a specific problem. If we actually just needed to create worktrees, /create-worktree, and we’re done. Give the branch, give the additional details to make the branch unique, set up environment variables, set up the right client/server ports — done, one-off. But if we need to manage multiple elements, stop manually prompting this, stop firing off these custom slash commands by yourself. Really dial in and build a skill.
So I’m going to say “pull back up our trees, and let’s manage these now.” Manage Git worktrees, remove red tree, create purple tree with offset 4, list our trees. This is a skill set. We have solved the problem of managing our Git worktrees with a dedicated skill.
Let’s look at some definitions:
- Agent skills: package custom expertise that your agent autonomously applies to your recurring workflows.
- MCP servers: connect your agent to external tools and data sources. Very little overlap between agent skills and MCP servers — these are fully distinct.
- Composition hierarchy: skills can have many MCP servers, many sub-agents, many custom slash commands. An MCP server is a lower-level unit — you wouldn’t have an MCP server use a skill. There’s a chain of command. A slash command is a super-primitive that acts as both a primitive and a composition.
- Sub-agents: delegate isolatable specialized tasks with separate contexts that can work in parallel. Use when you want work out of your primary agent’s context window, you can delegate it, and you don’t care that you’re going to lose the context at the end.
- Custom slash commands: reusable prompt shortcuts that you invoke manually. I’m definitely underselling these. If you had to pick one, prioritize your mastery of custom slash commands. Why? Because this is the closest compositional unit to bare-metal agent + LLM. You’re passing in a user prompt. You must master the prompt. There are no exceptions. If you avoid understanding how to write great prompts in a repeatable way, you will not progress as an agentic engineer in 2025, 2026, and beyond. The prompt is the fundamental unit of knowledge work now.
- Hooks: deterministic automation that executes commands at specific lifecycle events. We balance — push outside of the agents to ADWs (AI Developer Workflows) where you combine the old world of code with the new world of agents.
- Plugins: package and distribute these sets of work. Just a way to share and reuse Claude Code extensions.
- Output styles: I’m using these 24/7. When my agent finishes work, it summarizes using a text-to-speech output style. I have observable tools, diff, text-to-speech summary.
Have a strong bias toward slash commands. When you’re thinking about composing many slash commands, sub-agents, or MCPs, think about putting them in a skill. But your skills should still have a slew of slash commands inside.
Pros and cons of agent skills:
Pros:
- Agent invoked — we want to lean into the autonomy.
- Context protection — incremental context window adoption (progressive disclosure). Unlike MCP servers, which straight up torture the context window.
- Dedicated isolated file-system pattern — we can now logically compose and group our skills together. Easy to write, update, create, modify, and distribute what your agents can do.
- Can compose other features.
- The agentic approach. Agent just does the right thing.
Cons:
- It doesn’t go all the way. I can’t nest sub-agents, and I can’t nest my prompts. Why not? Inside of my bundle (my file-system VM for my skill), where is my slash commands directory? Where is my agents directory? Why didn’t the Claude Code team go all the way here? If you’re making this the bundle for repeatable solutions, why can’t I embed prompts — the most important feature out of any one of these agents? Don’t let anyone confuse you with these feature releases. Prompts are the most important thing of all.
- Reliability is going to be an interesting one. Will the agent actually use the right skills when chained? Individually it’s less concerning, but when you stack these up — and this is one of the key features they mentioned, “compose capabilities, combine skills” — how reliable is that? Can I actually deploy that into production? Can I actually chain together five skills and expect them to be called back-to-back-to-back? Or should I again just use a prompt? Because I can guarantee you if you run
call /XYZ, thencall /ZYX, this will run in the right order. So it’s not clear to me how reliable skills are yet. - We could do all this with prompt engineering plus custom slash commands plus the slash command tool. Skills are effectively opinionated prompt engineering plus modularity. The real question: what’s the actual innovation? Not that much. And at the same time, having a dedicated specific way to operate your agents in an agent-first way is still powerful.
I’ve built out several skills for repeat workflows. Right now, I’m really stacking up my user directory with a bunch of concrete skills. It’s very clear that this release is important. The Claude Code team, the Anthropic engineers, they’re really pushing this feature. And I think for good reason. This is powerful — a dedicated way across their entire platform to enable engineers and general users to create repeat agent-first solutions. We’re creating domain-specific expertise in an agent-first way. I give this a solid 8/10. It is very clear this does not replace any existing feature or capability. This is not a replacement for MCP, slash command, or sub-agent. It is a higher compositional level that you can use to group these features together to solve a specific problem in a repeat way.
This codebase will have access to all four skills, plus a meta skill for you. You can use this skill to build other skills. This is a very powerful agentic abstraction you can always use: build the thing that builds the thing. We also have the video processor with a dedicated script for processing and managing different video files, creating transcriptions, and so on.
Take these, understand skills, make them your own. Stay focused and keep building.