Better than MCPs? Claude Code's New Skills Feature

Okay, so we'll be going over this  brand new feature called Claude   skills and specifically how it's used in  Claude code and how it differs from slash   commands and subagents. So when I woke up  this morning, I saw this feature come out   and I grabbed my coffee and then basically  read through all the like announcements   and documentation as well as the GitHub page  because they have a few example Claude skills   that are available here. And also Simon's blog,  which he says that Claude skills are awesome. Maybe they're a bigger deal than MCP,  but I don't think it is a bigger deal   than MCP. But I guess it really does depend  on your use cases and how you're currently

using Claude. I also did try and the Claude  application because it's available there. And if you go to settings, then you can go  to capabilities and then turn on any of the   desired skills that you can see here, or you  can upload a zip file that contains your own   skills. And I actually tried out one of these  default skills, which is a Slack GIF creator.    And you can see that I called the skill, and  at least within the Claude web application,   it mounts a bunch of things onto like a  remote server somewhere and then executes   a bunch of the code until it makes the  thing that is desired from the skill. And it made this amazing GIF here, which is  kind of weird, but hey. And of course, if I   go to Anthropic Claude Skills page, then I can  see the specific instructions that were given to   that Slack GIF generator creator, as well as some  of the templates that are available for the code,   like the bounce, explode animations, and also  some of the core logic. And before going over

the differences, I will show you how you can  set this up and use this within Cloud Code. So there's much more documentation  links down below in the agent skill   section. But basically you want to  go to your project, and in my case,   I have a project called Hyperwhisper here. And  within the dot Claude folder, you want to create   a new skills folder and then create a folder  inside of that, which is this name of the skill. So in this case, I have code reviewer. And then  you can define your skill on top with the name,   the description, and that basically tells  Claude when it will be used because these   skills are triggered automatically from Claude  code. Like Claude decides when to trigger them. So you can't like add a skill and have  it triggered, but you can say like, hey,   can you trigger the skill? And whereas slash  commands, you trigger manually by actually   the slash command. And this description  basically lets Claude know when it should   be triggered. These are some of the allowed  tools that the skill can use once it's enabled. And then this is a description of the skill  itself. One of the things that you can do is   add a bunch of examples or optional files. So you  can create a new file and call it examples. md. So I can call it like examples. md. And  then after creating the examples. md,   I can say something like look at the examples. And then within brackets, I can say  examples. md and that will link to that   particular file in the same folder. And when  Cloud Code is using this particular skill,   then it will look at that file if needs be. And you can organize the files within subfolders  and so forth as shown here. So if you go to one   of their skills such as the MCP Builder, then  you can see there are a bunch of reference   files such as MCP best practices. And if you go  to SKILL. md file, then you can see some of these   reference files are used. So if I search like  best practices, then you can see it's linking   over to the best practices MCP file. And  remember that skills are model invoked,   so Claude autonomously decides when to use them  based on the request and the skills description. This is different from slash commands,  which are user invoked because you have   to explicitly type out the slash command  to trigger it. So this skill that I made,   which is a code review skill, I can  go to a session of cloud code and say,   what skills do I have available? And then it  will show me the skills available, which is a   code review skill and the release note skill. So  I can then say, trigger the code review skill to   tell Claude to manually trigger it or based on the  description, it will be triggered automatically. And you can see it's loading in the tools  that are available for the skill. It now   read through the file of the skill. It's reading  through the example file that we made earlier. And now it's going to do the code review of  the project based on the description of the   skill. But it's probably not going to do a  good job because like the description of the   skill is pretty bad. Anyway, so whilst this is  running, let's compare it to subagents as well.

I do have a previous video all about subagents   that you can watch. It should be  linked down below. But basically   after messing around with it and reading  all the documentation that's available. Some of the key differences are skills basically  use a parent model and subagents, you can define a   different model that's used for that particular  subagent. So when you're creating a subagent,   you can choose whether Haiku is used, Opus  is used, or just Sonnet is used instead. Or   you can choose whether the parent model for that  cloud code session is being used for the subagent. Another big difference is how the context window  is handled within the skills. So skills, whenever   they're triggered or run, they stay within the  same context window, which means that you can   follow up easily. You may have had a situation  before where a subagent was triggered and the   subagent decided to do something, but you can't  follow upon the subagent like what it decided   to do because whatever like context it had is  immediately discarded and only the output is kept. So when you have a subagent, it looks  kind of like this. You have your main   cloud code session on the left and then  it triggers a subagent and it gives it a   system prompt. And then the subagent does some  working, it like fetches all the files again. It basically is like an independent agent that  doesn't know anything else besides a system prompt   that was given to it. And then once the subagent  has finished running, everything in the working is   discarded. And then only the final output of  the subagent is passed back to main session. So that can be something like I found X, Y and  Z bug, or I did A, B and C changes, for example,   and everything else here is discarded.   Whereas when you're running a skill,   like this part in red, which has a skill  is like working or it's logic or everything   that it's doing, it is actually kept within  the main session. Another big difference is   that when you're using a subagent,  it's all defined within one file. So for example, I have this release notes  generated subagent and basically everything   is within one file here. And in some cases, you  can imagine your file getting like really long,   so like 500, like a thousand lines or something.   And you can add additional stuff for the subagent. So you can say look at this particular file if  needs be and have that bundled with your project,   for example. But for skills, any additional  context is progressively disclosed. So when   you run a skill, only the skill. md file is  loaded at once. And you can have dozens of   additional files that are all bundled  with the same skill and are only loaded   when needs be. So you can see,  for example, this MCP builder skill. You have a documentation library and then you have  some like specific implementations like TypeScript   implementation guide and Python implementation  guide and then a evaluation guide. So for example,   if you're working in a TypeScript only project  and you downloaded the skill online, then you   don't have like unnecessary Python implementation  guide like logic clogging up the context for no.    When the skill is triggered, it would know the  project is a TypeScript project and then it   would only look at the TypeScript implementation  guide when it comes to that particular skill. So yeah, basically because you can  split a skill up into a main file,   which is your skill. md file and reference  files, and have them loaded only when needs be,   it means you're much more context efficient and  you're not loading unnecessary information when   you basically don't need to. When  it comes to parallelizing them,   like with subagents, you can chain them  so you can tell it to run one skill and   then run another skill if needs be, but  you can't really run them in parallel. Whilst code is able to run many tools in  parallel and skills are essentially tools,   you will quickly fill up the context window  and then it will basically be unusable. So   it's much better to have subagents when you need  things running in parallel. So ultimately the   conclusion kind of here is that skills are  more for lightweight template driven tasks. So when you have like a very defined way of doing  something, such as when it comes to building a   new MCP server, for example, like they showed in  their example right here, then a skill can be very   useful and it's like a very well defined task of  either you successfully built the MCP server like   with this skill or you did not. Whereas subagents  are more for complex multi-step like tasks that   require a lot more context and context that may  be discarded later on. So that basically does   mean that there is some kind of overlap where I  have level of autonomy on the bottom over here. Subagents have the highest level of autonomy  and slash commands basically have next to no   autonomy. Then you have some overlap where  you may come up with something that could   be a skill or it could be a slash command  skill or it could be a   subagent instead. And it's for you to decide  which is best and which is fastest for your   particular context, depending on which  requirements you have here, for example. So I have some examples over here. I have like one   which is a PR formatter. So  this is very template driven. You may have a set of systems in your company  where your PR requests have to be formatted in   a certain way and having a skill can really help  you with that. And if you just tell Claude like,   hey, can you now make a PR for this?   Then it will know to trigger the PR   formatter skill because you will  have defined the skill description   to be like that. Skills can also be  useful for very lightweight tasks. So if you handle a lot of images, for example, and  you extract the metadata from the images using the   EXIF formats, then you can basically define  a skill of how the metadata that's extracted   from the image should be handled, because like  using a subagent for this particular thing is   pretty overkill, and for a slash command you  will have to trigger it manually. So you're   seeing a recurring theme here where skills are  most useful when you want standardized outputs   and you have examples or reference documentation  that you really want used. Whereas subagents are   more useful when you're doing something  like you want a code review of subagent,   you want a lot of deep context and you  want it to forget that previous context   and not to have it to complete the  main Claude code agent conversation. And another pretty useful way of using them is  to have like a problem solver sub agent. So when   you're really stuck on a pesky bug, for example,  you can spin up many sub agents in parallel that   basically try and figure out what the recalls of  that bug is and all take different approaches and   then combine that approach and then select the  best approach. And I did make a separate video   about this technique as well, which will  be linked down below in the description.

And in my own testing as well, I found  that skills can call sub agents. So you   can see I made a release note skill that then  calls a release note generate a subagent,   but I seem to be having a much harder time  making a subagent call a skill instead. And   I think that's probably something to do with  the system prompt of the subagent because it   kind of forgets that skills are even a thing  to begin with, so it doesn't call a skill. I'm sure that may be fixed soon and you will  be able to have a subagent call a skill,   but I'm kind of struggling to see  a use case where you would want   to have a subagent call skill or have a skill  called subagent. Anyways, for my application,

Hyperwhisper, I will be making a brand  new skill for this project. And what I   did recently is I basically translated  the entire application into Japanese. So basically every single string of the  application is in this really long file   over here. And I have the exact same file  as well, both for Japanese. So you can see   like this is how I'm basically translating  the application into different languages. And what I'll do is make a brand new  skill where every time Claude Code   adds a brand new string into application,  then it adds it into these two files here,   and it finds a relevant point to add it into.   You can also do that with subagents as well. But   because subagents are starting completely from  fresh with a brand new context, it will take   time to find that relevant like string that was  recently added and then added to relevant files. Whereas I think by having it in the main  session, it will be much faster and just do   a better job overall. And if you do want to  buy the application, it will be linked down   below with a coupon code for those who are  interested. And finally, if you have found

the video to be interesting, then do subscribe  to the channel because I do make these kind of   videos whenever there's a big release or update  within Claude code or any other AI coding tools.   89. 1s Use Arrow