304 - Agent Skills - when to use them and why they matter

[MUSIC] Welcome to Fragmented, an AI developer podcast that helps Vibicoters become software engineers. One episode at a time. I'm your host, Koushik. >> And I'm Yuri, the other host of Fragmented, where I'd love to talk about using AI to make you a better developer. >> Today, we're going to tackle the topic of agent skills. Once you understand how skills work, you unlock a new level of productivity that is therefore the taking, because skills are just so simple. But there's two really common questions that come up whenever people talk about agent skills. The first is, when do I actually need to use agent skills? It's a feature, but I don't exactly know when I'm supposed to use this feature and what it's meant to achieve. And the second is, now that you have an understanding of what it is, it feels very confusing because there are plenty of other tools and features, like MCPs, slash commands, and it's very easy to get confused when to use one of these existing tools versus say an agent skill. So think of this episode as a crash course in understanding agent skills, because the thing with agent skills is they're like deceptively simple, but incredibly powerful. Once you understand how agent skills work and how simple they are to get them working, you almost unlock a new level of productivity. >> Totally, yeah. Especially since last week, if you've been following the news, probably heard about Cloudbot, skews are the reason most of that is going about like that. So it's really interesting to see how another Markdown file can help you do so much. >> That's true. Well, you said Cloudbot, but I think you have to correct yourself. You're eating, it's molt spot. Oh, actually, no, it's not even molt spot. (laughing) It's open-claw now, right? >> Yeah, it's open-claw. So it's been very interesting following all the drama around how this tool has evolved, but you're absolutely right. Underneath the hood, it's all just a bunch of skills that really powers it. >> So yeah, I think if we want to start looking at that, we probably want to know, when do you need an agent skill? So what do you think? >> So when they came up with agent skills, it was as simple as just repetition. Every time you needed to repeatedly do the same thing with an agent, so think about cases where people would have prompts stashed away or you would copy-paste the same thing again and again into your agent. That's a good sign, or as we say, code smell that you should probably be using an agent skill instead of repeatedly manually doing the same thing. So that's the first reason to use agent skills, repetition. And the repetition can be across two dimensions, right, one is you yourself happen to be doing the same thing over and over again, that's one dimension. The other dimension is say you work in a team and across the board, your teammates happen to do the same thing across the board, right? So you might do it today, your colleague might do it two times tomorrow, another colleague might do it three or four times. That is another dimension of repetition, where again, if you just create an agent skill to do this, everyone can leverage and use that same functionality. - Well, yeah, that's fair. I think it's like an idea how to get out of this non-deterministic and getting to something more deterministic, right? It's just a bit weird that someone could ask why you can't just put that in the agents, MD file or in the cloud MD file and because that would probably also work, right? - That's a great question. The answer to that is the second most important reason to use agent skills. Agent skills come with a feature called progressive disclosure and we'll go into the details of progressive disclosure. It'll make more sense once you understand what a skill is and how to build a skill. So we'll just remember that term progressive disclosure. In the past, we have talked even in our MCP episode, we talked about the problem of context window bloat. Agent skills were specifically designed to address this problem. I think it'll be easier to understand progressive disclosure once you know how skills are actually created and what they are. So maybe that's a good place to start Yuri. Can you tell us what are skills? - Right. Yeah, so I did some research in that and well, turns out it's a folder with some markdown files. So your PhD thesis paper is like two lines. It's a folder with markdown instructions. - Yeah, they keep on giving. But yeah, I think basically, I think this whole thing is just an evolution of what the other two that came before. So because before, like you could have some slash command, which is also just a markdown file, but now you're combining things because you're also leveraging the two calling capabilities. So it's now you're composing two things now. So an agent skill is just a simple folder with instructions, scripts, resources, anything that an agent can use and discover to do the work more reliably. So it's like this small package of instructions with maybe a command or like a CLI-2 or something. From a highlight, but that's basically it. - If you think about the agent being born new, right? 'Cause every time you create a new session, the model has no idea about the specific domain. So skills is a way to basically equip this agent to be able to do these things that are specific to your domain or your requirements, right? And so that's where the instruction file and the folders become useful. I did have a question though, with scripts, what are we talking about? What are, what do you mean by the scripts folder? - Basically, you can just put any script there. Some Python, GoRus, Bash, BashShelvescripts, you know, anything, it's just that these now will be part of the instructions that you're going to give to your agent. So you can do something very reliably because this is just code, right? It's going to like same input, same output. So now you're adding literally a capability that your model can use it and it's already baked in into this skill. - Oh, that's interesting. It goes back to that point you're making, but determinism in a non-deterministic world. - Yeah. - These scripts, you can literally put that in there and say, "Hey, agent, just use this. You don't need to figure out the logic, just run the script and you will get the results you need." - Yeah, because it turns out like these agents, they can run code and they have a lot of capability of creating things on the go, but sometimes you just want something very solid, very reliable. You just give it the script and it will run, and but it also now has the context of when to run it and what kind of output you actually want given the context that it has. So when you put all these things together, it becomes super powerful. So yeah, for the, as part of the skills definition, you will have first the skill.md, that's the main file where you have your markdown, description of what the skill is, like the instructions of the skill, but now you also have this header, which is in front matter, metadata, right? So you can have a bunch of things there. You can need to look at the spec to know all the properties. The thing is that now you have this front matter metadata that can be parsed by the agent harness in this case. This is really important. This really differentiates how skills are used. Then you have the scripts folder like we talked about. Then you have the reference folder. This is where you put the documentation that can be loading to the context. So if there is more than just the instructions, this is where you put it. And finally, you have the NASA folder, which is where you put the templates or examples for output. So it's really useful to have examples for using LLM's, right? So if you want to have very solid kind of response and outcome and have the LLM generating good results, it's really useful to have examples as part of the context for the LLM to generate results reliably. So it's part of the definition of a skill to have this folder. So you can do exactly that. So that's about it. So these are the four pieces you would need to create a skill, which by the way, only the skill.md is actually required. The other ones are optional. So you don't need to have the assets and the scripts and the references. Those are optional. That makes a lot of sense. And so just to recap, if I want to create a quote agent skill, what all I have to do is create a folder, name it the same as what I want to call the agent skill. I have a skill.md markdown file and that's the only thing that's required. That almost is like the instructions I could put in. And these are human instructions, right? I don't have to necessarily write these instructions in like code or anything. It's just as though I was talking to the agent. That's exactly it. So back to the initial point I was making with OpenClaw. The thing that makes this even more powerful is that this is now, it's been for some time already, right? Parts of the A-A-I-F OpenStandard. This is similar to what we said on the MCT episode. So agent skills are part of this OpenStandard. So that's why it's getting a lot of attention and a lot of people building it because it's also since it's a standard, all the agents can use that. It's like, you have this one platform. Oh, and the other one point I'll add with this is, when you package up the skill, you can zip that folder we talked about and actually upload it beyond just the terminal or these coding kind of platforms. So as an example, Cloud AI, the web platform, you can take the skills folder you just built, zip it, and that zip, you can upload that directly into these tools. So if you wanted your mom, dad, to basically run this script for some reason, again, I'm making up a convoluted thing. But you don't want them to write Python or any of these other scripts. But you just want them to have a nice interface that will run these scripts. Skills would work. You could potentially use skills and give it to other people to use, right? That distribution piece in a much more friendlier platform. So that's the other thing as part of the standard. I think is becoming a thing. Yeah, you get a lot of things on that. So you gave us a high level overview of what a skill is. But maybe let's zero in on that instructions file that you mentioned. So the standard requires you to have a YAML front matter at the top of that marked on file. So a name and description field. The name should correspond to the same skill. So whenever you invoke the skill, it should be the same name used there. But in the description, you describe what the skill does. And this is actually pretty important when we talk about progressive disclosure. Because the main difference between all of these tools, say you wanted to put everything into your agents.md file or your cloud.md file. Every time you create a new session, all of that is loaded into your context. It the same applies into MCPs. And we talked again about this one of the disadvantages in MCPs. Everything is loaded into your context, which means regardless, every time I open up cloud code or anyone opens a new session, that context window is already taken up because you've added all these instructions. That's the disadvantage. The way skills goes about this is this YAML front matter that I talked about. It only takes the name and description and loads that into the context window. Only the words in your name and description are converted into tokens and used in your context window. Below that field, you might have like 500 lines of instructions in that skill.md where you're telling the agent what to do. None of that is loaded by default into your session. It only picks that up when explicitly the model realises it needs to use this skill. Then it reads that file again, takes all of that, converts it to tokens and then loads it into the context. It lazy loads the information only as it needs. That's the whole innovation, so to speak, with agent skills compared to all the other tools we have had before. Yeah, they're really leaning on solving this problem and I think it makes a lot of sense. So that's how I think about it. You just give just enough information to be able to find your way to the next point. Yeah, and if you want to get more technical on that, I think the model is now good enough on that specific needle on the haystack test, which is like, given these huge contexts, can you remember this part, this most section? And basically, the descriptions of the skills are these sections, you know, like these tiny sentences that the model can retrieve and remember, okay, I know that this thing exists in my context. So they're good enough now to do that. So that's I think maybe one of the reason this feature works so well now. Interesting. And is that like a terminology that's used in the industry now? The specific problem, the needle in the haystack problem? Yeah, there are benchmarks for needle in the haystack. We'll try to add that in the show notes. Okay, so I think that's pretty much what we mean. Hopefully the terminology of progressive disclosure makes sense. It's just lazy loading and providing the right kind of information when needed. I think this is really useful. I think the first time I started using it was mostly because of MCPs, you can literally type the slash context on cloud. And it will show you this small UX, small UI showing like which part of the context is being used by which feature. Basically, how many tokens your system promptly is taking? Or how many tokens your MCPs tools are taking and the skills and the messages and that kind of stuff. So you can just by looking at it, you will notice right away that MCPs take way more in general. Like especially, of course, you need to have MCPs. But if you have a couple, you would already see that MCPs they take more than skills and skills like they're very nimble because it's literally that's just the description of the skill that's being loaded. You don't have the full all the files that you have there. You're not loaded there progressively disclosed. That makes sense. And you know what found interesting is that just last week, anthropically announced that slash commands and skills are basically going to be merged into a single feature in a way. Also effectively slash commands and slash skills are pretty much the same. So I can reap, are they like almost interchangeable? They're merging them, but there is a difference and they are making that difference explicit now. Basically, if you think about it, slash commands, it's you who's doing that right, you invoke the slash commands. But skills on the other hand, skills are invoked by the agent. You just add it to the context and the agent decides, hey, oh, I think it makes sense now to use that skill. But commands know commands you are the one doing that. So basically they add this this parameter on the definition of a command and a skill is this user invocable or agent invocable can be either one of them or it can be both. Yeah, this is the differentiating part. You know, I think that's really insightful. The point about being agent invocable is probably why they came up with skills, right? Like they want, again, if you think about what an agent is, eventually that tool piece is extremely important for an agent, right? I think you pointed out the Nvidia definition in one of our early episodes. You have this thing that is able to execute it come up with a plan and has the tooling to execute on that plan, right? So this tooling, you want the agent to be able to discover those tools and I think that it's all connecting. Yeah. So I think basically that this whole progressive disclosure thing, if you think about it, what's happening is that slash commands and skills are so similar, but skills like are super set, right? They're bigger. They have the same things, but they have more things. And also like the issue we had with MCPs, they're also solving the same way with progressive disclosure, like they also introducing that. So I think that's kind of converging, you know, like all these features are kind of converging in a similar direction. So eventually, this will be simpler maybe, but as it stands, I think the whole idea is to get this progressive disclosure out there and fixing these issues with context bloat. I think we covered the basics, the theory, but if you want to actually view the skill, where do we start from? So I would say start at the beginner level, which is maybe just use a very simple MCP and try to get a repeatable set of tasks. So one good example is maybe if you want the agent to give you a list of open pull requests that you have to review for the day, that's a good beginner example of how you can create a skill. So you create the skill, you know, connect it to maybe a GitHub MCP or even if you don't want to connect to the MCP, if you have the GH, CLI utility available locally, you can create a skill with a set of instructions to say, hey, hit the GitHub repository, pull the list of open pull requests that are assigned to me for review and present them to me. That's the simplest skill you can start with. But if you thought the way to create the skill is to, you know, go and create a folder called skill at a skill.md instructions file, I would say don't even bother because you can use a skill to create the skill, if that makes sense. Class, you can just open up the agent and use this skill called skill creator and it'll do all of that. It'll make sure it's in the right format and it's a little nuance because if you use Cloud code, it doesn't come built in with the skill. You have to install this skill and you can install it from a marketplace and Thropic has this repository called Anthropics/skills. It's a GitHub repository. It's open and in that you'll basically have the skill called skill creator. It's funny because in Codex, it actually comes built in. So the Codex CLI tool has a skill creator. I don't know what they call it, but it's a very similar term. I would say based on the tool or utility that you're using, figure out if they have the skill built in, if not, install that skill and definitely use it. You don't want to be handwriting your markdown and making sure the YAML front matter is all in the right format. Fair enough. Fair enough. Good tip. So it's funny. You mentioned that because I actually copied this skill creator from cursor because I think I was browsing my dot files and I saw, hey, there is a skill creator. Then I checked the code and I checked the text there and there were some instructions about cursor folders. So I just changed that to whatever I was using. But yeah, it's literally, you can literally just do that. But speaking about advanced skills, there was this topic that you and I were discussing as we were coming up with the episode script. In the YAML front matter, we talked about just name and description. Those are the required fields, but there's actually more fields, right? There's other very interesting fields. For example, one, you can specify the model that you want in that skill because sometimes you don't want to use the biggest, most powerful model because it's more expensive. If you're just retrieving or doing basic things, you want to actually use a much smaller or leaner model. So there is an attribute in the Yamel front matter called model, but you can explicitly specify which model you want. That's one example of how you can start to make these even more advanced. There's one called context fork, which is very interesting. That's the one that I think you and I were going back and forth. Do you want to tell us a little more about this one? So there's this very interesting one feud, right? It's called context, which when you set to fork, it will run the skew on an isolated context. So the idea is that this is not going to pollute the context that from your main conversation. It would run as if it was like in a separate thread, so to speak. And this context fork is actually pretty useful because when you think about it, even if you have repetitive tasks, because I'm not sure if you have faced this situation, but if you have an agent and you want this agent to do the thing repeatedly, which is like search a folder, analyze, come back with the result or make multiple API requests. If it's making 50 requests because it pulls a list of IDs and then it has to make an API request for each. When you start to do these repetitive tasks, that's a good reason to use context fork because you don't kind of want all of that API request and the back and forth to go into your main agent. You just want the results, especially when you have this repetitive process. So that's another good reason to use context fork. When you find yourself having these small but repeated tasks, you should probably push all of that into isolated subagents with this field. While we were saying that, I just thought about this good use case because I have this skill that I built for transcribing Instagram Reels. Yeah, I know. Oh, man, you're like a machine, so you want to be cool and plugged into social media. You do it with an agent. In my experience, we can very uncool. In my defense, there's some useful content on Instagram, but it's really annoying to have to be watching the thing over and over. So I just want to, you had just give me your context. So I paste that you are also the agent and it goes, watches the thing, pulls back the pulls back the transcript. So I think it's a very good use case because it has to do a little back and forth. For example, there are some stories you have to split into multiple chunks and then you transcribe each chunk and then you put it together. So I think it's a good idea to to start now fork it. So it doesn't pollute the main context, right? It just gives me the output which is this file with the transcript. That's a good idea. Maybe I should try that. And just as a nuance, a common question people ask is if you have this context fork and it's pushed to a separate subagent, how does the main agent know what results to pick up? The way that works is the very last output, the final response that you have from this subagent is fed back into the main agent. Before we close, I'm reminded of this quote by Uncle Ben from Spider-Man with great power comes great responsibility. What should I be careful about with agent skills? I think our whole industry is going through some very interesting phase now with skills. If you step back and look at it for what it is, becomes clear that this thing can be pretty dangerous because what is it? What is that you have now? Is that you have this agent which a lot of people give full access on their machine, right? And now you have something that can decide when to do something and this something is basically running code that you download from the internet. So I think as a rule of thumb, you should really know what the skills that you have installed do. Ideally, maybe you should be building the skills that you use, I think. But I mean, eventually you're going to find something that's just so compelling to just to start pulling skills into your agent and making it do different things. And I think that's probably what made OpenClaw so popular is that there is this marketplace of crazy skills that you can just start adding to your agent. It's just become super smart and it just works. But for example, giving your agent access to your one password and letting it decide when to use that, you should be aware of what you're doing when you install these skills and maybe try to isolate them to a specific sub agent. There are ways to use them that make them more safe. But one thing I can't wrap my head around is using a package manager to install skills that you don't know where they're coming from. Something that's also interesting to do, there is the OpenClaw. They have this repo, this website, where they have all these skills there. And you can just install like with their platform. But what I recommend is that you browse it. You can literally just copy the repo. It's just a repo. You copy your clone into your computer. And then you browse it. You ask your agent to list the skills there. They are like, what are the interesting skills for, I don't know, browsing social media or transcribing text. And then you can decide and look at the code and decide which ones you want to actually have. Don't just mindlessly install stuff from the internet. We should be past that phase. I think I was going to say that's general advice since the 1990s. Don't randomly install things you find on the internet because surely enough, you're going to shoot yourself in the foot. All right, Yuri, I think those are great parting words. Do not go randomly install things from the internet, especially agent skills. If you use OpenClaw, be careful what you let OpenClaw do. Don't give it access to your credentials, your API credentials or your secrets or your Bitcoin tokens or whatever it is. You want to be a little careful there. I'm going to keep you in my Instagram transcriber and whatnot myself. Thank you very much. If I start to see random posts from Yuri on his Instagram, I'll know he's definitely jumped onto OpenClaw then. All right, thank you all for listening and we will catch you in the next episode. All right, see you in the next one.