Skills in Claude Code Desktop: Architecture and Execution Runtime

Hi everyone, how you doing? My name is Daniel Avila, and today I'm going to talk to you about skills in Cloud Code Desktop. Before we get started with the talk, I'm sharing my social media, so you can follow me. Here you'll find all the content I share daily. You can check it out on these social networks, and I also post different articles. I also have blogs and several open source projects you can check out.

A little about me. I've been working in technology for over 15 years, developing software, working for various companies, and I've also founded two startups. I've traveled to many countries speaking about AI agents, software development, using different language models. This time, we're going to talk very clearly about Cloud Code Desktop. This platform is basically Cloud Code, but running inside a user interface that's really easy to use. This platform is relatively new, since Anthropic launched this new platform just a couple of months ago. But today I'm going to tell you how it works, how to use it, what features it has, and most importantly, we're going to talk about how to run and install skills within this platform.

You can go to Anthropic's documentation, and you'll be able to download this platform, which is available for both macOS and Windows. You can even download it by scanning the QR code I'm showing on the screen. Scan this QR code and directly download this platform. The very first thing that you'll notice right away when you download this platform is the main chat window. This is the standard regular cloud chat interface, which is exactly the same familiar one we see every time we go to the cloud.ai website. It functions in the same way you'd expect. Throughout this interactive chat experience, you'll be able to engage directly with the capabilities of Cloud, seamlessly integrate your own NCPs, and also incorporate a variety of distinct contexts within the specific sessions you run with Cloud.

You can select different models, and it's exactly the same as what we use when we access the mobile app or even the cloud website. The next section is Cowork, and this one is a bit different from the chat. In Cowork, we can run projects that we have on our computer. Cowork runs with Cloud SDK. That means it comes with all the power of cloud code, but within an interface that we can manage and run. This interface has different ways to operate, for example by creating projects or setting up scheduled tasks.

We're not going to go over Codework this time, because what we're interested in is the last tab, which is Cloud Code. In Cloud Code, we can run projects that we have on our computer. This one is a bit different from the chat. In Cloud Code, it's exactly the same platform that we run both in the console and in this user interface. We can create a new session by selecting this button right here. We can create routines. That means cloud will run at a specific time and day and will execute a task. And we can also customize the workspace environment with different skills, connectors, which are the MCPs, and also different plugins.

But first, I'd like you to see how this technology works. In this case, I can create different execution environments. These can be local environments or cloud environments, like the one I'm showing now, where you can select network access, add environment variables, and also different scripts that will run in this cloud environment. You can add different folders and select the branch you'll be working on if you have GitHub connected. You can also run Word 3. And finally, different types of execution. Plan mode, auto mode, ask permissions, all of it is included in this interface. You can also talk to cloud by selecting your microphone. And you can also select different MCPs within the text input section of Cloud Code.

And you can also select different MCPs within the text input section of Cloud Code. The models and effort are also available in the interface. So you have absolutely everything you need. You can even see your usage within your Cloud Code session, whether it's the current session or the whole week. Within the bar, inside the menu, we can see the different sessions and whether each of these sessions has been merged. You can split sessions to run many of them in parallel.

I can even show you here that I can split into three different views, so you can run cloud in one view and run cloud in another. Other views within the same execution. You can even create different panels that operate independently from the main application. Each panel has different functions. You can even see the plan that's being executed and the background tasks, which are pretty hard to see in the console. Here you have everything within the user interface.

In this specific view, you can even see the full diff, including all the individual files and every single one of the changes you currently have in your local Git branch compared to the changes in main. You'll be able to thoroughly review them all right here in this dedicated section. You can also customize Cloud Code desktop sessions by going into the customization section, where you'll see the skills. These are skills installed in the cloud, and you can browse through all the components and references these skills have.

You can even see the connectors, which are basically the MCPs. You'll be able to approve the tools for each of the MCPs, and you can even block entire tools. And finally, I'm going to show you the plug-in section. You can browse through many available plug-ins, and we even have plug-ins from Anthropic and Partners. These are skills, MCPs, hooks, and various settings that are all packaged within a single plug-in, and with just one click, you can install absolutely everything. The best part is that it's very user-friendly, and you can even see what's inside the plug-in.

In this case, we have a skill where we can view the code in markdown, and we also have an agent where, just like before, we can see the code, even the AML, which is available right within the Cloud Code desktop interface. And now that we have a very clear understanding of exactly how the entire platform works, we must always keep in mind that there will constantly be a specific context window being managed by the underlying model throughout the duration of the whole session. This context window has a system prompt, the cloud.md file, the conversation, and all the turns of iteration that have gone through the model, and all the messages you sent in.

The latest models are reaching up to a million tokens, so we have plenty of space to send even more context so cloud can understand our entire project. But that doesn't mean we should send absolutely all the information possible. The more context you provide, the worse the performance gets. The primary reason for this is essentially because you're introducing an excessive amount of unnecessary noise into a session, and the cloud system begins to become quite confused and gradually starts to lose sight of the specific details of the task you assigned it. And that's why skills exist. Skills are files inside the .cloud.com folder. Skills give cloud instructions on how to perform certain tasks. You can even add much more documentation within these skills so that cloud can navigate through all this documentation. This is what it looks like when a skill is injected into the context window of a cloud session. We can see that we have many different skills that are automatically loaded when you start a session.

This is what it looks like when a skill is injected into the context window of a cloud session. We can see that we have many different skills that are automatically loaded when you start a session. And whenever you request that cloud assist you with a task related to these particular skills, cloud will automatically invoke the precise and specific skill that performs this task and will thoroughly search through every single reference it needs to successfully execute it. The skill has two very important fields that are in YAML. The first is the name that cloud will define and find in order to call this skill and also display it in the interface. And the second is the description that cloud will read and use to make a match when the user requests a task related to this description.

Then the skill is written entirely in Markdown. That means it's very easy for humans to read. We can read it, understand it, and modify it. I recommend that you read absolutely all the skills you have installed in your project. Skills, besides the name and description, have many other fields. I recommend that you review absolutely all the fields so that none are left out in the execution processes you're building with your skills. Some of them are quite important. For example, allow tools. This field is very important because you need to provide the tools that cloud needs to use during the reading process of the skill.

For example, if you have an MCP that runs some specific tools, you should add those tools in this field of the skill so that cloud knows it can use them when it calls that specific skill. In this case, I can show you a slightly more advanced skill. We have the name, the description, the argument, and the description. We have the name, the description, the argument. Since skills can receive arguments that come from the chat and that each user will add within the context of the skill, and in this case, we're giving it the batch tool, that means cloud can only run batch commands when it executes the skill.

That's actually very important to remember because if we don't provide the specific field, cloud essentially has the full power to run any tool it wants. This means if you have an MCP that's going to do something similar within the skill, it can run external tools. When building your skill, be careful to add all control measures for precise execution. The process of executing a skill involves progressive disclosure, with cloud reading the description first to call the skill.

After calling the skill, cloud reads the markdown only from the skill.md file and directly references other files if required. Scripts, references, and assets can be added, dictating the execution based on provided instructions within the script. Cloud Code Desktop allows calling skills added to .cloud/.skills, appearing automatically in the interface. Ensure detailed descriptions and triggers with keywords for skill loading accuracy.

Creating interfaces step by step is recommended, adding checkboxes or guides for task execution. Careful consideration of steps, references, and building workflows by calling one skill from another is crucial for comprehensive skill development.

This execution will depend entirely on cloud and the instructions you provide within the script. For example, if you call this script, cloud will read the entire script. But if you tell cloud that the script should only be executed, cloud will run this file in Python and will only read the output from this file. We can conserve a significant amount of tokens if we provide cloud with highly specific and detailed instructions right within our skill.md file.

But what happens inside Cloud Code Desktop? We can also call them since every time we add skills to this file in .cloud/.skills, they will automatically appear in the user interface. If you use the slash command, you'll be able to see all the available skills. And you can even see the description directly in the interface. These are the specific rules I always use to load different skills.

First, you need a really good detailed description. Because if you don't clearly specify exactly when it should be used, this skill will simply never load correctly and cloud will never be able to read it at all. We need to have triggers with keywords so that cloud can understand and know when and how to load. Keep in mind that some skills are very similar and if you keep adding different skills, some of them might end up doing exactly the same thing as others.

When you're creating the interface inside the body, follow step by step the tasks that cloud needs to perform. It's a really good practice to add checkboxes. Or add a step by step guide where you tell cloud it can execute step 1, step 2, and step 3, which can be optional or not. I recommend that you think carefully about the steps you're building into your skills. You also need to add the references. These are simply files and documents that will be inside the skill.md markdown file.

One skill can call another skill so you can create complete workflows. One skill can build a specific reference for a certain knowledge group and another skill can have a different reference for another knowledge group. By combining these two skills, you can create complete workflows that work together. So you shouldn't put all the references into a single skill. You can play around with this too.

Keep in mind that scripts, as I mentioned earlier, are a way to make script executions a bit more deterministic. Not everything is markdown. Not everything is instructions. You can add a variety of different custom scripts that build a specific workflow with code. It can be Python, Batch, or JavaScript, and efficiently gather all the necessary information. As I mentioned before, it is essential that you always remember to add the specific tools that need to be executed within the script inside the skill. This ensures that every part of your automated process runs smoothly and effectively.

As I mentioned before, always add the tools that need to be executed within the script. The cloud will thank you for it, since it won't look for any other external tool and will only run the one you're providing. And finally, test how this skill works directly. Test phase 1. Test phase 2. You can open different sessions and run cloud while another cloud instance is reviewing the skills and making a decision.

One of the most critical and important things that you absolutely need to keep in mind when you are using skills in MCPs is that you must clearly separate the specific responsibilities of each and every one of these individual components. Skills should be detailed step-by-step instructions that you carefully provide as essential background information to the model to ensure it follows your specific guidance correctly. And the MCPs should be direct functions and tools that are executed and have a single responsibility to perform that function, not to provide information or documentation. This should represent the entire, complete process that a specific function should ideally execute when working with a particular skill.

First, the user should make a request. The skill should be loaded with all the information it contains. By carefully extracting the information from its references and also from its scripts, this data must then be successfully passed directly to the model and the model will systematically search for and identify the specific tools it needs to run the model context protocol server. In this case, we could call different databases, different APIs, or any external resource using the MCP. And the skill will manage the conversation context and, in addition, all the extra references and documentation we want to provide to the session.

When we didn't have skills to be able to add this extra context to the MCPs, we had to do these kinds of practices within the function of an MCP. For example, consider this specific function designed for getting the weather. We had to meticulously add the complete detailed documentation on exactly how the tool works, including what it's used for, how to use it properly, the specific parameters, the individual arguments, and the exact return value that this tool sends back. Absolutely all of this comprehensive information went directly inside the model context protocol. But when skills came along, we were able to separate these responsibilities. The MCP was left with only one responsibility, which was to provide the information from a function. In this case, getting the weather only includes the argument the function receives and the function's return value. There's no extra documentation inside this function, because we're providing all that documentation in a specific skill. In this case, a weather analysis skill, where it will explain how to use the MCP tools and also provide all the documentation this MCP needs. So it can be executed within a session.

Finally, we're able to have a process like this. The user makes a request or asks a question, the model reasons and calls the MCP, executes the tools, and finally the model is able to send a direct response to the user. And finally, the easiest part, which is installing a skill. There are different platforms that let you install skills. Even the marketplaces we saw earlier inside Cloud Code Desktop can be used to install them just by running a few commands within your Cloud Code session. For example, plugins marketplace add and the repository you want to install, where this marketplace is full of plugins, skills, hooks, or MCPs. But there are also these websites where you can search for different skills and install them. For example, this page is from Vercell, which you can visit at skills.sh and you just run this command depending on the skill you find on this website. There's also this page that I created to be able to bundle many skills and different components. This page is called AItemplates.com and the repository is called Cloud Code Templates on GitHub. Inside this repository, you'll be able to find different skills, agents, commands, settings, hooks, and MCPs. You can also find different marketplaces if you're looking for official Cloud Code marketplaces. I recommend you check it out so you can see which skills are available and how to use them in Cloud through the console and also in Cloud Code Desktop. Lastly, I suggest you look for skills in different GitHub repositories. For example, this skill is from Gary Tan, the CEO of Y Combinator. This skill is extremely good, so I recommend you give it a try. It's very easy to install. Gary even added these instructions where you just have to copy the entire text and give it to Cloud Code. Cloud Code is very, very smart and will know how to install different skills, even if you give it an incorrect instruction. It'll ask you and say, are you really trying to install a skill? It looks like the instruction isn't quite right.

I'll install it anyway. In this case, it's a complete instruction. And the most interesting part is that, besides installing the skill, it will also modify the cloud.md file. Essentially, that means it is already a complete and full installation right within your specific work environment. Not just located in the cloud or skills folder, but it is also actively making significant changes in various other areas within the current Cloud Code session.

Plus, it even clones the entire repository. That's a really smart move by Gary, so I want to congratulate him for adding this instruction. We can even see here that he's adding the MCP tools that will be used within the skills. Like I mentioned before, the tools are really important for the skills to run properly, and Gary understands that perfectly, which is why he added the tool directly in this section.

Take a look at this. This is exactly how I went about it to install Gary's skill. What I did was simply open up the Cloud Code desktop application, pasted the full text right in, and then Cloud Code started the process by cloning the repository first. After that, it automatically began installing all of these various necessary subdirectories and folders within the user-level installation of the skill and deep inside the project itself. It's amazing what you can do with Cloud Code just by adding or sending it text in natural language. And that was it.

I hope you enjoyed this talk and that you keep using Cloud Code Desktop. This platform is just getting started, and there are lots of improvements coming all the time. I recommend you follow me on Twitter since I'm showing how to use it, what the best practices are, and how to enhance your sessions with different skills. I also share a ton of open source repositories where I teach how to use skills in Cloud Code Desktop as well as different anthropic technologies. Thank you very much, and see you next time.