WEBVTT

00:00:00.000 --> 00:00:20.655
I listened to Anthropic's engineers at the AI code summit and I learned something I wasn't expecting. Almost everyone is prompting Claude code wrong. So I decided to dig deeper and after studying everything Anthropic engineers have published, I uncovered four rules for how they actually prompt Claude code. And it turns out you don't need any technical experience to implement these rules. So rule number one is they prompt skills,

00:00:20.895 --> 00:01:02.530
not Claude. Before we get to the rules that will transform how you work, we need to understand the foundation of how they use Claude. Generally, when people first start using AI, they start writing new prompts for everything they do. But the reality is, most of what people do is repetitive tasks. So, Anthropic engineers created Claude's skills to help tackle these repetitive tasks. Here's them describing what they are and don't get worried about the technical terms. Skills are organized collections of files that package composable procedural knowledge for agents. In other words, they're folders. Barry describes it as procedural knowledge for agents, which is a fancy way to say a way to get a task done. And there's an art to actually creating these skills, we'll cover in rules two, three, and four. But first, you need to have the mental shift. Stop thinking in traditional prompts.

00:01:02.610 --> 00:03:30.785
Start thinking in prompting Claude skills. This may sound complicated, but it really, it's quite simple. Here's what it could look like if you wanted to draft a response to an email. Instead of you having a crazy prompt to help you respond to an email with your voice, your tone, and your writing style, you would just type slash draft email and then bring in the email you wanna respond to. So that's how you do it in practice, but conceptually, how should you think about this? I pulled this graph from the Anthropic engineering presentation and added a slight tweak to it. Layer one, you have the AI models. This is the AI that you're using. Layer two is you have the AI agents and the prompts. This is likely how you've been interacting with AI to date. But you wanna move up a layer to layer three, which is skills. This is the application layer of the AI world. If you were to compare this to your cell phone, Anthropic is building the phone itself. You have to create the apps. That's the layer to control. And before we get to how to best create these skills, here's a prompt you can run to help you identify these skills that are worth creating. So you're no longer writing custom prompts, you're writing more specific prompts that clearly reference skills. And this leads to the next topic which most people get wrong, which is how do you actually build a skill that works? Rule number two is skills are more than prompts. So you're convinced you need to change how you prompt to prompt skills. So the next question is how do you actually create skills that work? There's an art to this, lot like when prompt engineering went viral when ChatGPT first came out, and it's important that you get this right. The act of actually creating the skill is super easy. You can just write in Claude, build me a skill for x, and I'll just create a skill for you. But to use these skills well, you need to understand what's actually inside them. Because it's not just a prompt that lives in a folder. A skill is more than a prompt. Inside a skill, there are three layers. Layer one is the description. This is what Claude checks every time you ask a specific question and it determines if it should use the skill or not. Think of it like a title on a folder. If the label's vague, Claude's gonna have tough time identifying when to use it. If it's specific, it'll know exactly when it needs to use it. And yes, when you're prompting Claude, don't need to explicitly call a skill if it's properly described. Claude will automatically know when to use it, which is awesome. Layer two is the instructions. Once Claude grabs the skill, this is the playbook it follows. This is a step by step process on how to actually complete the task. And layer three are the tools it has access to. This is code scripts, API calls, reference files. This is where a skill becomes a lot more than prompts. And this layer three is where most of the leverage lives, but most people stop at that layer two. Here's Eric from the Anthropic team talking about exactly this. And I think maybe the funniest things I see is that people will put a lot of effort into creating these really beautiful detailed prompts.

00:03:31.745 --> 00:03:36.465
And then the tools that they make to give the model are sort of these incredibly bare bones,

00:03:37.185 --> 00:03:39.505
like, you know, no documentation

00:03:39.585 --> 00:03:47.000
func like the parameters are named a and b. Yeah. And it's kinda like, oh, like, an an engineer wouldn't be able to, like, you know, work with this as a Right.

00:03:47.720 --> 00:04:04.015
You know, work with this as if this was a function they had to use. People obsess over the prompt and skip the tools, the third layer of a skill. Anthropic engineers do the opposite. They focus on these tools. So instead of this whole back and forth, I created my own custom skill that could check these domains programmatically

00:04:04.015 --> 00:04:20.010
so that whatever domains it was telling me, it is already verified that I could go and buy it. So I gave this skill access to the right tool and it leveled up the entire process. And like I mentioned in rule one, instead of manually thinking about domains, I could have 10 different sub agents using this skill to look through 10,000

00:04:20.010 --> 00:05:17.575
plus domains to find the right one. Now I can do something that I literally would have never been able to do before. Here's a prompt you can use to think deeper about the skills you create so when you actually go ahead and prompt them, they'll be that much more effective. So rule number two covers how anthropic engineers make skills. But what skills do they actually create? Rule number three is they build composable skills, not custom skills. Pulling directly from Anthropic's engineering blog about what skills are and how to position them, they are composable, portable, efficient, and powerful. Composability means multiple skills can work together with Claude automatically coordinating which to use. What this means is you should have small, focused, and reusable skills that can work together versus having a single massive skill that does everything. A concrete example that I experienced when I first started building skills for my content engine, I built a single slash content creation skill that did everything. Generate ideas, wrote scripts, drafted social posts, all of it, one skill, a million possibilities. And it just became unmanageable.

00:05:17.575 --> 00:05:27.735
Every time I wanted to change how scripts were written, I had to rewrite the whole skill and I didn't know what it actually impacted. And so instead, I split it up to more specific skills. Right? YouTube idea research,

00:05:28.140 --> 00:05:30.860
YouTube script writer, LinkedIn post.

00:05:31.020 --> 00:06:04.940
Each skill had a specific goal in mind. And the benefit is that each can call the other skills so that they start chaining them together. This may seem a bit overkill, but it really isn't for three specific reasons. The first is that issues are easy to spot. When a focused skill breaks, you know exactly where to look. Whereas, if it's a giant skill, you don't know what exactly the issue was. The second is that improvements compound. If you update, let's call it YouTube idea research, every workflow that uses the same skill automatically gets upgraded. Whereas if you're using a giant skill, you're going to have overlapping functionality,

00:06:05.260 --> 00:07:24.010
which means you'll fix it in one skill and it will still be broken in the other. The third is that you can re instead of rebuilding. If you build something like the check domain skill I mentioned earlier, you can plug that into any workflow you want. You're not rebuilding the wheel every time with a new workflow. So you know you should break them up, but what's some more technical patterns that you should consider to make these even more powerful? So both of these come from directly how Anthropic engineers actually use them. So pattern one is save scripts inside of skills. This is part of the tools layer of a skill and it's how you actually make them sharper. Here's Barry at the AI Engineering Code Summit talking about how he does exactly this. We kept seeing Claude write the same Python script over and over again to apply styling to slides. So we just asked Claude to save it instead of the skill as a tool for his versions for his future self. Now we can just run the script and that makes everything a lot more consistent, a lot more efficient. Let me break down what he said. Claude kept rewriting the same Python script every session, and instead of them letting it rewrite it, they saved the script inside of a skill folder. So now the next session, Claude doesn't have to rewrite the script, it just reruns it. And this is so powerful because code is deterministic, which essentially means if you give it the same input, it will give you the same output every single time. Whereas in the AI world, that's not necessarily the case. It interprets it, it guesses, it uses tokens that cost money. And when you have a script inside a skill, you're trading AI tokens for code compute,

00:07:24.250 --> 00:07:54.940
which is cheaper, faster, and repeatable. A general rule of thumb is if you can use code instead of AI, you should. And you don't have to write the code, you can just have AI write it for you once, and then you can reuse it as much as you want. The second pattern is you can control who invokes what. Most people don't know this exists, but Anthropic built two flags into Claude's skills that are important to understand. The first is user invocable. If you set this to false, it hides the skill from your slash menu. It means that the user, you or me or whoever, can't directly invoke the skill. It's only a skill for agents.

00:07:55.020 --> 00:08:00.940
This is perfect for any AI agent specific tools that you don't even wanna think about. And then disable model invocation.

00:08:01.020 --> 00:08:42.285
This does the opposite. Only you can run it and the model can't. This is great for higher risk things like a skill that sends a message or deploys a new version of your code to production. Most of you watching this have likely never heard of either of those things, but now you have it in your bag when you're designing these skills. Here's a prompt you can run to audit your setup to make sure that you're properly applying these things into your skills. Screenshot this and just send the photo into Claude, and I highly recommend you do this. So you know how to build skills and what to build, but how do you make these improve over time? And before I get to that, if this is your first video of mine, welcome the channel. But if it's your second or more, here is our anti slop agreement. The visuals, the testing, the time I put into this video, that's entirely built for humans,

00:08:42.445 --> 00:09:08.035
not for AI robots or data scrapers. So all I ask is you subscribe as part of this agreement to help this content reach more people so I can keep making videos like this. Numeric number four is their prompts get smarter every session. Here's where Anthropic engineers really pull ahead. Their skills and, in turn, their prompting doesn't just work. They get better every session. When you prompt Claude with a sentence, that prompt advantages the moment you close the chat. When you prompt with a skill, the skill states,

00:09:08.355 --> 00:09:17.955
and every time you use it, you have a chance to sharpen it. Listen to their engineering team talk about exactly this. When you first start using Claude, this standardized format gives a very important guarantee.

00:09:18.195 --> 00:10:17.215
Anything that Claude writes down can be used efficiently by a future version of itself. Our goal is that Claude on day 30 of working with you is gonna be a lot better on Claude on day one. Every time Claude learns something about how you work, your voice, your process, your edge cases, you write it down in the skill. Next session starts smarter than the last. So how do you actually do this? Every time you run a skill and the output isn't exactly what you want, ask yourself one question. Is this a one time fix or should this be in the skill forever? If it's forever, update the skill. Add the rule, the example, the edge case. And a lot of people skip this entirely. They're just like, okay. Run the skill, get an output, like, continue with their day. But anthropic engineers use a skill, get the output, then update the skill so that there's a compounding loop that improves over time. And it's really quite simple. Like, it's literally you can just use your chat history as a reference point to improve the skill itself. Just say review the back and forth I just had after using this skill. Can we enhance the skill so this is handled automatically

00:10:17.420 --> 00:10:44.715
or we don't make the same mistake again? So zooming out, these four rules are clear. Use skills, not prompts. Build tools, not just skills with prompts. Build skills that are composable, not custom, and update your skills every time you use them. Using Claude like an engineer doesn't have to be complicated. And if you like this, you'll love this video where I break down how Boris Churney, the creator of Claude code, uses Claude skills. It's pretty wild and builds on a lot of what we covered here. I'll see you over there. Peace.