Matt Pocock's EXACT System To 10x Your Claude Skills transcript

Mattacott has the most installed Claude skills on the planet with over 22 million people using that. So I decided to do a deep dive in how exactly he creates his skills and the results shocked me. I went in expecting extremely complicated processes, but after analyzing every video he's ever posted and every skill he's created, I realized that he has a five-step process he uses to create every skill. But unfortunately, Matt's videos are extremely technical and the majority of his content is for engineers.

So in this video, I'll break down each of the five steps he uses to create skills, simplify it and then tell you exactly how you can apply this process in your day-to-day to make your skills better and build 10 times faster. And at the end of the video, I'll cover the reason why Matt thinks you should never blindly copy anyone else's skills. The step one is about notice and this is the thing that you keep sending back.

Now, I've heard a lot of breakdowns on what a Claude skill actually is, right? It's a reusable prompt. It's a process of teaching Claude something new and these aren't wrong, but Matt has one of my favorite definitions that I've come across. A skill is a correction you got tired of making. Here's someone on podcast explaining exactly this. >> Uh I went to a restaurant and I ordered a chorizo salad and I got a chorizo sandwich.

Right? So I had to send it back. And what I was finding is I was just having to send things back all the time to AI. >> Said another way, the key reason to create a skill isn't what you do most often with Claude. It's what you keep having to correct. If the model can already complete a task correctly the first time, a skill for that is just unnecessary bloat. And that's actually part of the reason why the creator of Claude code told people to go delete all of their Claude skills.

If Claude already gets it right, the skill isn't doing anything except costing tokens. With Matt's framework, he's essentially saying if Claude doesn't get it right the first time, send it back. And this kind of remind me of that scene in The Office where he says, "I'll have the spaghetti with a side salad. If the salad is on top, I'll send it back." It's that same Michael Scott energy. If the model gets it wrong, create a skill so you stop having to send it back.

But the question is, why do you have to keep sending things back when the model gets better and better. Matt has a specific answer for that and he calls it an asset rush. >> It has a little bit of what I'm going to call an asset rush. It's rushing towards creating an asset. It's like a premature completion. >> In plain English, this means the models are trained to finish, to produce something right now. The framework I like is think about models as an over eager student.

They raise their hand, the answer's ready before it's even sure if it's correct. So, when doing this for yourself, be mindful to avoid rushing steps end to end. When your skills aren't focused on a single step of the process, that lands you in the danger zone for this asset rush problem. More bluntly speaking, if you don't do this, you'll generate AI slop. So, the mental shift here is this. Throughout your day, stop asking yourself "What did I use AI for?" and start asking "What did I have to send back?" And then once you do that, you then say "What specific step of the process was that?" So, here's a prompt you can run right now to scan your conversation history for the past 30 days and flag places you send something back to see if those candidates can become a skill that's reusable.

So, at this point, you know what requires a skill, but how do you actually create one? Step two is about using leading words where you borrow a word the model already knows. When you create a skill, you want to avoid starting from scratch or re-explaining something Claude already understands. LLMs have so much training data that there are specific words called leading words that immediately direct Claude to pull from its massive training data.

So, if you choose the right word, the one the model already knows deeply, you radically simplify the whole entire skill. Here's Matt again explaining it and if it sounds technical, don't worry, I'll simplify it right after. >> Refactoring is such an old book, such a well cited book that these uh kind of smells are deep in the agent's priors. >> So, what he's actually saying is simple. Just by saying the word refactor, to pull from its billions of lines of training data specifically about refactoring code.

And the alternative in this case, let's say you're trying to explain to Claude what refactoring is, you're starting from scratch. And the reality is this is a lot of wasted effort, the output won't as good, and this is what a lot of people actually do. The model already read all the information. You don't need to re-teach it. You just need to use a specific leading word to point it in the right direction. Here's how Matt put it in his own words.

A made-up word recruits no priors. You pay in definition tokens what a pre-trained word gives free. Logically this should start making sense, but what are some other leading words? Here are some of the words that Matt uses in his Grill Me skill. He uses relentlessly. This shows up in both the description and the very first line. This single word is doing most of the work in the entire file. He used decision tree, which is decision branching into other decisions hanging off them.

Work the tree in rounds, not one question at a time. And then frontier. Every decision whose prerequisites are already settled. Okay, it should start making sense, but how do you apply this to your day-to-day? Identify what you're actually trying to do and consider if there's already a leading word for it. There are a ton of established frameworks the model is already trained on. You just have to point it in the right direction.

So before you write a skill from scratch, ask Claude directly, is there an established framework or term for what I'm describing? Then you'll just use whatever word it gives you instead of your own clunky description. For example, on screen are a bunch of leading words that apply to totally non-technical workflows, but here are some of my favorites. You have a smart goal framework which will help you set achievable goals.

Steelman, which argues the opposing case. Premortem, imagines it already failed. Bluff, puts conclusions first and then spin discovery, ask pain point questions. And here's a prompt you can run to audit your own setup for missing leading words. So you've got the trigger and the word. Now before we get to the part that everyone messes up including me, which is step three, we've covered the power of skills in this video, but one limitation is video generation, which brings us today's video sponsor AI Cove, an AI video company out of Germany.

If you've ever played with AI video, you know one of the biggest problems. You get a amazing clip and then you generate the next clip, and either the characters look entirely different, or the room changes, and suddenly the whole story kind of falls apart. And so, AI Core has fixed that with something they just launched called reference mode inside their Cinema AI Engine. And the character consistency that this establishes is a major unlock, because once your characters and locations stay the same from the first frame to the last, AI video stops being this cool clip generator, and it instead becomes something more than that.

You can create full-length documentaries or music videos from a single idea in the future. I think that everyone's actually going to have their own personal documentary, and this is something that would have just never existed before. Now, that's just one impact this feature has, but two other features have surprised me. The first is that you can stay in control of the creative direction. AI Core will suggest the references in the video, but you can add your own.

So, you could add a specific prop you want to keep coming up, or a visual style for the entire video. The camera, the color, the whole look, you can set this yourself. And now, the second it takes you from idea to finished video. So, with one click, you can generate a script, a voice, and the visuals. And now, for me, this isn't about replacing creativity, it's about expanding it. It lets you tell stories, make fun ads, and try concepts that you never could have made on your own before.

And this is flexing a creative muscle that way too many people neglect. So, to go use reference mode, check out AI Core in the first link in the description, and use code Austin to get started for free, and get an extra 10 credits. Now, getting back to step three, less is more. Make skills smaller and harder to use. This is the part of the research that surprised me the most, and there are two things going on here. The first part is a skill length.

On screen, you can see Matt Grillme's skill. It's seven lines, 22 words. That's it. This single skill has 1.1 million installs. So, clearly, skills don't need to be long to be effective. Here's Matt talking about that directly. >> From this, skills don't have to be long to be impactful. You've just got to choose the right words for the LLM at the right time. >> This quote builds directly on what we just covered with leading words, but now we're looking at the skill as a whole, not just one line or one word inside of the skill.

The second part is making them harder to use. For every skill, you can actually enable or disable Claude's ability to call it automatically. This is called model invocation, and all it means is can the model use the skill without you telling it to. And on the surface, it feels like you want the model to be able to use the skills, right? That's why you're creating it. But when you actually look at Matt's skills, he has disabled the ability for models to call them, essentially saying a human has to call this skill.

And when I dug into why, I found two tweets that explain it perfectly. First is the reasoning itself, cognitive load versus context load. Cognitive load lessens over time as you get better, context load costs you tokens forever. If you let the model auto-invoke skills, each of those skill descriptions gets loaded into context on every message you sent. That costs you tokens on every single run. If you remove that ability, you remove the constant contextual load, and it forces you to think about when to use a skill.

And over time, this makes you better at using AI, and in turn fights intellectual obesity, a concept you guys know is so important to me. Then in that tweet, he lays out the actual benefit of doing it this way. One benefit of being a primarily user-invoked skill set is that we get rid of a whole category of errors you never need to worry about. Did {slash} two spec fire? Why did {slash} two spec fire there? Why did it choose two tickets instead of two spec?

You stay in control, plus it means most of the skills don't cost any tokens until you invoke them. So, Matt is intentionally making these skills harder to use on purpose, so the model literally can't call them without him. And from my own experience, I've definitely seen the downside of not doing this. Claude will just automatically fire a skill that I didn't want it to, and it'll in turn slow down the whole process or trigger something that's totally unnecessary for what I'm actually trying to do.

So, here's how you can apply this. Here is a prompt that simplifies your existing skills and flags which ones are good candidates to make user-invoked only. And now, before we get to step four, this is our anti-slop agreement. Everything in this video is built by human for humans. So, all that I ask is that you subscribe to help this content reach more people. In every video, I give away a Claude Max subscription as a thank you for everyone who supports.

So, shout out this video's winner, journeymengeorgie7000, for building a project management software. And to enter this video's giveaway, comment with what you're building, and let's chat about how skills can help that. Step four, iterate over time and don't overthink if it's working. So, you've written your skill, it's short, it's got the right leading word, but is it working? Did your changes help the final result?

How do you even measure that? This is where most people mid-curve the whole skills thing. They get worked up trying to quantify whether a skill has improved or not, and that's exactly why this step in Matt's process is so refreshing. Matt doesn't quantifiably measure whether a change made a skill better. He mostly goes by vibes. Here's him talking about exactly this. Actually, at least, you know, in terms of vibes. I'm not doing evals here.

Maybe I should be doing evals on this particular case, but what I'm seeing is that people aren't reporting this anymore. Guy with 22 million installs has no testing setup. He uses the skill himself for about a week and just watches whether people stop complaining. Now, sure, you won't have as many testers as Matt does, but the stakes are just as high for you in your own world. And he still just goes by vibes. So, to do this testing yourself, you don't need to go crazy trying to evaluate whether a skill is improving.

You just need to use it and run what I'll call the send it back test. If you don't have to send back the result, the skill is working. It's really that simple. And when you're making skills, don't try and be perfect on version one. Perfection is the enemy of good. Good is good enough. Just the skill you write, just iterate from the first version. If you break down how some of Matt's most famous skills got built, every single line tells a story.

On screen, here is a history of the change log for his skill. "Give your recommended answer" was added because conversations were dragging. "Ask one question at a time" was added because firing off multiple questions was bewildering. What a great word, bewildering. "Do not enact the plan until I confirm was added because the agent kept skipping ahead and just building and split facts from decisions was added because the agent started grilling itself.

None of that was planned in advance. Each line is something that broke got noticed and was fixed with a one sentence addition. So wrapping up the step there are three things to actually do. The first is run your skill on real work not test cases. The second is at the end of the week have Claude analyze your conversation history for anything you sent something back and turn recurring corrections into a one sentence fix.

And then three once you have that fixed stop and try again. Don't add anything you haven't personally watched fail. So at this point you'll keep iterating and improving your skills which creates a new problem that nobody warned you about. Step five you need to cut it. Everyone treats a skill like a thing that only ever grows. Nobody schedules the day to make one smaller and honestly this is a step that I forget all of the time.

Matt's most engaged post about skills isn't even about writing. It's about deleting. Check for lines like be thorough. They're no-ops. Try removing that. Does the output change? No, then the line was a no-op. Agent authored skills are littered with no-ops. In plain English go through your skill one sentence at a time and ask yourself would Claude have done that anyway? If the answer is yes, the line is decoration and Matt calls these no-ops and they're costing you tokens to say absolutely nothing.

And so the decision you have here is you can be precise or aggressive. The precise version go line by line, remove the line you suspect is a no-op, run it again and if the output didn't change it was never doing anything in the first place. The aggressive version which I personally prefer is just have Claude scan the whole thing for no-op language and delete those words. Then just see what happens. And so either way there are a couple of rules when you're cleaning up these skills.

The first is delete the whole sentence. Don't just trim words out of it. Then say what you want not what you don't want. Words like don't do this drags the banned thing right back into context. Matt has a line on this where he says, "If you say don't think of an elephant, and then suddenly the elephant is all that's there." Just by saying the word elephant, you've already put it in the model's head. So, how does Matt apply this himself?

He's constantly shortening and deleting skills, and he's just as careful about creating new ones. His rule is, "If you can compose the behavior from existing skills, then don't create a new skill." You can apply this thought process by first doing a full audit of your skills for no-op lines, then deleting whole sentences. And then two, by checking if your skills overlap, then condensing them or cutting them entirely.

On screen, you can see a prompt that will help you do both of these. So, let's recap all five steps. The first is notice what you keep sending back to identify where you need skills. Two is use leading words the model already knows to simplify your skills. Three, keep skills small and make them harder to auto-invoke to avoid bloat. Four is iterate by using the simple send back test, and five, cut the no-ops before you ever add something new.

There's one thing that Matt said that reframed the entire video for me. >> AI has eaten tactical programming. It's gone. There's a sort of crisis of responsibility when it comes to working with AI, which is that people fire off these things, they merge into main, and then no one is responsible for it. You know, it's the AI who did it, wasn't me, it was not my code. >> So, he's saying that AI ate the doing, but it can't remove ownership.

The reality is it comes down to people, and you have to own your process, and a skill is the way to do that. And as a result, you do not get anything out of blindly copying other people's setups, because you don't have a deep understanding of how it works. And Matt agrees with this. He said this while replying to someone who called his skills awful. Most folks should write their own skills and own their own processes.

So, don't blindly copy things. Instead, create your own using the five-step framework we've covered in this video. Now, once you do that, you may have a problem where you say, "I send back a ton of things. Where do I start?" So, to solve that, check out this video, where I break down exactly how Entropic's own team uses skills. That'll inspire you on exactly where to start. And if you like this video, I guarantee you'll love that.

I'll see you over there. Peace.