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

Cloud 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 aents, 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 make sense of all of these

powerful clawed code capabilities.

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/comand

on the right. Bam, bam, bam. If you're

parallel agent coding, generating

multiple solutions at the same time,

you've likely created git work trees.

Here's a question for you. Which one of

these three ways is the right way to

create your git work trees or manage

your git work trees? To answer this, we

need to understand how these features

really differ. On the top here, we have

four key features we're going to compare

side by side. And on the left, we have

capabilities. So, let's start with the

three most important capabilities.

Skills stand out here right away because

they're triggered by your agents. If you

give your agents some direction, they

will trigger the right skill. Sub agents

are very similar in this way. Unlike

slash commands where you are explicitly

kicking this off, we then have context

efficiency. Now, this is a huge selling

point of skills. Unlike MCP servers

which explode your context window on

bootup, skills are very context

efficient. This is something that they

talk about a lot which I think is super

super important. I'm glad that they're

going into detail. There are three

levels of progressive disclosure. You

have the metadata level, the actual

instructions of your skill.md file, and

then you have all of the resources that

your agent pulls in from your skill when

it needs. All right, the last thing here

is context persistence. The only loser

here is sub aents. But of course, this

is what makes sub aents great. Sub aents

isolate and protect your context window.

Sharability is not that important. You

can use git, you can use plugins, you

can share these.

>> Your red tree work tree is live on ports

4020 and 5193. Ready for parallel

development.

>> Nice. All right. So, we got one of our

trees there. Sub agents are the big

winner if you're looking to parallelize

your workflows.

>> Dan, I've successfully created and

started your yellow tree work tree on

ports 4010 and it's running now.

>> All right. So we have our red tree, blue

tree, yellow tree. Fantastic. Okay, you

would think that specializability 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 and that you have a

dedicated solution. It's even more

modular than MCP service frankly because

skills have a dedicated directory

structure. Right? If we look at this

skill create workree skill, the most

important thing here is that we have a

dedicated structure for building out

repeat solutions that our agent can

invoke. Right? That is the primary

benefit of skill. So the modularity here

is really important. It is high. All

right? Unlike sub aents and slash

commands where you kind of had to roll

this capability out yourself which we

have done in previous videos. And then

things get interesting here at the last

level where we start thinking about

composition. Now this is where uh 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 aents, right? Because a sub

aent cannot use a sub aent. 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 aents. So this is the feature

breakdown. As you can see here, there's

a ton of overlap. This is important to

call out. It's the approach that's new,

right? We get a dedicated modular

directory structure, efficient context,

right, which again we had with sub

aents, 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.

Now, I know this isn't super clear right

away. So, let's look at some dedicated

specific use cases on when you would use

these four features. So, skills are

truly for automatic behavior. MCP is

built for external integrations. We have

sub agents for isolated workflows that

you can also parallelize. And then slash

commands are manual triggers, right?

Manual units of compute that you can

deploy when you need them. The big

battle here I see is between skills and

slash commands to be specific here.

These are custom slash commands. All

right, so let's look through some use

cases. Automatically extract text and

data from PDFs. So which of these four

do you think this belongs in? As we work

through this, make a good guess and then

comment down below how many you roughly

got right and if you were aligned with

where I'm going to place these use

cases. All right, so I think

automatically, right, there's that

keyword automatic. I think you want this

to be a skill. If you always want to

extract text and data from PDFs, this is

a skill. What if you want to connect to

Jira? This is an external source, right?

So, we want of course an MCP server. All

right. What next? Right? Let's keep

breaking these down. What if you want to

run a comprehensive security audit? Now,

this one is tricky. This one is tricky,

but I think because you want this to be

able to scale and because you don't

really need this in your context window

and you don't want this to be automatic.

You want this to occur at a specific

point in time that you kick off. I think

we want this to be a sub agent. Okay.

And so what about generalize, you know,

get commit messages. Now, we have a

simple one-step task here. Here's the

tricky part about these, right? You

could easily make this a skill. You can

make it a slash command. You can make it

a sub agent. But which is best? I think

this is best as a simple slash command.

Okay, what about querying your database?

This is a classic one. You of course

want an MCP server. All right, you at

least want to start with an MCP server.

We'll talk about composability in just a

second here. So what if you want to fix

and debug some failing tests and you

want to do this at scale. Okay, you of

course want to throw this inside of a

sub agent, right? You can scale this up.

Just get the job done. I don't care what

the errors are. Just fix them and do it

at scale. All right. What if you want to

detect style guide violations? This is

an interesting one. I think when you

want to encode some behavior, some

repeat behavior. I do think that you

want this to be a dedicated skill. All

right. Fetch real-time weather data from

APIs. This is a stupid one. Uh it's MCP,

right? This is a third party service

that you're integrating with. So, here's

a cool one. What if you want to create a

component, right? Insert whatever UI

framework you use. No one cares anymore

and it doesn't matter. This is a simple

one-off task that you likely want to

encode in a custom slash command. All

right, fantastic. So, here is a key

word. Whenever you see parallel, you

should always just think just jump to

sub aents, right? Nothing else supports

parallel calling, right? It's just sub

agents. So, whenever you see that

parallel keyword and whenever you want

to think about something, you want to

parallelize and isolate the context

window. And again, you have to be okay

with losing that context afterward cuz

it will be lost. you'll just want to

throw that into a sub agent, right? So,

this is for sub aents. Okay, so here are

some use cases with the appropriate

feature. I think you should set them

next to I think it's clear that MCP is

all about external integrations and also

if you want to bundle multiple services

together and then expose them to your

agent with specific capabilities, it's

pretty clear here you want MCP. If you

want isolated context windows that

you're okay losing the context of and

you want parallelization, it's clear you

want a sub agent. Now, what's more

confusing is skills versus slash

commands. I think skills versus MCP is

very distinct. Skills can of course use

MCP servers. You can compose everything

into a skill, but you can also compose

everything into a slash command. And

then this is where things get

interesting. If you look at this feature

set here, slash commands and skills are

very similar. The only exception here is

the modularity and who is triggering it.

So this is actually really interesting.

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

agenta coding, of AI coding, and really

of language models. So you want to be

very very careful to get rid of your

prompts. And let me show you exactly

what I mean. Let me show you how I'm

thinking about approaching skills as a

compositional unit and not a replace for

MCP/comands or sub agents because these

are all distinct. I think if you're

using just one of these, you're not

using these features properly. You're

not using cloud code properly. We have

our work trees and we can just ver, you

know, verify this very quickly. If we go

to trees, you can see we have three

brand new versions of this codebase.

fully built out. There's the environment

variable file. If you go into apps, you

can see client server. Everything is

there. 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 custom slash command and

it's a one-off job, do not use a skill.

This is not what skills are for. How

should we think about skills? So, here's

our skill sub agent and here's our

prompt. the three agentic units of work

that we kicked off. We accomplished the

same job with three different

capabilities. Okay. Now, this is where

things get tricky and this is where

there's a lot of confusion around this

tool. Right? 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.

Cloud code is becoming a larger and

larger tool. Successful things tend to

grow and at some point it loses its

originality. It loses what made it

distinct. Now I don't think cloud code

is there. I like this feature. I think

it's a net positive for the ecosystem,

for the tool and for engineers. Now how

do we properly use skills? Remember in

the beginning I mentioned that you know

I asked what's the right way to create a

get work tree. Very clearly you can do

this in three distinct ways. I think in

the end you can build out any one of

these. But the true answer here is you

probably want a prompt to create a get

work tree. You want to be able to see

what happened. And unless you need to

create many of these, we don't need to

parallelize this, right? But if you do

need to parallelize, use a sub agent,

right? That's a perfect, you know,

branching point to go from custom slash

commands to sub aents. If you need to

parallelize, you can take your existing

custom slash command and throw it in a

sub agent. In fact, that's exactly what

we've done here. 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, right? Where we have the base

level unit being a prompt, aka a custom

slash command. How you compose these

features is very important. All right.

And you can push this even further in

our skill. Guess what we're doing?

Instructions. Use the slash command

tool. Okay, so here we are looking at

the prompt as the primitive for all the

existing features. I've been saying this

for years, frankly, ever since the

generative AI revolution kicked off. Do

not give away the prompt. Okay, 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 is that?

It's because everything comes down to

just four pieces. Now, there are four

pieces of Agenta coding. You have

context, model, prompt, and tools. If

you understand these, if you can build

and manage these, you will win. Why is

that? It's because every agent is the

core 4. And every feature that every one

of these agent coding tools is going to

build is going to build directly on the

core 4. This is the foundation. This is

the ground level. All right? If you

master the fundamentals, you'll master

the compositional units, you'll master

the features, and then you'll master the

tools. 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 out an MCP server. Keep it

simple. All right? Build a prompt.

Everything is a prompt in the end. It's

tokens in, tokens out. So, if we want to

parallelize though, we can go to sub

agent. Now, when do we go to a skill?

Right? This is the critical question.

When do we move from a prompt to a skill

for creating git work trees? We can

easily use just a prompt, right? One

prompt solves the problem. But if we

want to solve the problem of managing

our git work trees, right? Because you

know dealing with git work trees isn't

just about creating them, right? If I

open up trees here, I now have three git

work trees to manage, to read from, to

merge, to remove, right? We need a

skill. Okay? We need a skill to manage

our get work trees, right? So this is

where one prompt is not enough. You want

to scale it into a reusable solution. We

need of course a skill. This is what

skills were built for. Okay, reusable

file system based resources clawed

domain specific expertise workflow

context best practices into specialists.

Okay, I just kind of glossed over that.

Didn't really read that properly, but

you get the point. Okay, this is this is

what skills are all about. Skills offer

a dedicated solution, right? An

opinionated structure on how to solve

repeat problems in an agent first way.

Okay, let's let me show you exactly what

I mean here. So, we're going to boot up

a new instance and if we go to our

skills here, right? If we collapse

collapse and look at skills, we have a

work tree manager skill. This is a lot

more built out, right? And so, we can do

something like this list skills. You can

see here I have a meta skill and a video

processor skill.

>> Dan, I've listed the four available

skills you can use in your cloud code

environment.

>> So this is the right way to think about

skills. We have a skill that is a

manager of a specific problem set.

Repeat solution for a specific problem.

If we actually just needed to create

work trees slashcre

and we're done, right? Give the branch,

give the, you know, additional details

to make the branch unique. Right? set up

environment variables, set up the right

client server ports, whatever, and

you're done, right? Oneoff. But if we

need to manage, and you saw those

prompts just then, right? If you need to

manage multiple elements, you know, stop

manually prompting this, stop fing off

these custom slash commands by yourself,

really dial in and build a skill. So,

let's run this, right? Let's actually

run the skill. So, I'm going to say pull

back up our trees and let's manage these

now, right? So manage get work trees

remove red tree create purple tree with

offset four so that we offset our ports

list our trees. Okay so this is a skill

set we have solved the problem of

managing our get work trees with a

dedicated skill. This is what skills are

about. All right I'm going to fire that

off and our agent is going to get to

work on this. You know this leads us to

a great point here. Let's go ahead and

look at some definitions while our agent

works through this piece by piece. When

we come back, we should see red tree

removed and we want to see an added

purple tree and then uh we want to see

just a summary of our current trees,

right? Let's look at some just

definitions at a high level, right?

Where do all these capabilities fit and

when do we use each? All right, so agent

skills, you use this to package custom

expertise that your agent autonomously

applies to your reoccurring workflows.

Super important, very distinguished. MCP

servers is about connecting your agents

to external tools and data sources. To

me, there is very very little overlap

here between agent skills and MCP

servers. These are fully distinct. And

to be super clear here, I like to think

about things in composition levels,

right? What should be using what skills

can have many MCP servers. Skills can

have many sub aents. Skills can have

many custom slash commands, right? But

an MCP server is a lower level unit,

right? you wouldn't have an MCP server

use a skill. So there's a chain of

command here. And very interestingly, um

I would consider a slash command a super

primitive where it acts as both a

primitive and a composition because of

course you can take a custom slash

command and you can run a set of skills,

you can run MCP servers, and you can run

sub agents. So it's very interesting how

these things compose. There's a lot of

circular composition that you can build

up here, but I would definitely place

your skills at the top of the

composition hierarchy. All right, so

let's continue here. We have agent

skills. We have AMCP servers, right?

External data sources. We have sub

agents and we use sub aents to delegate

isolatable specialized tasks with

separate contexts that can work in

parallel. Sub aents are very

distinguished, right? I think it's very

clear when you'd use a sub agent versus

when you wouldn't. when you want work

out of your primary agents context

window and you can delegate it and you

don't care that you're going to lose the

context at the end. We also have custom

slash commands. All right, this is for

reusable prompt shortcuts that you

invoke manually. Now, I am definitely

underelling custom slash commands here.

I I would say if you had to pick one and

you just kind of forget about everything

else, you definitely want to prioritize

your mastery of custom slash commands.

Why? because this is the closest

compositional unit to just bare metal

agent plus LLM, right? You're passing in

a user prompt. You must master the

prompt. There are no exceptions here. If

you avoid understanding how to write

great prompts, how to really build these

out in a repeatable way. Uh you will not

progress as an agentic engineer. You

will not progress as an engineer in

2025, in 2026 and beyond. Okay, the

prompt is the fundamental unit of

knowledge work. Now, there are no

exceptions to this. If you understand

this, you will win. All right? And this

is something that comes up over and over

and over. This is a big topic inside of

Tactical Agentic Coding and Agentic

Horizon. I'll leave those linked in the

description if you want to push further

and really master how you can use

prompts at scale in agents with multiple

agents. All right, that's the custom

slash command. This is the primitive.

All right, this is there's this is ultra

important. All right, so what's next?

Right, let's continue breaking down all

these features. We of course have hooks.

Hooks are great. This is deterministic

automation that executes commands at

specific life cycle events. Right? This

is where we kind of add determinism

rather than always relying on the agent

to decide. So we need to balance these

things. Right? And this is why again in

tactical agent coding we push outside of

the agents to ADWs AI developer

workflows where you combine the old

world of code with the new world of

agents. If you really want to scale you

need both. and hooks lets us tap into

deterministic automation. All right, so

what else we have here? We have plugins.

This is simple. There's no overlap here

between any of these other features.

Plugins let you package and distribute

these sets of work, right? This isn't

super interesting. It's just a way to

share and reuse cloud code extensions.

All right, last but not least here, we

have our output styles. And so you saw

this here, right? I'm using output

styles 24/7. When our agent finishes

this work, it's going to actually

summarize the work using a texttospech

output style. If we scroll down here,

you can see I have a whole slew of

output styles. We've talked about this

before on the channel. I'm using the

observable tools diff text to speech

summary. And you can see here we're on

to that last step list work trees

prompt. And very importantly here, you

can see my skill is using a

compositional prompt, right? It's using

a prompt to do the work. Great stuff

there. That's the output styles. You

know, I hope this helps you distinguish

some of these features and when you

should be using each. At the end of the

day, use whatever works for you, right?

Don't let these features, don't let

these, you know, cloud code buzzy kind

of features stop you from just shipping

work. All right? Use what works for you.

But I would say have a strong bias

towards slash commands. And then when

you're thinking about composing many

slash commands, sub agents or MCPS,

think about putting them in a skill. All

right? But your skills again should have

a slew of slash commands. Now that leads

me to some opinions that I have about

this feature. I like it, but there are

also some problems with this feature.

So, let me just quickly just work

through this pros and cons list. So,

this is agent skills. And let me just

kind of walk through this with you. I'm

going to tell you what I like and what I

don't like. And comment down below if

you agree with me on my pros and cons

here. I like that this is agent invoked,

right? We want to lean into the

autonomy, right? Dial up the autonomy

knob to 11. All right. And this is how

we do it. We delegate more work to our

agents. I like the context protection,

right? This is incremental context

window adoption. Progressive disclosure

is what they call it. Unlike MCP

servers, which just straight up torch

your context window. I like that this is

a dedicated isolated uh file system

pattern, right? We can now logically

compose and group our skills together.

This makes it really easy to write,

update, create, modify, and then

distribute what your agents can do. So,

this is great. This is honestly the

biggest value prop right next to agent

invoked for agent skills. Um, can

compose other elements or we should say

other features. And then lastly, you

know, again, I think it's really

important to highlight this is the

agentic approach. This is what you want

to see. Agent just does the right thing.

Lots to like here, but there are some

things that I don't like. So, uh,

doesn't go all the way. What do I mean

by that? I can't nest sub agents and I

can't nest my prompts, right? Why not?

Why do we not have the capability to

inside of our bundle here, right?

Instead of our like file system VM for

my skill, where's my /commands

directory? Where's my agents directory?

Right? Why didn't the cloud 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 these agents, it's just prompts,

right? This is Don't let anyone confuse

you with these feature releases. Prompts

are the most important thing of all.

>> Dan, I have successfully managed your

git work trees.

>> Nice.

>> Removed red tree, created purple tree on

ports 4040 and 13, and listed all three

running work trees. Okay, so that work's

been completed, but let me just finish

my rant here. Um, you know, why can't I

put the most important primitive of all

inside of skills in a dedicated way? I

know, I know I can just engineer this

in, but they're creating this pattern,

so just go all the way. That's my

biggest complaint um and my like one

request for this feature. I think that

uh reliability is going to be an

interesting one. So, will the agent

actually use the right skills when

chained? I think individually it's less

concerning but when you you know stack

these up and this is one of the key

features that they mention um you know

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

to back to back or should I again just

use a prompt because I can guarantee you

if you run you know call slxyz

then call slash uh zyx this will run in

the right order. So, I'm I'm It's not

clear to me how reliable skills are yet.

Of course, more testing. Make sure to

subscribe. Make sure you like and

comment so the YouTube algorithm knows

you're interested. We're going to be

pushing skills hard and seeing what we

can really do on the channel. So, the

last kind of issue I have with this is

that we could do all this with prompt

engineering plus custom slash commands

plus slash command tool. problem here is

that skills are effectively canyonated

prompt engineering plus modularity. The

real question here is is what's the

actual innovation,

right? What's actually new here? I think

the answer is not that much. And at the

same time, um having a dedicated

specific way to operate your agents in

an agent first way is still powerful.

All right. So, it's very interesting,

right? This is quite a simple feature.

It's a kind of thin opinionated file

structure, but we could do that before,

you know? So, I don't know. I'm I'm I'm

still kind of working through this.

There's nothing actually new here. I

think this is, you know, the cloud code

team making it easier to bundle together

repeat solutions in an agent first way.

So that's my pros and cons list. 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, right? We

have this like huge banner here at the

top. The cloud code team, the anthropic

engineers, they're really pushing this

feature and I think for good reason.

This is powerful and it's a dedicated

way to across their entire platform

enable engineers and just general users

to create repeat agent first solutions.

Right? We're creating domain specific

expertise in an agent first way. So I

like this feature. I am using it. You

know I give this a solid 8 out of 10. It

is very clear this does not replace any

existing feature or capability. Like

this is not a replacement for MCP/comand

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 is going to be available to

you. Link in the description. You're

going to get access to all four of these

skills. And I also have the meta skill

for you. You can use this skill to build

other skills. This is a very very very

powerful agentic abstraction you can

always use. Build the thing that builds

the thing. This is a big theme in

tactical agentic coding. Again, link in

the description for that. Then we have

the video processor where we actually

have a dedicated script and this skill

is dedicated around processing and

managing different video files, create

transcriptions, so on and so forth.

Right? So I just wanted to give you a

few ideas of how you can use skills to

push your engineering forward. Take

these, understand skills, make them your

own. If you made it to the end,

definitely like and comment to let the

algorithm know you're interested. I'll

see you next Monday with a big idea for

your agent coding. Stay focused and keep

building.