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. 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. It becomes an engineering discipline focused on agents. All these concepts are part of this harness, which establishes a scope of work for cloud code and all the AI agents working within the code base. This process goes hand in hand with observability and improving the processes we're working with.

Prior to setting up processes and controls for the agents, we must be exceptionally clear and precise about the different levels of configuration we are implementing. User level, project level, and company or organizational level configurations are crucial. The settings.json file is fundamental in cloud code, allowing for the configuration of environment variables, attributes, permissions, MCP configurations, and processes with hooks. Hooks provide powerful options to execute essential cleanup and optimization processes, ensuring deterministic projects in the face of potential mistakes made by artificial intelligence agents.

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 root of our project. We also have the project level configuration, which basically means adding these 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 pretool 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. Projects can become deterministic since artificial intelligence agents simply aren't, and we can run hooks to minimize errors. This is where we can create templates and configurations for the team to run within the execution processes of agents working within our code base.

We also have status lines displayed at the bottom of the input within cloud code, along with other settings like output styles and spinners that can be shared with the team. It's recommended to go through every field available in the settings.json to decide which ones to share and configure individually. Another crucial file is cloud.md, the main file of the project, in Markdown format for easy readability and updates. It often includes execution commands or the entire project directory, following community and cloud code team's best practices for configuration. The cloud.md file plays a significant role in the project's configuration, being the main file always read.

The skill.md file, divided into YAML and Markdown sections, is key. It demonstrates how specific skills are automatically injected into an active cloud session upon a detailed user request related to the skill's unique ability. At the start of each new session, cloud analyzes available skills in the project's specific skills folder. This allows cloud to utilize specialized skills for direct user requests related to their specific abilities, enhancing the user experience and project functionality.

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. 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. 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. 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.

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 standup meeting. 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. 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.

And we're telling cloud directly to use it when the user asks to set up a standup 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 are 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 skills context. I'm going to show you how that type of instruction works.

We also have 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.

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.

It's much cheaper, much simpler, and more basic to use. And 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 autocomplete 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 code base. 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, CLAUD, it manages the system prompt, the cloud.md, the conversation history, and terms that are within the session, iterating with CLAUD and all the agents, plus the tools that are running and the output from each of these schools.

In this case, we can 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. It's essential to manage and understand when and how to inject skills into the context window effectively. The ability to call various files within skills, including scripts, enhances the power of the skill, providing access to a wide range of information and capabilities to enrich the user experience.

The skill is not just the 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.

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 CLAUD will read the output of these scripts. This means we can run many internal processes and CLAUD 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. CLAUD will read these files and inject them directly into the context.

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?

Python will 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 CLAUD 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.

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 skills instructions?

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, AntiGravity, Cursor, GitHub Copilot, or OpenCode. 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. I created it myself, and it's worked really well for me. I've been using it for a lot of projects.

Thank you so much. Once again, I'm sharing my social media, so you can check out everything I've been posting and all the articles and blogs that I share daily with all the information I'm learning. I hope this talk was helpful, and I'll see you around. Thank you all very much.

Hi, everyone. And welcome back. Hi, Daniel. Hi, guys. Thanks a lot for your talk. It's very significant and momentous. I think we all, as software engineers, we start to see that even in bigger companies, those best practices start appearing and centralizing. Thanks a lot from your perspective to help it in the other direction, from a community point of view. Amazing work, and thanks a lot for your talk.

I just want to remind you that if you want to ask someone, our speakers, a question, please join Slido.com and use the number 0607 for AI Core Coding Summit today. And ask anything our speakers today. While we're waiting for more questions to appear, we already have a few of them, maybe I'll start with my own question. That's regarding your famous repo and basically your experience with activities there. Do you see a lot of agents contributing or it's more like people? What is your experience with GitHub so far? I think right now everything is agents. Nobody is writing code. Nobody is writing skills. Everything is Cloud Code or Codex. So that's the reason that we need to check every single pull request from our repo. But right now we have two kind of contributions. The first one is people just sharing skills, sharing MCPs, sharing hooks. A lot of companies that they want to share different APIs and MCPs. And the other kind of contribution is loops. So there's a lot of loops running in the repo, improving different skills. So everything I already show you is related to loops, skills, and agents trying to share more data in the repo. So it's a little bit hard to try to keep everything in control, everything in my repo right now. But I have like five agents running and checking every single pull request.

So I think right now I'm doing really good trying to keep everything related to the repo and working with the whole contribution that I'm having.

Yeah, I see. I see a lot of agents contributing nowadays. Well, there are a few questions, as I said, in the queue already.

Let's start with the first one. By Alejandro and thanks for logging in, actually, in the system. That's a bit technical, but I think it is interesting from your perspective.

When should I use a sub-agent versus a skill using ContextFork? Yeah, that's a really good question because the ContextFork is confusing.

So when you need to fork your context and trying to work with a different context. So in this case, when you use a sub-agent, it's because you don't need the whole context in your main context.

You need that sub-agent working in a different session, in a different context. So in this case, you need to use a sub-agent. You can just create a new sub-agent, run with different skills, and just get the output from that sub-agent.

Noted. Thanks. And we continue with another question by Alejandro, actually. It's also in that direction. It's more how to change skills or compose skills depending on a concrete task. Would you suggest anything?

Again, what are you trying to achieve with your task? In this case, every skill that you are going to build, you can create reference, you can create scripts, you can create assets for your skill.

So the best way to do it depends on if you're going to run this task and what is your context window. If you are running isolate agent, who will be with one context windows, and you don't need to think a lot about that.

But if you're running in Telco, for example, you have to think you already have a full session with more context, with your whole code base. So everything is going to be in your context window.

You need to create your skill.md the smaller possible. If you have a really small skill.md, you can start to create different reference with more data, and you can create different scripts with more data, and then you can start to create this change of prompts to get more data. And you need to think in your skill.md like an index.

So everything is going to be in your context window. You need to create your skill.md the smaller possible. If you have a really small skill.md, you can start to create different reference with more data, and you can create different scripts with more data, and then you can start to create this change of prompts to get more data. And you need to think in your skill.md like an index.

So if you have that really good index to get and retrieve this data from your reference, that's going to be a really good skill because you can run it in your full session, and you can start to create different tasks for that skill. Thanks. I think that covers another question that was regarding the CloudMD without increasing too much the context window.

But if you want to add something to that question, please go ahead while also answering another question about CloudMD. Would it be more efficient to transfer the rules and guidelines from CloudMD into skills instead of maintaining them in rules and using skills to validate and apply rules? Yeah. So CloudMD is something that you always need in every single request that you are going to do to the LLMs. So think that every time that you ask something to your LLM, you're going to need that data in your request.

And the skill is just a specific task with that beginning and end. So if you have a task that you are doing every single session and you need to repeat for more people in your team, that you need to move from your Cloud.MD and create a skill for that. Something that you need to share with your team. Something that you need to share with more people. That's going to be a skill.

You don't need that data in your Cloud.MD because you're going to be adding more data to your context window, and you need your context window as small as possible to run your whole code base and your whole session. So think of your Cloud.MD as something like guidelines that you need to add to your session, simple and always remembered in every request. Your skill is just a task in a specific session, a specific task to create and share within your team. Sharing skills within the team based on expertise is essential for effective collaboration.

The need for summarizing threads and starting new ones in LLM's galicination process points towards evolving best practices. Continual improvement and creation of skills and agents are crucial in this evolving landscape. Reading and refining skills is a fundamental activity, akin to the iterative process of software development. Evaluating, updating, and aligning skills with new models are key aspects of skill management and development.

Continuous enhancement of LLM's and the associated skills is imperative due to the evolving nature of AI models by organizations like Entropiq and OpenAI. Regular evaluations, skill reviews, and adaptation to new models are necessary for staying relevant and effective in utilizing LLM capabilities. Emphasizing the importance of skill evaluation, refinement, and adaptation to keep pace with advancements in AI models and technologies is crucial for sustained success.

The next question is about LLM's galicination. There is observation that when the context window is about to complete, the Cloud starts to galicinate. I would assume there are already best practices appear to summarize the thread and start a new one. What is your advice on that? What is your take? I think that's the reason that we keep working in this harness. That's the reason we are creating the skills, that's the reason that we are creating some agents. And that's the reason that we need to read every single skill that we create. It's super hard because I was writing code, I was reading code for the last 15 years. And right now I'm reading and writing skills, markdown files. So my whole day is reading markdown files and creating a script to execute in these skills. So I think we need to keep working on this. It's a really early stage right now. And we need to keep improving the LLM's and also the skill that we run on top of these LLM's. So right now it's something that we cannot manage too much because Entropiq, OpenAI, they are building these LLM's. And every time that we have a new LLM, a new model, we can improve the skills and we can run different evals. But that's my advice. You need to run evals. You need to keep reading these skills that you have and improve with new models. Got it. Awesome.

I think we have maybe time for one last, maybe the last two questions. Well, the first one, someone is asking, maybe like a summary, what would you suggest to use MCP versus CLI? Which one is the right choice for the task? Yeah, that's a really good question. And right now we have both. We have CLI and we have MCPs in our work. I'm using a lot of CLI. Cloud code is amazing. So CLI is really good to create a different task in your work. But MCP, I think, is the future right now because not the whole users and people know what is a CLI. So if you need to share your work with more people, not technical people, you need an MCP. And you need to create your MCP because people are going to run these in chat GPT, in Cloud, not in the Cloud code. So they're going to use Cloud Chat.

They're going to use chat GPT. And if you want to share with more, not technical people, with the whole world your work, you need an MCP. Because it's a really good way to share your APIs, your work and connect with your platform. Right now we have both. So you need to think in technical people. CLI is really good. Non-technical people, MCP is really good.

All right. All right. That's very clear. I think we'll finish with that. Daniel, thanks a lot for your project. That's amazing. Good luck with the journey further and enjoy the conference.

Yeah. Thank you so much.