Templates and Components for Claude Code: The Future of AI Coding Workflows

Hello everyone, my name is Daniel Avila, and today I'm going to talk about templates and components for Cloud Code, the future of AI coding workflow. Before we get started, I'm going to share my social media accounts so you can follow me and check out all the content I share. Some of them are in Spanish, others are in English, but basically I'm sharing everything I've learned over the years working with different language models in code development.

A little about me. I've been working in technology for over 15 years and have founded two startups. I've also learned how to implement artificial intelligence in software development. And I've given many talks in different countries about AI agents and how to apply them throughout the entire software development cycle. This time I'm going to talk to you about Cloud Code, the settings you need to configure to apply this technology in a controlled and proper way. And in addition, we're going to talk quite a bit about the skills that by putting all these parts together allow you to build a complete template that you can then apply to different teams and also to different projects.

When you start with this technology, the first thing you should do is add an initial instruction to Cloud Code. We all start out this way, but we realize that after passing a lot of instructions, Cloud Code, it starts to lose focus a bit and begins to do things that it shouldn't be doing within our code base. And that's why we also start adding different components. In this case, we can add MCPs, which are basically connections with applications or with external text within our project. And in this way, we can execute some actions that are outside, or even extract information from different APIs, different libraries, and inject them into Cloud Code's context window using various MCPs.

On top of all this, we also have to add that we can set different settings. That means we can control the permissions that Cloud has to run within our code base. And in addition, we can give it permissions to run some tools from certain MCPs, or we can even set up Cloud Code to have different modes for working within our project, enabling auto mode or enabling plan mode. This makes the settings.json file extremely important, and we need to use it across different projects.

On top of that, there are some commands that are repetitive and that we basically take and put into certain files so the team can implement them. And so we don't have to repeat the same instruction over and over again. We create these commands and this way we can call and execute them whenever we need to during the development cycle. So far, we've already included quite a few components in this whole process. But don't worry, because there are still a few more to go.

To this, we have to add the sub-agents, which are basically a way to split the main context into different processes where these sub-agents will explore the code base, carry out certain tasks, and then return to the main context. They are extremely useful and effective for working with massive, complex code bases. These specialized sub-agents are constantly and consistently being utilized by Cloud Code, which is the main agent, in order to explore, analyze, and execute various commands in the background.

And finally, we get to the skills, which are a way to inject large amounts of context into the main context. Let's think of them as a kind of dictionary or documentation for the AI agents. They can go and look up different documents within these skills. And that's pretty powerful because we can load a huge documentation set from different libraries or we can even give it some processes for the agents to execute. In this way, we have a complete development template that Cloud Code should use.

We have initial instructions, MCPs, settings, commands, sub-agents, and skills. All of this together forms a template, and we should reuse it in different projects. There are many ways to share these components. Today, I'm going to show you the way that Anthropic and the Cloud Code community have been building a library of plugins or a component library with best practices so that developers can take these processes and run them in their projects. This is called harness engineering. All these concepts are part of this harness, which is basically about establishing a scope of work so that Cloud Code or all the AI agents working within the code base can have control and specific rails to execute their tasks.

Once an agent has completed a task, we need to review the logs using OpenTelemetry and then see how we can improve the process that this agent just carried out. There are many ways to do this process, and today I'm going to show you one of the most basic ones that I use all the time in my projects. Prior to setting up various processes and controls for the agents, we need to be exceptionally clear and precise about the different levels of configuration that we are currently implementing. We have the user level, project level configuration, and company or organizational level configuration.

And it's the one I use all the time in my projects. Prior to the point where we can actually begin to set up these various processes and controls for the agents, we need to be exceptionally clear and precise about the different levels of configuration that we are currently implementing and applying directly to the agents within our specific organizational environment. We have the user level, which will be applied to all the projects on our computer. It's simply a matter of adding all these configurations to the route of our project. We also have the project level configuration, which basically means adding the same configurations inside our repository so that in this way they're shared with our whole team. And finally, we have the company or organizational level, which basically means giving all the configuration to an administrator. And then this administrator at the organizational level starts adding these configurations so that they are applied within our projects and within our local configurations.

The first file, and one of the most important ones you need to keep in mind in cloud code, is settings.json. This file will allow you to save environment variables, attributes, permissions, all the MCP configurations. You can even configure different processes, for example, with hooks. Here we can see that hooks have a pre-tool use and a post-tool use. That means that every time Cloud Code runs a tool within the process of its context window, we'll be able to execute code, whether in batch or Python, so that this code runs before or after that tool is executed. And that already gives us a wide variety of powerful options to execute several essential cleanup and optimization processes for our project. We can even perform a thorough verification of the specific code that Cloud Code just wrote to see if it actually did it correctly or if it introduced any unexpected errors or mistakes. This is where projects can become deterministic, because artificial intelligence agents simply aren't and many times they're going to make mistakes. We have to keep in mind that we can run hooks so that these errors are minimized as much as possible.

And this is where we can create some templates and configurations so that the whole team can run them within the execution processes of agents that are cleaning up or working within our code base. We also have status lines, which are basically the area at the bottom of the input that's displayed within Cloud Code. And there are many other settings, for example, output styles, spinners. These are things you can share with the team or not, but I recommend that you read through every single field that are available in the setting.json so you know which ones you should share with the team and which ones you can configure yourself. Another very important file is cloud.md. This file will be the main file of your project. The first thing it'll do is check this file and it'll understand your project. By reviewing and reading every single word that appears here. This file is in markdown so we can review it ourselves as humans. And it's pretty easy to read and that's why. I recommend that you always read and update the cloud.md file. It can have some execution commands or it can include the entire project directory. I suggest you set it up following the best practices shared by the community. And you can also adopt all the best practices taught by the Cloud Code team.

Every time they update it with new models, this file is key. If you have it, you already have a large percentage of your project's configuration done, since cloud is the main file that will always be read.

And now let's move on to the skills. This file, skill.md is divided into two sections. The first is yaml and the second is markdown. We're going to go over each of these sections in this talk.

In this demonstration, we can clearly see exactly how the specific skill is automatically injected into an active cloud session whenever the user makes a detailed request that is directly related to the unique ability of this particular skill. Right at the very start of each new session, cloud will carefully look for all of the available skills that are currently located inside the specific skills folder of your project. And in this specific way, cloud will clearly know that it can effectively use these specialized skills whenever the user makes a direct request that is specifically related to this particular ability.

In this example, we can see that all the skills are injected at the start of the session, and then when the user makes a request, for example, to create a PDF, cloud will call the PDF skill and inject all the context from the cloud.md file so that the PDF the user is asking for can be created. And it's also very important that cloud can call reference files that are inside the skill.

Now let me tell you a bit more about how this mechanism works. But to get started with a skill, the first thing you need to do is create the name and the description. These two fields will be injected into the context window, and cloud will know that there is a skill that, for example, in this case, is setting up a stand up meeting. And in this way, when the user requests to create a stand up for the week or the day, cloud will call this skill and look at the description. It's very important that the description is perfect so that cloud knows when to call this type of skill.

In this case, the key detail in the description is when to use it. And we're telling cloud directly to use it when the user asks to set up a stand up or the plan or the planning for the day or the week. Once we've created the initial YAML, we need to write the instructions. And that's done in markdown format. That's really great because we can read this format and in this way we can understand what cloud is doing. So the markdown format is very easy to understand and grasp for both humans and agents.

The most fundamental front matter configuration that you need to establish inside of a skill is essentially comprised of both the specific name and the detailed description. But if we want to do something a bit more advanced, there are different fields we can add to this front matter. For example, when to use it. This specific description field is absolutely perfect for including a detailed contextual description of exactly when we need to pass the instruction to cloud so it knows precisely how and when to effectively execute and call this specific skill. We also have the arguments. Whenever you initiate a specific skill by using the forward slash command, you can provide additional arguments and parameters to this file that cloud will then automatically inject directly into the skill by utilizing the argument. Hence feature. You will be able to take advantage of auto complete functionality whenever you're calling this specific command.

Furthermore, with the argument field, you can conveniently and directly pass the argument name to seamlessly inject that specific value into the skill's context. I'm going to show you how that type of instruction works. We also have the disable model invocation. By utilizing this specific configuration field, you are given the ability to disable the model from invoking the skill, which effectively means that you can develop and implement skills that are only invoked by the user using the user-invocable field, or you can choose to manually and directly deactivate the model from ever invoking this particular skill. In this specific way, it is actually much easier to set up complex agent workflows because we clearly know there are some specific flows that the models themselves need to invoke during the conversation.

And then there are other distinct flows that the user should manually invoke during the course of the conversation. So when you are in the process of using and creating new skills for your team, it is important to think carefully about whether you need to make that skill self-invocable by the model itself or if it should instead be manually invocable by the human user. In addition to that, we also have the allowed tools field available, and this specific field lets you add various specific tools that Claude can then use within the context of that skill. This field is very important because if you don't add it, Claude will use all the tools it has available to execute the skill.

That means if you have MCPs, it's possible that a tool from one of these MCPs could get injected into the flow you created and that wasn't part of your original plan or process for the skill. So I always recommend adding the specific tools that are allowed to execute the skills you're creating. We can also add the model, effort and context. When it comes to adding the model, you might ask yourself, do I need a model that can reason? Do I need a model that's really good at executing tasks? Or do I just need a model that's very structured and can handle a very basic simple task? If you need a model that can do deep reasoning because the skill solves an important problem, I recommend adding the Opus model. If you need a model that simply executes a very well-categorized and designed task within the skill, but also explores and really understands what you're doing, I recommend adding the Sonnet model. And if you already have a very basic and easy to execute workflow, for example adding a message to a commit or adding messages to your PRs, I recommend using the Haiku model. It's much cheaper, much simpler and more basic to use. On top of that, it's very fast. So think carefully when you're creating your skills about which models should be used in this process. You can also add the effort field. This field allows for much more advanced reasoning. For example, if you combine the Opus model with an effort field set to high or max, the reasoning will be very advanced and a lot of agents will be activated to work within this process. If you're doing a very basic process, I recommend using Haiku with effort set to low. This way you can mix and match different ways to run a skill. It's very important that when you're creating it, you know exactly which fields you need to add to these from matter inside the YAML. For example, here we have a very specific YAML to create a message in Git. Right here on the screen we have the specific name, the detailed description, and the various hints or clues. Here are the actual hints and you will see that these hints will automatically auto-complete whenever the model needs to call upon this particular skill. Now I am going to give you a thorough demonstration to show you exactly how that process works in practice. In this skill, I'm going to show you how these fields work. For example, we have this skill with this name and we have this description. If we want to use it without the other fields, we simply have to delete it and we will have a clean description and name. If we want to call the skill, we have to enter cloud gold and start typing the skill name. Here we can see that the skill is not showing any extra fields. Now we're going to add the field argument hint. We're going to delete the others. And we're only going to leave this field. When we run the application once again, we can now clearly see that we have all the specific hint fields that we just finished adding inside the skill. Furthermore, cloud code automatically renders every single one of the configurations that we manually add within the skill interface. Now we need to add the following fields.

For example, the argument field. And this specific argument that we are passing right here can be easily called within the instruction simply by using the dollar sign symbol. It's really easy to build instructions when you're passing arguments inside the YAML. So keep in mind that every time you create a skill, you need to add the hints and then the argument. If you're going to use it within the hints, descriptions.

Lastly, let's add the other fields. Now I'm going to show you how to tell the difference between when the model is invoking the skill and when it's the developer doing it. If you navigate back to the interface of cloud and execute the specific skills command within the terminal, you'll be able to view a comprehensive list of every skill currently in your project as well as the various skills that have been made available globally. In this case, the ones labeled user are global and the ones labeled project are inside your project. You can also see the tokens that will be used.

In this case, it's only the description tokens and you can see all the descriptions and all the tokens that are already being used because they're being injected into club's context window. In this specific section of the interface, we are able to clearly observe whether the skill is specifically tied to an individual's account at the user level or if it functions directly during the actual model invocation process itself to better understand the scope of the skills application. Now that we've saved and added this field, let's see what changed. Skills again, and now we can see that it's only invoked by the user here. It says user only.

In this case, we're making it so that only the user can invoke the skill. If we remove this field, we'll see that this will change. We run skill again, and now we can see that user only doesn't appear unlike in this skill over here. In this case, it doesn't show up, and that means it can be invoked by either the user or the model. The model can also invoke it. And finally, this skill is only allowed to use the batch tools, and it's also running the Haiku model with low effort.

Now you might be wondering why that is the case. As I mentioned earlier, this particular skill is specifically designed for the purpose of crafting a message inside a commit. That means we do not necessarily require the use of a powerful, high-level reasoning model like Opus, and we also don't have a need for a very specialized model for these certain types of tasks. A bit more focused on programming and development within the codebase. Keep this in mind, it can save you a lot of tokens.

Now that we already have a general idea of how to build skills in both a basic and a more advanced way, we need to keep the context window in mind. If we manage the context window well in each of the sessions we have with our agents, we can understand when and how we need to inject these skills. In this case, Clod, it manages the system prompt, the cloud.md, the conversation history, and terms that are within the session, iterating with Clod and all the agents, plus the tools that are running, and the output from each of these tools. And also the files that Clod reads to inject context into this entire window.

And finally, we have a space where we can add context, either manually or with skills or sub-agents, or different ways to provide more context within the session. Here, we can see a typical flow of a skill calling different files. The skill is not just a from matter and the markdown. The skill also has references it can call if it needs to use other sources of information that will be inside the folder. In this case, the pdf skill is calling this file reference .md and injecting all the context from this file. It's also calling another file, which is form.md. And it's also injecting it into this context window to get more information according to the user's request. Skills can call many files, but keep in mind that they can also call files that are scripts, and when it calls, a script can read this file, or it can simply execute it. And this is very powerful because we can have a lot of scripts within our skill. And only Clod will read the output of these scripts. This means we can run many internal processes and Clod will be able to get the result of all these executions. We can also have references to many markdown files, or any other type of file. Clod will read these files and inject them directly into the context. I recommend that the references be in markdown because you also have to read them and you need to be aware of all the information you're injecting into the skills process.

And finally, we can add extra assets. In this case, they can be TXT files or any type of files you need to add within the skills processes. Here, we can see an example where we're running this file in Python to be able to read the output. It won't read absolutely all the information from the script in this file. And here we can see that Clod will read the file directly. The verb is very important. Here we're telling it to execute this file and here we're telling it to read this file. Finally, now we can understand how the entire flow works. The context we saw at the beginning. Where the skill was injected at the start of the session, now we understand it and we know when it happens. The model will call each skill either automatically or manually. And how will they navigate through all the references and the scripts that this skill has that you just put together? And that it's an internal process you have to manage in order to execute?

Here I'm sharing with you some skills that are incredibly well-made. Matt created this skill. He's one of the most influential engineers in the JavaScript field. So I recommend you check it out and try running it. But most importantly, I recommend that you go to Matt's GitHub and read the entire skill.

He shared all the processes and the entire workflow he's creating with his skills. This is another very important skill because it's made by the same company that created Cloud Code, which is Anthropic. And also, what are the processes being applied within the skill's instructions?

And finally, this skill. I've been using it since it works really well with your JavaScript projects. And it works quite well with absolutely all of them, whether it's Cloud Code, Codex, Anti-Gravity, Cursor, GitHub Copilot, or Open Code. I recommend that you check out even more skills by visiting this website. I made this website myself, and it's called Cloud Code Templates.

You can go to this address and you'll be able to see a huge number of skills. And the best part is that you'll be able to read the skills to understand how the community is building these skills and how they're working in many projects. You'll also be able to see how many downloads each skill has. And they're also divided into skills, agents, commands, settings, hooks, and MCPs. Take a look at this page.