Transcription
After the last video, a lot of people have been asking me what skills do I use when building applications when I'm inentic engineering. And I'm going to give you those skills. I'm going to give you my agents.mmd file, but I'm going to share with you the thought process, how these tools work, so you can use them effectively when you're doing your agentic engineering. Let's get straight into it.
So, I have three skills that I use. Nothing crazy. I have a code structure skill, which is my own that I developed. I have a GP loop skill, which is skill by Greal, my code review agent, and code simplifier, which is a skill by Claude. I'm going to share with you all the skills. It'll be linked in the description and I'll explain how each works. But I also have an agents.mmd file.
Now, one thing you'll notice is there are a lot of videos where they'll pit skills versus agents MD like one's better than the other. I use both. And the reason why I use both is both do different things. For example, with skills, skills are on a need to know basis where agents.mmd file is given to the agent every single time. Let me explain this step by step.
With skills, for example, you need to know how a skill is architected, how it's written. A skill has metadata, it has the instruction, and then it has resources. Forget about resources. I want you to focus on metadata and instructions. The metadata often looks like this. A name and then a description. The name is the name of the skill and the description describes what the skill does, right? And then after the metadata, the name and the description, then come the instructions. Basically telling the agent how it's supposed to do whatever it's supposed to do. For example, I have a YouTube analytics skill and it basically pulls uh clicks from dub.sh and it pulls stuff from notion and it pulls analytics from YouTube and it does some math and it presents to me a report. I created a skill for that. But what's interesting is all skills are structured the same. Name, description, metadata and then everything below that is an instruction.
Now this is very important. Let me just show you a real life example. So this is my code structure skill and if I go to code right here you'll see the same structure. This is the metadata and then everything under the metadata is the instruction. The reason why skills are powerful because they are a need to know basis. Skills aren't injected the entire skill isn't injected in the context. What's injected in the context is the metadata. I'll explain this clearly. If you're confused don't worry I got you. Let's go to OpenAI's tokenizer. And this is all going to make sense.
Now, whenever you create a markdown file and you tell the agent to read the markdown file, the entire markdown file is going to be in the context, right? So, let's say this skill that I have, this entire file, let's say I put this in the context of the AA agent, right? That's about 944 tokens, right? It's not a lot of tokens, but it can it can add up, right? Imagine in every chat conversation you have, you're adding 944 tokens to the agent. Now, what if the only thing in context was the name and the description? That's what makes skills awesome. The only thing, you can see the token difference from 944 to 53 tokens. The only thing injected in the context of the AI agent of the model when you're using skills is the name and the description. The reason why this is awesome is because I have more context window, right? I'm not wasting my context window. And the reason why I say it's a need to know basis is because the model only invokes the instructions when it knows it needs the skill.
So a perfect example I can give you is I have this skill right here, right? code structure. And if we look at this skill, basically what it does is it rewrites the code in a service layer architecture, right? This is in a way a a very clean pattern for code to be written for the agent to continue to understand even for me to review. Right? So this restructures the code that the agent has generated because most of the time agents are just generating slop code. This structures it. Let's say I wanted to run the code structure skill. The basically the way I would do it is I can show you an example here is I would just run slashcode structure and I would just hit enter. And in doing that the agent basically calls the skill file reads the instructions. Right? All it has in its context is the name and description. It reads the instructions and then it knows what to do. That's what makes skill so powerful. It's on a need to- know basis, right?
When you hear the word Daytona, you probably think of fast cars. When I hear it, I think of the most performance sandbox provider. And that is confirmed by this benchmark by Compute SDK. When you flip through all the different benchmarks, all the different tests, one thing that you see in commonality is Daytona is number one. And this isn't me just trusting a benchmark. I use Daytona in this app called Feedback. This is an internal tool for my product studio. It's basically our own internal vibe coding tool. And Daytona is the sandbox provider that powers this app. And what I'm going to do is I'm going to test this project in a Daytona sandbox. All I have to do is click test in sandbox. You're going to see how quickly it's going to spin up a sandbox instance. It's going to fork the project. It's going to install all the dependencies and it's going to test if this application is working by running a build. That literally took 30 seconds. I'm now going to click create app. And what I'm going to do is I'm going to open up an instance of the app. So, it's going to set up a new sandbox and preview environment. It's going to install a selected agent. I have Open Code as the default agent. And you'll see in just a few seconds, I'll be able to give feedback. In just a few seconds, I have my application running in a sandbox with an Open Code agent. I can see the files here. I have access to a terminal. This is the terminal running in the Daytona sandbox. I also have live diagnostics. All of this is possible thanks to Daytona. Check them out in the link in the description down below. If you use my code, you get $100 free credit. Make sure to go check them out.
So, I want my agent to be able to know how to structure code. I want my agent to be able to run a loop with Gravile so he can review the code and get a five out of five score. I want my code to be simplified so I use these skills. And again, all of these will be linked in the description down below and I'll explain them in a second.
Here's what's interesting about agents MD. They're very different from skills because the agent MD file is injected in the context window every single turn. So, if we were to think of this as the context window, let's say this is a 272,000 context window, you know, you have the system prompt and all that like internal stuff the model has and then the agents MD and then the conversations, right? The back and forth that I'm having with the model. With skills, the only thing that gets loaded with skills is the name and the description. And again, I showed you the difference, right? If I loaded the entire skill, it would be 944 tokens. But because we're just loading in the name and description, it's only 53 tokens.
With agents.mmd files though, the entire thing is loaded in the context at every turn. So we got to ask ourselves, what kind of files are we going to put in agent MDs, right? What kind of information, sorry, are we going to put in an agents.mmd? And for me, it's stuff that the agent needs to know all the time. So I have a specific branching and PR workflow. You can see here it says use staging as the integration branch for feature work. Create a feature branch from the latest staging, preferably in an isolated work tree under work trees. Open small focused PRs from each feature branch into staging. Do not merge unrelated feature work into another feature branch unless the PR is intentionally stacked and the dependencies real. Keep PRs reviewable for code review agent split by feature ownership boundary or behavioral surface rather than accumulating a large mixed diff. After a feature PR merges into staging, update any active feature branches from staging before continuing work. Promote staging to main only when the integrated set of changes is ready to for release. I need the agent to know this all the time. All the time.
And then another thing I have, I use this tool called open source. I actually did a video about it. I'll share with you right here. It'll be linked in the description down below. And basically what open source does is it downloads the source code of whatever tool I'm using in the codebase. For example, you can see here it's grayed out. And the reason why it's grayed out is this does not get pushed to GitHub into production. But I have a bunch of repos here. For example, browser use, Composio, uh, Daytona, Cross Mint, Open Claw, my my boy, uh, Christoi dropped an agent. I downloaded that here. Super memory AI. So all the tools that I'm using that are open source, I will have their code bases downloaded in this folder. And the reason being is because the models might not be trained on the most up-to-date information. I will tell the agent to reference the source code so it knows exactly what to look for. Now a lot of you think that it's going to have the entire codebase in context. No, the models have the ability to search, right? So if I say, oh, how do remote functions work in speltkit? It knows to search for remote functions. It's not going to go through the entire codebase, right? So this makes it very good for me to get up-to-date information to my agent and I tell it that it has access to this tool. This is something I want the agent to know every single time.
Now that you know the difference between skills and agents.mmd file. Skills are a need to know basis, right? Imagine I put my skill files in the agents.mmd. It it doesn't need to restructure the code all the time. It doesn't need to run a g loop all the time. It doesn't need to simplify the code all the time, right? I want the features to be done and I want to be able to trigger these things myself. The agents.mmd file, this is information I want the agent to know all the time. Now for you know for the love of all things do not put the codebase information that they don't say oh this is a react codebase the agent knows it can search the code right this is specific workflows that are not let's say the word natural to it that's what you're going to put in the agents.mmd file.
Now in terms of my skills code structure I explained this restructures a given piece of code in a service little architecture I love this I'll link it down below take a read at it. G loop is one of my favorite skills in pair with Greile. Now, Gretile does sponsor some videos, but this video is not sponsored. I genuinely love and use Grapile. And basically, what this does is I can give you maybe a very concrete example here, uh, PR right now. Okay, let me pull up this one right here. So, actually, this got a five out of five, so maybe let me pull up another one. Oh, this one has a five out of five as well. Uh, let's see if this one doesn't have a five out of five. Oh, this one has a five out of five as well. All my PRs are golden. Let's say I push a feature and I get a confident score of a three out of five. What I would do, and I have tons of examples here where you can see here I ran /grebloot128. That's the PR number. And basically what this does is it will you can see that it worked for 19 minutes, right? So what the skill tells the agent to do is it reads the PR information, right? The review that Greile left. And if you're wondering what information, I could show you right here. You can see like the summary and all that stuff it leaves. It also like leaves like comments right here. Like you you could see like, oh, highlights code, gives you comments. It even gives you the prompt to fix it. So, what the GP loop skill tells the agent to do is to pull all this information from the PR, analyze the information, push a fix, and once it pushes a fix, it waits for a new review. If that review is not a five out of five, guess what it does? It loops again. That's why it's called GP loop. And for me, this has been the best feedback loop ever, right? Because I will go back and forth, plan with the agent, build with the agent, tell the agent to build it, and then I will test the feature obviously locally. But after I've tested the feature, I want the coding agent to review it. And when it reviews it, it almost always catches some security issue, some bug. There's always something that gets caught. GPile gives the agent the feedback it needs. I then run gre loop and then it just loops it. Just loops it. Just loops it until it gets a five out of five. I did a full video on my workflow. I'll share it with you right here. It is fantastic, right? I love this skill.
And finally, the final skill. This is by Claw themselves by the anthropic team. And this is a code simplifier. Now, I run this every now and then when I'm just like looking at code and it just feels too complex and I'm not understanding what's going on. I just run code simplifier and it basically preserves functionality. It simplifies thing. It's actually a great skill to use. I use it based off vibes. I don't really have like a structure as to when and where I use it. But when I just feel like something's a little too complex, I use a code simplifier skill and it simplifies the codebase for me.
So there you have it. You have my skills. You have my agents.md. You understand what skills I use and how I use them, why I use them. You understand what's the purpose of an agent.mmd file and what information I have of it. Skills are on a need to know basis. agents.mmd or claw.mmd is you want the agent to know this all the time. Both are necessary. Both are important. This is how I use it. Let me know in the comments down below what you want to see next. Thank you so much for watching this video. Make sure to like, comment, subscribe, hit the notification bell. I'll see you in the next one. Peace.