Using skills with Deep Agents CLI

Key Takeaways

Hey, this is Lance from Mangane. I want to talk about skills, a new concept introduced by Anthropic recently. Show how I implemented them in our deep agent CLI and then talk about the philosophy behind skills and why they're interesting. Now, this is a deep agency. I've just spun this up in my terminal. I'm going to ask the deep agent CLI to perform web research on a topic. I'm interested context engineering. It kicks off. Now, you'll see something interesting here. Based on my request, it scanned its skills directory, which I'll talk about in a minute, and it's found a skill related to this topic of web research, which I gave it. So, it actually went ahead and read this skill.md file, which gives a bunch of context about how to perform web research. So, you can think about skills as like standard operating procedures that you can give an agent for different tasks. So, in this case, I've given the deep agent CLI a number of different skills, one of them for web research. So what happens is when I ask this request for research, it knows, hey, I have a skill for that and it looks at a particular file called skillmd in the skills directory. It reads that file and then it gathers a bunch of context about this particular task that I wanted to solve. The agent mentions it's going to follow the web research workflow. Then based upon the skill, it says, "Okay, I'll follow that research workflow that you've given me." creates a task list, writes a request, and it proceeds down this research trajectory based upon the contents of that skilled.md file, which it dynamically loaded based upon my request. So now what's happening is it's going to kick off a sub agent per my instructions to do research. We can see that sub agent kicks off a bunch of web searches. That's fine. I approve them all. And you can run the deep agent CLI in auto approve mode if you don't want these human in the loop approval steps. stage has conducted a bunch of research and you can see it returns to me a nice overview here. It's then checking its to-do. Now it asked me for approval to write the final report. That's great. So I approve that. It's writing this file. It's verifying completeness relative to the request. So it reads this research request.md which it wrote initially. Verifies completeness and it finishes the final report has been written to this directory. I can enter bash mode with the exclamation point. And I can see the final report isn't written to my directory along with the research request. That's all great. And here's a file. I can open it up. I can scan it. So I get a very nicely researched rich report with 17 citations on context engineering. So you've seen skills in action with our deep agent CLI. I want to talk a little bit about the philosophy behind skills and why I think it's very interesting. So skills were introduced by Enthropic recently. You can see the very nice blog post on here. Skills are nothing more than directory of folders. Okay, each folder has a particular skillmd file and the skillmd file has a particular structure. It has this YAML front matter and it has then the rest of the instructions just as markdown. Now the thing that's interesting is this YAML front matter is always loaded into the system prompt of the agent. This is how it works with cloud code. This is how we implemented it with the deep agent CLI. So this YAML front matter is a very very context summary of what the skill does. If you go to the deep agents repo, go to the deep agent CLI folder, you see this example subfolder, open it up, you'll see skills and you can actually see the skill. MD file for that web research skill. Open that up and here you go. So there's that YAML front matter. Very nice. And then here is the full skill and this outlines in detail how I want the agent to conduct research. Now this is just markdown. You can modify this in any way you want. It just provides instructions to the agent about how to use it native tools to accomplish tasks. Now, one of the important ideas here is what Anthropic calls progressive disclosure. So that basically means that the YAML front matter is the only thing pre-loaded in the system prompt. So you're not overloading your agent with a whole bunch of kind of lengthy skill descriptions. You're only loading that YAML front matter. The agent can see all those and then decide, hey, if it wants to use a skill, it's instructed then go ahead and read this full skill MD file. Now the skillmd just lives in a directory and in the directory you can have other files. You can have scripts to run that can all just be explained in the body of that skillmd file. Now here's the key point. If you're using cloud code for example cloud code is a bunch of native tools for file access using the shell and so it can read any of these files. It can execute any scripts using the bash tool. So using a small set of native tools that can implement whatever you specify in the skillmd files, we've borrowed a lot of those same ideas for the deep agent CLI. We have a shell tool. We have file manipulation tools. And so all you need to do in the skillmd file is just say, hey, what to do? Any scripts you want to run, it can use this bash tool. Any files you want to read, it can use it to read file tool and so forth. So all you're doing in the skillmd file is you're providing context that the agent can use using its native tools to do stuff, execute scripts that live in the folder, read files that live in the folder, and so forth. Now, if we pull back even a little bit further, why is this interesting? Well, with agents, we actually want agents to perform actions. We want agents to be able to do things in the world. That could be execute code, that could be perform web search, that could be other things. Now, we did a webinar with Manis a few months ago and they talked a lot about this action space and how to design the action space accordingly. And one of the principles they talked about a lot is use a small number of atomic tools at the function calling layer or the tool calling layer but give the agent access to a file system where it can just run scripts if it wants to perform additional actions. This is a subtle but very interesting point. So for example with manis just like cloud code just like deep agent CLI has a small number of native tools shell tool file manipulation tools but it gave but the agent has access to a whole bunch of scripts that live inside in that case it sandbox environment same deal here with skill we're giving deep agent cli or claw code access to a directory of skills which can have anything we want in it we could just throw in scripts we could throw in files and using the native shell tool as well as file manipulation tools. The agent can read these directories, poke through them, run any scripts it wants. And this is a way to expand the action space significantly without loading up a whole bunch of different functions. Now, let's walk through this table. Why is that interesting? Well, let's say we want the agent to have five different actions. We can load those all as independent functions or tools. So, that means they get bound to the model itself. And typically what happens is when you bind a tool to the model, you bind the full tool description. And this can be quite tokenheavy, particularly if you have like say hundreds of tools. You're binding all those tools as well as their descriptions. Now with skills, the nice thing is you're only supplying that YAML front matter. It's a quick summary of when to actually use the skill, which really just means when to actually read that full skill.mmd file to find out what it's really all about and what to do. So that YAML front matter really provides the agent with a clue about when to go ahead and execute the skill by reading that full skill.mmd file. Now, here's the thing that's really not. If you bind a bunch of additional tools to your model, could be via MCP, could be via handrolled tools, you're bloating up that tool calling space. So you think about an agent has access to some number of tools. It has to make a decision at each turn about what tools to use. If you bloat up that tool calling space, it can get more confused. For example, you can bind two different tools that are very similar to the agent. It won't know which one to call. This happens a lot. People often talk about oh should I bind what happens when I bind 20 tools 50 tools 100 tools to a model and some people even flex that oh okay my agent has 100 tools what you're seeing with more state-of-the-art agents like maniscloud code is actually small number of tools less than 20 but give it access to file system where it can just execute where it can use its bash tool to execute scripts if it needs to perform additional actions. The point is that skills are a nice way to expand the action space of your agent without actually bloating your function calling layer, which is very important because more functions mean more tokens and function descriptions, but also more cognitive load on the model itself. It has to choose what tool to call at what turn. The more tools you add, the more potential for confusion. Now, what's the catch here? Well, the catch is you need access to a file system. So, there's a very nice write up I link here from Simon Willis talking about skills, and he highlights that really as a critical dependency, and I agree with that. that I mean listen you need to give the agent access to a computer and this is just a quick diagram summarizing all that from anthropic. So basically this is the context window of the LM this represents the agent system prompt and all these YAML front matters loaded up from any skills you give it. So this is this top thing is all the agent will see when it's deciding what skill to actually call. So here's a request just like we did perform web research. Here's an example request. In this case, Claude will say, "Okay, I'm aware of the various skills that I have. It looks like you want to do some PDF stuff. Okay, I have a PDF skill. I'm going to read in that skill. Cool." You can see it uses this native bash tool to read skill.md. Great. And then it's going to use this bash tool to read some additional file in that skill directory based on the initial instructions and so forth. So again, the idea is very simply my agent has access to the skills directory. You can use this native tools to read in skills based on the user's request. Now, if you look in the deep agents read me, you can look in this deep agent CLI folder. You can see we've updated our read for the deep agent CLI to include skills. And this is just one implementation of skills. It's all open source. You can inspect it if you want. And of course, there's other ways to do this. It follow exactly what we just talked about from anthropic. You can poke down here. You can see deep agents is just easily installable like this. Run it in your terminal just by calling deep agents. And if you want to inspect any skills, you can just run this command deep agent skills list. Back in my terminal, you can do that. And we can see when I run that, I can see I have these skills available. Project skills, global skills, and it shows the paths too. So the only difference is that these global skills are available across any project that I'm using deep agents in. They live in your home directory in deep agents. This is the default agent I'm working with. The skills directory and then the various skills folders. That's all we have. Very nice. And in this particular repo, I just have a test skill that I've added. You can see this is inside the deep agents repo and it's a project level skill. So the YAML front matter for all these skills at the global level and the project level will be loaded into the system prompt and the agent can decide which ones it needs to use. Again, we just saw it using this web research skill. We asked for a request related to web research and it followed the instructions in this skills directory and it followed the instructions in the skills.mmd file in this directory. If we want to see another in action, let me ask a question related to langraph. Create a langraph agent. Save it to agent.py. So I've added a skill called langraph docs. You can see here's that skill.mmd. The yaml front matter indicates use this skill for any request related to langraph to fetch relevant documentation to provide accurate up-to-date guidance. Down here, I basically give some instructions. First, use your fetch URL tool. Again, a built-in tool to the ad agent CLI. Read our LMS.ext file. Reflect on the request. Select a few different relevant URLs from this lm.ext. text to read, fetch them, and then use that to answer the question. You can open up this document and you can see there's just a list of documentation URLs and some little and a little bit of annotation about what's in each one. So, we can go back to our agent. You can see it read that skill.mmd file. That's great. So, it pulled in all those instructions. Now, it wants to read that element.ext file. That's great. I give it approval there. It reads that and it's going to it's going to reflect on that and then choose to read a few different specific documentation pages. That's fine. It's going to read the quick start, the overview. Good. I'll pull those in. It read the documentation. Now it's creating a file for me. This is cool. Called agent.py. And I approve that. Great. And it gives me a bunch of instructions. And we're done. So skills are a very easy way to expand the action space of agents. The key dependencies that you give your agent access to a file system. The deep agent CLI has one access to your local file system. So that's great just like cloud code. And two, it has a bunch of native tools built in allowing it to run bash commands, perform file manipulation, fetch URLs and so forth. So with those basic atomic tools, you can very easily create skills by creating a skills directory either at your global level or project level. And in that directory, just applying a skilled MD file properly formatted, which tells the agent what you want done. You can provide additional files. You can provide scripts and just give it instructions simply in markdown about what to do and it'll follow those instructions using it native tools. Very simple concept, a very nice way to expand the action space of your agent and doesn't require the complexities of tool calling. So hopefully this is a useful overview for skills and how they work and how we've implemented them and how we built them with the deep agent CLI. Thanks.