WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=UNzCG3lw6O0 NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/UNzCG3lw6O0.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:00.000 --> 00:00:07.640 Hello friends, I was dearly hoping to be able to come to the Air Engineer World's Fair, but family matters have intruded and I'm not able to make it. s2 00:00:07.640 --> 00:00:09.640 However, I will not be leaving you empty-handed. s3 00:00:09.640 --> 00:00:13.560 I'm going to give you the talk that I would have given in San Francisco. s4 00:00:13.560 --> 00:00:22.880 This talk is called The Missing Manual, How to Write Great Skills, and I think that the ability to distinguish good skills from bad skills is only getting more important. s5 00:00:22.880 --> 00:00:28.320 As developers, we seem to be pretty talented at finding different forms of hell for us to go to. s6 00:00:28.320 --> 00:00:40.280 In like a few years ago, we had tutorial hell, which is where you would go into a bunch of tutorials trying to learn something, not be able to piece it together, and sort of just get into this cycle you couldn't get out of. s7 00:00:40.280 --> 00:00:47.960 We had framework hell, where every other 10 minutes there was a JavaScript framework being announced, and you know, you had to learn the hot new thing all the time. s8 00:00:47.960 --> 00:00:51.440 And now, I think we have another version of hell, which is skill hell. s9 00:00:51.440 --> 00:01:01.880 Skill hell is where you have all of these skills available, freely available, that you can download, contribute to, you can figure out on your own, but you don't really know how the pieces all work together. s10 00:01:01.880 --> 00:01:04.199 You can't tell a good skill from a bad skill. s11 00:01:04.199 --> 00:01:10.160 And this means that people are trying to piece together these frameworks, trying to try everything that's out there all at once. s12 00:01:10.160 --> 00:01:15.280 And they sort of can't, or rather, they don't get the results that the skills themselves promise. s13 00:01:15.280 --> 00:01:19.440 This is true at an individual level, but it's also true at an organization level, too. s14 00:01:19.440 --> 00:01:28.720 Organizations have no way or no understanding on how to build good skills, how to take their operating procedures and turn them into things that an agent can do. s15 00:01:28.720 --> 00:01:33.400 you don't do that, then it's hard to get the bounty that skills can offer. s16 00:01:33.400 --> 00:01:35.320 Just one more skill, bro. s17 00:01:35.320 --> 00:01:37.280 That's kind of seems like what we're saying. s18 00:01:37.280 --> 00:01:45.680 And I feel a bit of guilt here, too, because we have Matt Pocock skills, which is my skills repo, which is one of the most popular engineering skill sets out there. s19 00:01:45.680 --> 00:01:50.000 And so, I feel like I want to help the people who use my skills get out of skill hell. s20 00:01:50.000 --> 00:01:50.720 So, how do we do it? s21 00:01:50.720 --> 00:01:51.800 How do we get out of this? s22 00:01:51.800 --> 00:01:54.520 Well, what is actually missing here? s23 00:01:54.520 --> 00:01:58.840 Well, in my opinion, the thing that we're missing is we don't know what makes a skill great. s24 00:01:58.840 --> 00:02:04.280 We can't yet look at a skill and go, "Okay, this skill is doing these good things and these bad things." s25 00:02:04.280 --> 00:02:08.520 There's no shared rubric, no framework for looking at a skill and making it better. s26 00:02:08.520 --> 00:02:10.479 And so, that's what I'm going to give you in this talk. s27 00:02:10.479 --> 00:02:20.520 I'm going to give you a skill checklist, a checklist of things you can look at inside the skill to make sure that it's doing what it says it's doing and ways you can improve it, ways you can write skills. s28 00:02:20.520 --> 00:02:22.120 This checklist looks like this. s29 00:02:22.120 --> 00:02:29.280 We start with the trigger of the skill, how the skill is invoked, and the decisions that you need to design there. s30 00:02:29.280 --> 00:02:35.000 Then the internal structure of the skill, how the skill is actually composed and laid out internally. s31 00:02:35.000 --> 00:02:38.480 Then number three is how do you actually steer using the skill? s32 00:02:38.480 --> 00:02:42.480 How do you get the skill to tell the agent what to do? s33 00:02:42.480 --> 00:02:45.959 Then four, how do you make the skill as small as possible? s34 00:02:45.959 --> 00:02:53.520 Because once we've got a working skill, we then need to basically maximize it, prune out all of the irrelevant stuff, prune out all of the no ops. s35 00:02:53.520 --> 00:03:03.200 There's one handy advantage of me not being in the room with you, which is you can immediately go and try this out because I've encoded all of this into a new skill in my repo called writing great skills. s36 00:03:03.200 --> 00:03:10.880 So, if you've got an immediate use case for this, then just go to this my skills repo, you know, just close this browser, get out of here, and go and use this skill s37 00:03:10.880 --> 00:03:14.200 to either improve your skills or write great new ones. s38 00:03:14.200 --> 00:03:15.560 But, let's now go through the checklist then. s39 00:03:15.560 --> 00:03:19.120 We have number one, the trigger, the way the skill is invoked. s40 00:03:19.120 --> 00:03:26.200 And in order to talk about this, I'm actually going to do a bit of comparison here, which is that my skills are often compared to another set of extremely s41 00:03:26.200 --> 00:03:28.800 popular engineering skills called superpowers. s42 00:03:28.800 --> 00:03:32.880 And I'm really often asked the question, "How do your skills compare to superpowers? s43 00:03:32.880 --> 00:03:34.239 What's the difference between them?" s44 00:03:34.239 --> 00:03:39.519 To understand that, we need to understand the difference between user invoked and model invoked skills. s45 00:03:39.519 --> 00:03:43.160 Anytime you have a skill, you can always invoke it manually. s46 00:03:43.160 --> 00:03:49.160 So, the skill sits on your file system, the agent will just be able to pull up the skill and understand what's in there. s47 00:03:49.160 --> 00:03:52.440 And you can always do that by communicating that to the agent. s48 00:03:52.440 --> 00:03:58.120 Doesn't always look like this forward slash depending on the harness, but that you can always use or invoke your skills. s49 00:03:58.120 --> 00:04:01.320 Another way that skills can be invoked is by the agent itself. s50 00:04:01.320 --> 00:04:04.720 These are called model invocable skills or model invoked skills. s51 00:04:04.720 --> 00:04:19.760 You can take a description, so the description of the skill always ends up in the agent's context, and the agent can look in that and go, "Okay, based on that description, I'm going to invoke the skill and I end up reading the skill.md s52 00:04:19.760 --> 00:04:23.200 file, which is where the meat of the skill is, into my context window. s53 00:04:23.200 --> 00:04:24.440 That's how you invoke a skill. s54 00:04:24.440 --> 00:04:26.320 That's what happens when a skill is invoked. s55 00:04:26.320 --> 00:04:29.360 So, this description serves as a kind of context pointer. s56 00:04:29.360 --> 00:04:35.760 It sits in the agent's context pointing to another file where the agent can go if it wants more context. s57 00:04:35.760 --> 00:04:39.720 But, that context pointer, you don't need to put it into the agent's context. s58 00:04:39.720 --> 00:04:45.320 It can just be invisible from the agent, and that is what we call a user invocable skill. s59 00:04:45.320 --> 00:04:50.960 So, some skills can only be invoked by the user because they don't have this context pointer. s60 00:04:50.960 --> 00:04:51.520 It's optional. s61 00:04:51.520 --> 00:04:55.680 For instance, we can see in my code base design here, this is a model invocable skill. s62 00:04:55.680 --> 00:04:58.680 It has a description that ends up in the agent's context window. s63 00:04:58.680 --> 00:05:04.200 But, if we look at my grill me skill instead, we can see it has disable model invocation true. s64 00:05:04.200 --> 00:05:07.680 This means that this little description here will only show to the user. s65 00:05:07.680 --> 00:05:09.120 It won't be visible to the agent. s66 00:05:09.120 --> 00:05:10.760 So, this then is tip number one. s67 00:05:10.760 --> 00:05:14.360 Decide if your skill is user invoked or model invoked. s68 00:05:14.360 --> 00:05:17.200 Now, you might think that model invoked skills are better, right? s69 00:05:17.200 --> 00:05:20.720 Because either the model can invoke it itself or the user can invoke it. s70 00:05:20.720 --> 00:05:22.080 It's more flexible. s71 00:05:22.080 --> 00:05:31.320 But, every time you add a model invoked skill into your agent's environment, it increases what I'm going to call the context load on that agent. s72 00:05:31.320 --> 00:05:39.760 It adds a new description, which is costing you tokens on every request, but also adding a different thing for the agent to think about. s73 00:05:39.760 --> 00:05:45.840 So, if you have a hundred model invoked skills, that's going to be a hundred descriptions inside the context for your agent. s74 00:05:45.840 --> 00:05:53.000 So, it seems to make sense then to either tamp down the number of model invoked skills or to just use all user invoked skills. s75 00:05:53.000 --> 00:06:00.360 But, user invoked skills have a different load, which is the more user invoked skills you have, the higher cognitive load on the user. s76 00:06:00.360 --> 00:06:06.960 In other words, the more things the user needs to keep in their head, the more skill you require from the pilot. s77 00:06:06.960 --> 00:06:13.280 And so, if we compare Matt Percot skills to Superpowers, Superpowers is primarily model invoked skills. s78 00:06:13.280 --> 00:06:16.080 It gives the agent superpowers. s79 00:06:16.080 --> 00:06:20.160 Whereas my skills, I much prefer to be in full control. s80 00:06:20.160 --> 00:06:27.000 That means I get to keep the context load on the agent as small as possible, but it does impose more of a cognitive load on me. s81 00:06:27.000 --> 00:06:31.480 So, I need to understand the skills really deeply in order to get the most use out. s82 00:06:31.480 --> 00:06:32.360 So, why have I done this? s83 00:06:32.360 --> 00:06:34.919 Why did I prefer user invoked skills? s84 00:06:34.919 --> 00:06:41.880 Well, every time you have a model invoked skill, it basically you get a cost in unpredictability. s85 00:06:41.880 --> 00:06:51.800 Because every time you have a context pointer pointing from one resource to another, the model may just choose not to follow it, you know, even if it's absolutely perfect for the task, s86 00:06:51.800 --> 00:06:55.120 it may just choose not to invoke the skill. s87 00:06:55.120 --> 00:07:06.320 I much prefer removing that level of unpredictability, imposing a bit more cognitive load on the user, and what you get is just you're removing a class of problem from even being a problem. s88 00:07:06.320 --> 00:07:16.120 Because this unpredictability leaves people to need to eval their skills to make sure they're being called at the right time, which is really nasty and it's a problem I prefer to avoid. s89 00:07:16.120 --> 00:07:22.000 But, what I'm hoping to show you here is that model invoked skills and user invoked skills both have their same costs. s90 00:07:22.000 --> 00:07:24.840 So, it's not an easy decision which one you choose. s91 00:07:24.840 --> 00:07:28.120 So, that then is the trigger, how the skill gets invoked. s92 00:07:28.120 --> 00:07:31.880 Now, let's talk about the structure, the internal layout of the skill. s93 00:07:31.880 --> 00:07:36.840 I think of there as being two main units that you need to put into most skills. s94 00:07:36.840 --> 00:07:40.640 These two units are the steps and the reference. s95 00:07:40.640 --> 00:07:49.600 The steps are the step-by-step procedure that the skill is going to walk through and the reference is any supporting information that helps it walk through those steps. s96 00:07:49.600 --> 00:07:58.040 You can have skills that have no steps and are only reference and you can have skills that are no reference and only a set of simple steps to walk through. s97 00:07:58.040 --> 00:08:03.520 But if you start thinking of skills as composed of these two units, it really helps just break them down a lot more. s98 00:08:03.520 --> 00:08:10.800 If we look at an example, one of my skills called 2 PRD creates a product requirements document out of the current context window. s99 00:08:10.800 --> 00:08:12.760 It's got three steps in it. s100 00:08:12.760 --> 00:08:17.600 So it finds the relevant context, it confirms the test seams with the user. s101 00:08:17.600 --> 00:08:24.440 So there's like a little human in the loop checkpoint there just to make sure we're not doing anything weird with the testing, which I find really important. s102 00:08:24.440 --> 00:08:26.560 And then we write the product requirements document. s103 00:08:26.560 --> 00:08:31.080 To handle those three steps, we've got two bits of reference material. s104 00:08:31.080 --> 00:08:37.599 We've got a little bit of reference on what is a test seam and then we've got a product requirements document template. s105 00:08:37.599 --> 00:08:42.280 So just a literal markdown template which is used to write the PRD. s106 00:08:42.280 --> 00:08:45.160 So this is a great way to write a skill from scratch. s107 00:08:45.160 --> 00:08:55.120 You work out if you need some steps, then you write those steps and you work out what reference material those steps need and you put it in a separate little spot in the skill, which is for reference material. s108 00:08:55.120 --> 00:09:04.600 However, there's a really important constraint that we need to think about, which is tip number three, we want to make the main skill.md file as small as possible. s109 00:09:04.600 --> 00:09:11.600 Every skill is composed of its description and then a skill.md file and then any reference material that branches off that. s110 00:09:11.600 --> 00:09:16.320 And this skill.md file, if we make it small, then we're saving in a bunch of different ways. s111 00:09:16.320 --> 00:09:21.720 Smaller skills are just easier to maintain, easier to audit, fewer words to think about. s112 00:09:21.720 --> 00:09:28.640 And every time you shave off a word, that is a token shaved, that multiple tokens shaved from your skills cost. s113 00:09:28.640 --> 00:09:33.839 So I do believe that small skills are really important both for maintainers and for users. s114 00:09:33.839 --> 00:09:41.960 One really useful way you can make your skill smaller is by thinking about the different branches of the skill, the different ways the skill can be used. s115 00:09:41.960 --> 00:09:48.960 Because if you have reference material that's only used in one branch, then that's a candidate for being removed from the main skill.md. s116 00:09:48.960 --> 00:09:56.280 For instance, if we look at my 2PRD here, we have two pieces of reference material, what is a test seam and the PRD template. s117 00:09:56.280 --> 00:10:05.840 Well, we need the PRD template every single time because we are always creating a PRD and we probably also need the what is a test seam information every time because we're always s118 00:10:05.840 --> 00:10:07.600 asking about the test seams. s119 00:10:07.600 --> 00:10:15.600 So, 2PRD, there's only one branch and all the reference material belongs on that branch, so it probably also belongs in the skill.md file. s120 00:10:15.600 --> 00:10:20.880 However, if we look at a different skill of mine, which is domain modeling, domain modeling does two things. s121 00:10:20.880 --> 00:10:27.200 It updates a local glossary called context.md and then it also creates architectural decision records. s122 00:10:27.200 --> 00:10:37.080 In other words, it's doing two different things or it might actually choose to do neither of these, in which case it doesn't need the template and it doesn't need the ADR template, either. s123 00:10:37.080 --> 00:10:47.760 So, in other words, domain modeling has two or maybe three branches and this means that we don't need to include the ADR template or the context.md template into the main skill. s124 00:10:47.760 --> 00:10:50.000 They can be moved into separate zones. s125 00:10:50.000 --> 00:11:01.680 The way you do that is you have the skill.md file, then you put it behind a context pointer and you point the context template to a separate markdown file inside the skills folder. s126 00:11:01.680 --> 00:11:08.400 That context pointer literally just says, "If you need the template or if you need to update the context.md file, go to this file." s127 00:11:08.400 --> 00:11:10.920 And I call that an external reference. s128 00:11:10.920 --> 00:11:19.280 It's a reference that's external to the skill.md that you can just easily reference the agent can pull in very easily because it's bundled along with the skill. s129 00:11:19.280 --> 00:11:26.600 So, this is a technique you can use for making the skill.md as small as possible, which is has so many benefits. s130 00:11:26.600 --> 00:11:29.760 Hide branching reference material behind context pointers. s131 00:11:29.760 --> 00:11:38.280 In other words, if you feel like your skill is going to be used in lots of different ways, then take the reference material that's relevant for those branches and hide them behind context pointers. s132 00:11:38.280 --> 00:11:39.680 So, that is structure. s133 00:11:39.680 --> 00:11:43.240 We need to think about making the skill.md super duper small. s134 00:11:43.240 --> 00:11:48.360 We need to think about the branches in our skill moving material out behind context pointers. s135 00:11:48.360 --> 00:11:53.600 And we need to think about steps and reference, which are the two main units inside a skill. s136 00:11:53.600 --> 00:11:58.800 Let's go next to steering, the actual ways we get the agent to do what we want it to do. s137 00:11:58.800 --> 00:12:05.760 And for me, steering comes down to one really cool technique, which is the kind of main thing I want you to get from this talk. s138 00:12:05.760 --> 00:12:11.480 This technique fixes this issue, which is the agent doesn't do what I want. s139 00:12:11.480 --> 00:12:16.800 In other words, I specify something in the skill, I think that I've been clear, and then it just doesn't do the thing. s140 00:12:16.800 --> 00:12:22.880 Now, I think the main reason this happens is because you're not using a technique called leading words. s141 00:12:22.880 --> 00:12:33.560 The idea of leading words, or light vert if you like literary theory, I suppose, is that there are certain words that pack in a bunch of meaning into a very small space. s142 00:12:33.560 --> 00:12:47.560 These leading words are really powerful with agents because you put the leading word in the skill itself in the text, and then the agent will repeat the leading word back to itself as part of its operations, as part of its thinking tokens, s143 00:12:47.560 --> 00:12:49.480 and as part of its output to you. s144 00:12:49.480 --> 00:12:57.680 And then, because it's re-emphasizing that word and that word hopefully describes what you want from the agent, that then goes and changes its behavior. s145 00:12:57.680 --> 00:13:00.200 Let's make this more concrete with an example. s146 00:13:00.200 --> 00:13:06.240 So, let's imagine that we have a problem, which is a classic problem with agents, which is that they code layer by layer. s147 00:13:06.240 --> 00:13:15.880 In other words, if you give them a big tranche of work to do, they will generally code up all of the database layer, then all of the schemas, then all of the API endpoints, then all of the front end. s148 00:13:15.880 --> 00:13:24.920 They don't do the sort of typical um human thing, which is to seek feedback early on, get something small working, and then expand out from there. s149 00:13:24.920 --> 00:13:32.960 Now, we can try to encourage the agent to do that by just saying, you know, don't code layer by layer, Um make sure that you create a small slice first and then go from there. s150 00:13:32.960 --> 00:13:35.040 But what if instead we use the leading word? s151 00:13:35.040 --> 00:13:38.640 We said, "vertical slice" is our leading word. s152 00:13:38.640 --> 00:13:44.120 We want to slice up the work instead of horizontal slices into vertical slices. s153 00:13:44.120 --> 00:13:52.560 A vertical slice is a pretty well-known terminology in development, and so this will hopefully trigger the agent's priors and it will understand what we mean. s154 00:13:52.560 --> 00:13:56.320 We don't just have to like have a two-word skill where it just says vertical slice. s155 00:13:56.320 --> 00:14:02.720 What we're doing is we're packing lots of meaning into a relatively short phrase that we then repeat throughout the skill. s156 00:14:02.720 --> 00:14:13.200 The cool thing about this technique is you can know if it's worked because you say vertical slice in your skill, and then you'll notice in the reasoning traces that it's saying, "Okay, we're going to do this as a thin vertical slice." s157 00:14:13.200 --> 00:14:15.640 Then you should get better implementation plans. s158 00:14:15.640 --> 00:14:20.160 Everyone I've explained this technique to sort of feels like, "Oh yeah, I've been doing that for a while. s159 00:14:20.160 --> 00:14:25.600 I've been using these little phrases to try to encourage the agent to do what I want." s160 00:14:25.600 --> 00:14:34.600 All I'm asking you now is to use those consistently within your skills and watch in the thinking traces as the agent adopts your way of doing it. s161 00:14:34.600 --> 00:14:52.440 So often if the agent isn't doing what you want, you need to make your leading words more consistent, more powerful, and look for others because, you know, English is a pretty wide API in terms of different functions you can call, different things you can experiment with, and there are many leading word candidates out there. s162 00:14:52.440 --> 00:14:54.920 And agents are actually pretty good at helping you think of them. s163 00:14:54.920 --> 00:15:01.960 Another little lever you can use with agents is sometimes the agent just doesn't do enough legwork. s164 00:15:01.960 --> 00:15:12.839 What I mean by this is that, okay, we're on a step, let's say, and maybe the step is to ask clarifying questions or to explore the code base, and the agent just doesn't do enough of it. s165 00:15:12.839 --> 00:15:15.839 It doesn't put enough effort into that particular step. s166 00:15:15.839 --> 00:15:22.000 A real classic case of this and something that I have found almost everywhere it is plan mode. s167 00:15:22.000 --> 00:15:24.240 Because in plan mode, we have two steps. s168 00:15:24.240 --> 00:15:28.240 We have ask clarifying questions and then create a plan. s169 00:15:28.240 --> 00:15:36.600 And what I have found in every single implementation of plan mode I've tried is that ask clarifying questions just, you know, it doesn't ever do enough legwork. s170 00:15:36.600 --> 00:15:46.640 It sees that its ultimate goal is to create a plan and so it just does a small amount of legwork with ask clarifying questions, ask you a couple of things, and then eagerly creates the plan. s171 00:15:46.640 --> 00:15:48.360 So, what was my solution here? s172 00:15:48.360 --> 00:15:55.720 Instead of doing plan mode, I instead have a skill called grill with docs, which is kind of my ask clarifying questions phase. s173 00:15:55.720 --> 00:15:58.960 And then, I split that up into a separate skill. s174 00:15:58.960 --> 00:16:02.160 So, I split the planning into its own skill. s175 00:16:02.160 --> 00:16:08.000 So, grill with docs now is its own skill where the agent only sees that part of the process. s176 00:16:08.000 --> 00:16:12.320 And then, after grill with docs completes, we then go and do 2 PRD. s177 00:16:12.320 --> 00:16:18.040 In other words, we have step one and step two, but the agent only sees one step at a time. s178 00:16:18.040 --> 00:16:25.960 So, this is a really cool technique for increasing legwork on the step that you're on by hiding the future goal, hiding the future steps. s179 00:16:25.960 --> 00:16:37.080 It's not always necessary to split skills into individual steps, but in particular cases where you really want an extra chunk of legwork, it really there's no technique like it. s180 00:16:37.080 --> 00:16:38.160 It works very, very well. s181 00:16:38.160 --> 00:16:47.880 So, that is steering using leading words to capture what you want in small reusable tokens and then making sure that it's doing the right amount of legwork per step. s182 00:16:47.880 --> 00:16:50.240 So, let's head now into pruning. s183 00:16:50.240 --> 00:16:55.320 Now, pruning really is just a quick fire set of failure modes, different things that you can get wrong. s184 00:16:55.320 --> 00:17:00.120 And the first is fairly obvious is we do not want massive skills. s185 00:17:00.120 --> 00:17:04.560 Massive skills are usually a kind of symptom of something else going wrong. s186 00:17:04.560 --> 00:17:06.959 So, a symptom of one of these other failure modes. s187 00:17:06.959 --> 00:17:08.920 And the first one is pretty simple. s188 00:17:08.920 --> 00:17:10.640 Don't repeat yourself. s189 00:17:10.640 --> 00:17:13.360 You need to make sure you're watching out for duplication. s190 00:17:13.360 --> 00:17:19.280 And in general, I like to have every part of the skill to have a single source of truth. s191 00:17:19.280 --> 00:17:32.520 In other words, if you have a piece of reference material like the PRD template, let's say, or something even smaller like what is a test seam, you make sure that you don't repeat that in several places or like cover multiple steps in multiple places. s192 00:17:32.520 --> 00:17:38.720 Just make sure each part has a single source of truth and you're not repeating yourself even across reference material, too. s193 00:17:38.720 --> 00:17:41.720 The next way that skills get big is via sediment. s194 00:17:41.720 --> 00:17:52.680 And sediment is just a classic thing when people are working on the same set of docs, really, which is that everyone starts contributing to a shared markdown file. s195 00:17:52.680 --> 00:17:53.880 People add their own stuff. s196 00:17:53.880 --> 00:17:57.160 They don't feel brave enough to delete and modify anyone else's. s197 00:17:57.160 --> 00:18:05.160 And so you just end up with this huge amount of sediment with often irrelevant material for the skill, especially stuff that hasn't been laid out properly. s198 00:18:05.160 --> 00:18:08.480 With a skill with a lot of sediments, you really need to look at structure. s199 00:18:08.480 --> 00:18:10.000 That's the first thing you need to do. s200 00:18:10.000 --> 00:18:13.920 You need to make sure that the stuff that's been added is relevant for all branches. s201 00:18:13.920 --> 00:18:16.360 If it's not, then move it into the correct branches. s202 00:18:16.360 --> 00:18:20.440 Or if it's just totally irrelevant, maybe just remove it or kill it. s203 00:18:20.440 --> 00:18:24.400 Or maybe there's stuff in there that's totally stale, in which case you just need to kill it dead. s204 00:18:24.400 --> 00:18:30.360 The next failure mode is really common when an agent writes your skills, which are no-ops. s205 00:18:30.360 --> 00:18:38.120 So things inside the skill that appear to do something but don't actually influence the agent's behavior inside the context of the skill. s206 00:18:38.120 --> 00:18:45.520 Let's imagine we have an implement skill and we have an entire paragraph of the skill that tells the agent to write a long detailed commit message. s207 00:18:45.520 --> 00:18:48.520 What would happen if you just deleted that paragraph? s208 00:18:48.520 --> 00:18:52.600 Well, the agent would probably still write a decent like long commit message. s209 00:18:52.600 --> 00:19:06.080 People ask me a lot how I get my skills so small, and it's just using these techniques, using deletion tests, using um making sure that I compact things into leading words, I don't have anything irrelevant in there, and I don't have any sediment. s210 00:19:06.080 --> 00:19:09.360 And that finally brings us to the full sweep of things. s211 00:19:09.360 --> 00:19:11.400 Number one, we check the trigger. s212 00:19:11.400 --> 00:19:13.920 We make sure that it's firing at the right times. s213 00:19:13.920 --> 00:19:17.440 We check whether we're imposing context load or cognitive load. s214 00:19:17.440 --> 00:19:19.640 With structure, we think about branches. s215 00:19:19.640 --> 00:19:23.880 We think about structuring things into steps and reference. s216 00:19:23.880 --> 00:19:29.160 And we make sure that material that's only relevant for one branch is outside of the main skill.md. s217 00:19:29.160 --> 00:19:37.280 With steering, we're thinking about condensing text down into leading words and watching those leading words appear in the reasoning traces. s218 00:19:37.280 --> 00:19:38.960 And we're also thinking about legwork. s219 00:19:38.960 --> 00:19:46.200 Should we break this skill down further to increase its focus on the current phase by hiding the future phase phase from it. s220 00:19:46.200 --> 00:19:54.840 And with pruning, we're doing a final pruning pass over the entire skill, watching out for sediments, watching out for crud, and watching out especially for no-ops. s221 00:19:54.840 --> 00:20:02.560 Now, all of this stuff, the best way to get started with this framework is inside this skill, inside the writing great skills skill. s222 00:20:02.560 --> 00:20:15.200 You can check it out from my papago skills, download it, use it to improve your own skills, and maybe even use it to run over some community authored skills so you can check that the skills that you're actually pulling in are any good. s223 00:20:15.200 --> 00:20:19.640 If you want to follow along with my stuff, then I have a newsletter up on aihero.dev. s224 00:20:19.640 --> 00:20:30.120 And my plans for the next few months are to release an AI coding crash course, which is an intro to a lot of the stuff I've been talking about and how you get off the ground working with engineering and AI. s225 00:20:30.120 --> 00:20:38.240 I hope that what I've given you is enough to help you escape from skill hell or at least try to make the bitter journey out of there. s226 00:20:38.240 --> 00:20:41.280 I'm so sorry not to be able to attend in person, but thanks for watching. s227 00:20:41.280 --> 00:20:44.040 I'll see you very soon.