AI Agent Skills Explained: What They Are and Which Ones to Use

Matt: [00:00:00] Most of us spend a ridiculous amount of time teaching our AI coding agents the same lessons over and over. Ask questions before coding, write a spec, break the work into tickets, test it and review it properly. Agent skills let us package those instructions into reusable workflows that an agent can load whenever it needs them. But not every skill is useful, and installing a pile of someone else's opinions can just straight up make your agent worse, not better. So today we're breaking down what agent skills actually are, how they differ from prompts, rules, and emp- n-MCP servers, excuse me, and the handful of skills that I think are genuinely worth trying. And this is actually a Mike-written episode, so I'll pass it to him in a moment. But if this sounds interesting to you and you wanna support the show, you can go and check us out on that Patreon, leave a review or rating on your podcast app, join us in our Discord server, or share this with your friends. if you want to learn how to code, you can get up to twenty percent off a Scrimba Pro plan. Scrimba has an interactive [00:01:00] media player code editor where you can pause the lesson, play with the code live that the instructor was writing, go and mess around with it, break things and kinda ask yourself-- ask some questions and be like, "What the heck is this?"

Try to break it and answer your own questions. And then you can press play and the lesson just picks up from back where it was. Get up to twenty percent off their Scrimba Pro plan using our link in the show description and in the show notes with full details on how it works in the app, in the show notes on htmlallthethings.com. Now, Mike, you are going to introduce us to the world of agent skills, so why don't you take it away?

Mikhail: Absolutely. So preamble for this episode really is that as AI kind of progressive, progresses, we're seeing different paradigms come and go. Um, skills have now been around for a significant amount of time that I think they're here to stay. I think there's, they're going to be a- at least in some degree, a part of AI development, AI workflows for at least a while longer.

So [00:02:00] I wanted to make this episode because I've dove into a lot of skills. I've also dove out of some skills, but being like, "Okay, this is too much." And I've just kind of put my head around it, understood what it, what it is, so I wanted to pass that knowledge on to anyone that's listening. It doesn't have to be just a developer.

If you're, you know, if you're out there just trying to learn how to build an app with AI tools, skills are going to help you do that in a more, uh, structured way. And the great thing is, is that for, for some developers, you might have your own skills that you wanna create, but for people that are just getting into development or people that are kind of just, like, building stuff without, you know, wanting to become an engineer or a developer, um, there are opinionated skills that have already been created by experts that you can kind of rely on a little bit more and lean on to put some more, like, engineering structure to your app, right?

Like, if you're just going and, going in blind, it's gonna be a little bit messy. With skills, you can kind of put it, like, put it all together and almost like you're [00:03:00] taking a engineer's mind and y- having them, like, almost mentor your, your agents, right?

Matt: Can I, can I actually just stop you really quick with a question? 'Cause, like, I know there's gonna be people listening to this that have heard about skills, they've heard about AI skills, and they have no idea, like, what they are really at all. To them, they're, they're probably thinking my AI, whether it be ChatGPT, Codex, et cetera, Cloud Code, the list goes on and on, Copilot, uh, my AI, whether it be agentic or not, has skills obviously 'cause it's answering questions.

Like, it has literal skills. It's answering questions. It can do math to some degree of success. I know I've seen some memes on that. Uh, it can draw pictures. It can do these things, so clearly it literally has skills. So, like, what's the difference between it having skills and what we're talking about here?

'Cause I'm sure there's gonna be people that are just not aware, right?

Mikhail: Yeah. Yeah, exactly. So why don't I just jump in right here to the, to the first topic, which is what are agent skills? So [00:04:00] off the top, these are essentially reusable text instructions that teach an AI agent how to perform a specific task or fol-follow a specific process, right? So this is a MD file, like a markdown file, that you add in a specific directory named in a specific way, so that when an agent starts doing something, it knows that, "Hey, I have these skills," quote-unquote.

What it is not is like a bunch of code, right? I think a lot-- I think that confuses people a little bit, especially when they're starting to get into AI development, is like they expect a lot of things to be like a, like a library, right? Like maybe a skill is a library. It's not. It's actually a very, uh, sometimes a very small amount of text.

Like, uh, initially I thought a skill would have to be pretty, pretty dense to explain exactly step by step what you want to do. But for example, I'm looking at a skill right now, uh, from Matt Pilcock, who I will bring up a little bit later in the episode. It has seven lines of text in it, and it's probably the skill I use most, right?

Like the-- we're, we're talking [00:05:00] very few things, but it's a guidance, a set of structure for a specific process, okay? Again, in natural language text, and you, you have to think of it as kind of like a template a little bit on what you want, want, what you want it to do. And sometimes, uh, skills can also reference other things.

So the initial input, initial, uh, start point of a skill is always gonna be that like just .md file. But it could potentially be like, hey, when you're doing this process, reference this in-- reference this script and actually run a piece of code. For example, like linting, right? Like, hey, here's my linting script.

You know, run-- you know, follow this, uh, instruction manual and then run this script for linting if you wanted to do it like that. There's other ways you can kind of use scripts or you can use like, uh, not even just scripts, you can use like assets of like, I don't know, literal images and be like, "Hey, this is a skill for [00:06:00] branding.

Here is my..." In-inside the skill, you can kind of like point it to your branding folder and be like, "Hey, this is the branding folder. These are all the assets. So use these, uh, use these assets when you're actually doing any sort of, you know, logo layouts and stuff like that."

Matt: So something, and, and I wanna be s- clear that, uh, I, I don't know how this was made, but there's a, there's a, a mode, let's say, of ChatGPT, just ChatGPT, not Codex, not the agentic part, uh, where you can tell it to do deep research. You can do, like, @deepresearch, do, like, a bunch of research.

Mikhail: Угу.

Matt: As a part of that, if you give it a prompt that it feels needs more information, or if you give it a prompt that makes its own plan up, it comes up and it says, like, "I'll do this, then this, then this, then this," and it waits to execute that plan, 'cause you can actually go in and sorta, like, stop it or, like, you know, modify your prompt or what have you.

Basically, there's, like, a thing, a mechanic stopping it and being like, follow up with the user

Mikhail: Yep

Matt: a few ways." [00:07:00] I'm not saying that that's necessarily a skill in this case, 'cause this is for... The skills we're talking about is more for the agentic side, the Codex side of ChatGPT, let's say, and other,

Mikhail: Uh, I,

Matt: and

Mikhail: I, I think ChatGPT can have skills as well, I believe. Yeah, I think you can add skills like skill files to chat, to, to normal ChatGPT through the configuration menu.

Matt: Okay, but

Mikhail: Mm-hmm.

Matt: my, my point for the chat, for people that have used ChatGPT app and just sort of played with ChatGPT, they've probably seen deep research mode. I don't know if that's necessarily a skill, but just for the sake of conversation, that prompt that ChatGPT generates when you, when you tell it a prompt under the deep research mode is an example of what a skill might provide, where the skill might say, "Hey, g- have pause here. Ask the user a question if you have a question, or show the user before executing what your procedure roughly is going to be."

Mikhail: Mm-hmm. That's right, yeah. So like, uh, the deep research mode would use some skills if it, [00:08:00] if it needed to by-- to, to pause and to do something, right? So there's an orchestration layer, that's what people call it, of like, "Hey, let's do something. Let's-- But while you're doing it, make sure that you're using the right tools for the job."

And one of those tools is skills. So sometimes it'll go in and look at your skills as it's, as it's trying to think and as it's doing the, uh, different, different elements of whatever you're asking it to do. It'll look at your kind of table of contents of skills and progressively, like through progressive disclosure, will determine which one to use.

So it'll just look at initially just skill names and then descriptions, right? And then it'll be like, "Oh, this kind of matches what I'm doing right now." Like if I'm doing design and I have a branding skill, then that kind of matches logically. So I'll, I'll go deeper into the skill and see if there's anything relevant for me there.

And sometimes it'll determine there isn't, because you're not doing any branding work, for example, and it'll bounce out of there. So it's just another element of it being able to think a little bit further and use some structured content in, in its [00:09:00] thinking while, you know, figuring out a solution to your whatever problem you're asking it to solve.

Matt: So like something I, I would imagine is like, let's say for example, you tell somebody or tell a, uh, an AI to f- to look through a collection podcast episodes. Let's just say it's, uh, th- it's looking through the transcript,

Mikhail: mhm

Matt: you want it to look through the transcript and determine, uh, a summary statement.

One of the skills might tell it and say, "Hey, if you see as you go through episode after episode, a repeatable part that's likely the introduction, skip that introduction. If you see that, you don't have to spend time computing that introduction. You can skip that introduction and do not include any of the introduction in your summary paragraph that I'm telling you to make," for example.

You're guiding it along, along the way.

Mikhail: Yes. That's right. That's exactly it. So, and you can, again, you can make those skills yourself based on your own workflows, which I kind [00:10:00] of highly recommend you do as you establish workflows. You're like, "Oh, I always do this. I always have an introductory paragraph for this, for this kind of blog post or something."

Add that as a skill, right? Or you can rely on other people's skills and, uh, u- use those as well, right? As long as you understand what's going on in them

Matt: Yeah. Let me ask you a question there then. So I know that obviously this is a markdown file and it's different literally, but you remember back in the day, and I assume now, I just haven't done it in a long time, I haven't needed to, is people used to create their own GPTs. This is ... It, it almost seems something similar to this, right?

Because like a GPT, I just tinkered with it. I didn't get super, super in depth 'cause I just honestly didn't really need it that much. But I was more or less giving it sort of a, a set of like a paragraph where I was like, "Hey, you know, it in

Mikhail: So

Matt: way. I, I have a jovial podcast and I always want you to, you know, make it so that if you write a script for me," and no, this is not a scripted show, but, "I have a jovial podcast.

I don't want you to be serious in [00:11:00] tone writing this script. When you do this research I tell you, I want you to be jovial and always spin things in a positive light."

Mikhail: So, so yes and no. Uh, that would be more of an agents.md thing,

Matt: Okay

Mikhail: because when you're making a GPT, you're creating a separate agent that will always follow those instructions every single time, right? It'll look at those instructions every single time, look at all of them, and deci- decide which ones to follow based on the input that you're given, right?

Whereas skills, again, are progressively disclosed. So an agent, like when you ask, when you ask them, they actually aren't gonna load all your skills up and check everything one by one. They're going to look at only titles and only skill names, so it's not gonna bloat your context. So this is, this is where skills come in handy, is like, if you don't wanna bloat your agent.md context, technically you could put all your skills inside of agents.md and have similar performance for the most part, 'cause it's gonna have all that information.

But the problem is that at every time you run, all of the information in your skill [00:12:00] file is going to be loaded in every single skill, and therefore your context will be bloated and sometimes that'll introduce context rot. There's too much, too much stuff you're throwing at it, and when it's not useful, what's the point of putting it in there?

Matt: So would it be something like a ch- a, a GPT, and correct me if I'm wrong, but a GPT would be something where if we always, um, I don't know, e- every single time I give this GPT a URL, I want it to write me a good meta description and meta title, and I give it parameters like 60 characters and 55 characters and a maximum of 150 characters or whatever my SEO strategy is. And basically every single time I toss that GPT link, a URL, it goes through all the instructions. In this case it's rather simple, but you know, you could see how it would get more complex. And so basically I never have to give it all this context and everything. It's just always working in a context and I would just be like, "Okay, there's my URL, copy, paste, give it," and then it would generate all the shite and it would do it.

But something that's using skills in the, [00:13:00] in the agent skills side of things, it would decide, oh, I should use that SEO skill right now 'cause Matt's asking me for SE... Like it's making the decision to use that

Mikhail: Correct

Matt: is like, I always give SEO. Like it doesn't really have much external context or like that's not how you would use it effectively

Mikhail: Yeah, exactly. Uh, like it, it does have external context obviously, but i- if you're telling it that it is an SEO bot, then it is going to be an SEO bot as much as it possibly can be.

Matt: Y- right, yeah,

Mikhail: So the... Yeah.

Matt: on the

Mikhail: Yes

Matt: it's still gonna be like, "I'm an SEO bot, but this doesn't seem like SEO, so sure, I'll answer your question about leopards," or whatever, like

Mikhail: Correct. Yeah, unless you tell it specifically in your agents.md file to not answer other questions, which is another thing that you could do. Like when you're... 'Cause it, essentially the agents.md file is used pretty heavily across our industry, but the advice that I've been seeing and the, what I've taken is to use it as little as [00:14:00] possible.

Because again, the more you write to it, the more it has to be fed into your prompts, and the more it could go down the wrong paths and stuff like that. So you need to give it as loose of a set of instructions as you can. Like, if you have something very generic that you need that, for, from your project, like y- or something super important for example, like, "Hey, never commit to main directly," right?

Like, "Always go through a pull request." That's something you put in your agents.md file, right? Like the, the structure, the, the really important rules of your project, that's something you put in the agents.md file. And then everything else you would put into a skills file that you need to be reused o- over and over, because again, it's not context bloating your, your project.

There, th- there is some like hesitation to put everything into a skill too. Like, don't load up your entire project with like 1,000 skills. I have a whole section...

Matt: skills, like

Mikhail: Yes

Matt: to, it, it, it knows what it, when you say [00:15:00] draw, you don't have to define the word draw as like

Mikhail: Correct. Yes. And, and if you also, what I've seen happen is people will skill bloat as in like, "Oh, this guy has a bunch of really awesome skills, so I'm gonna download them all. Oh, this guy has a bunch of really awesome skills, I'm gonna download them all." What, what ends up happening is there's a lot of overlap in the skills that you've downloaded, and therefore now it's like doing the exact opposite of what you need because it's actually being inconsistent.

So sometimes it'll take this person's skill, and then sometimes it'll take this person's skill for design. So you need to be careful to make sure that you don't have too many overlapping skills. Otherwise, again, you're losing the point of what, what the skills are supposed to do, and you're increasing more bloat, and you're also making it so that the decision to use a skill is becoming harder and harder and harder.

And then that in itself is costing more and more tokens as you, like, skill bloat over and over. I have kind of a, in the show notes on htmlthings.com, if you go there, I do have like a whole section here with why not to use a skill. Uh, and yeah, I have a bunch of different points there if you wanna dive a little bit deeper into that.

Um, I do wanna [00:16:00] talk... Yeah, mm-hmm.

Matt: question. Sorry again, I know I'm

Mikhail: Yeah, of course.

Matt: questions here. But,

Mikhail: Mm-hmm.

Matt: so we have the skill.md, which is your skills, and then you

Mikhail: Mm-hmm.

Matt: agents.md, which are like instructions or rules like, "Hey, never email Matt," or whatever, right? You have those. When we were talking about GPTs, g- the agents.md is...

Like that's closer to what a GPT is, but it literally isn't that. 'Cause I know that some beginners are gonna get confused where they're like, "Oh, my agents.md is like creating a GPT." Like who knows what ChatGPT is doing in the background to create a GPT. It's more or less kind of like an agents.md, right?

Kind of, but it isn't that directly

Mikhail: Yeah, I, I think there's more to it. There's a little-- Like, a GPT has more to it than ag- just an agents.md file. I believe there's more, like, you can actually load data into it so that every time you run, it'll run through some data source if it needs it and stuff like that. So there's more to a GPT. I don't know how heavily used they are right now either and for what, so I, I don't have too much context on them.

Matt: I was

Mikhail: But

Matt: it's kind of being antiquated. It kind of feels like I

Mikhail: I think so

Matt: [00:17:00] "This is the most useful, uh, GPT." I never see that on TikTok. I never see that on socials. Now, of course, it's, you know, what, the algorithm's gonna show me whatever the algorithm decides to show me. Who's, who knows?

But I- back in the day, it was always, "This GPT will, like, make your art so much better," and stuff like this. Now it's like, "Use this skill if you want the best project management possible." It's like, okay, well, skill kind of sounds like it is, uh, replacing

Mikhail: Yeah

Matt: is, like, on the road to that anyway

Mikhail: Yeah, and that's why we're talking about skills. 'Cause like initially, yes, GPTs were around and it was an interesting concept. We never really did an episode on it because it never, in my opinion or in our zeitgeist, took off the way that we thought it would.

Matt: them, uh, to be

Mikhail: It...

Matt: it once or twice and it was

Mikhail: Yeah

Matt: it's just going off. It's just sorta like, "Yes, Matt, I'll talk to you about the podcast," and then it would

Mikhail: Yeah

Matt: "And then the tiger attacked..." It's like, whoa, hang on. What's going on here? Like, you're o- you know, you're off on a different context here.

It's like you're just, you're just, like, framing... Y- you're just doing, like, like, the government r- requires this disclaimer,[00:18:00]

Mikhail: Угу

Matt: almost like, "Yes, Matt, the podcast. Anyway, let's talk about tigers." Like, what? What's going

Mikhail: Yeah, e-exactly. I didn't see too much value in it. You can always add stuff to your memories in ChatGPT, and that's what I've done is I've asked it to be like, "Hey, remember that I'm a podcast host," and now I don't have to

Matt: yep

Mikhail: w-worry about that kind of stuff where I have a separate GPT just to talk about the podcast.

Um, but yeah, so like, it-- at the end of the day, we-- I saw skills come out, and I'm like, I did the same kind of thing. I'm like, "Ah, I don't know. It's kinda weird." But then as time went on, this has been like months now, right? Like maybe even a year or so, um, I was like, "Okay, I'll try this one, I'll try this one."

Some of them sucked, some of them were good, and then I just saw them keep propagating, propagating. And now I believe, again, at least in the short term, they are something that's gonna stick around. Um, so it's important for whatever sticks around in AI, that's a pretty rare thing, honestly. So it's important to kind of dive deeper into those things, understand them from a, at least a high level concept, [00:19:00] but then dive deeper into them as you have that understanding and hopefully, you know, utilize them to your advantage.

'Cause they are, they are a useful tool. They don't bloat context as much as an agents.md file, and they also make it so that when you're using something like an MCP or tools, right? Like when you're like giving it access to GitHub, for example, uh, you're giving it access in a more consistent way. Because if you don't have a skills file, that doesn't mean you can't have a GitHub integration, that you can a-add a GitHub MCP or integrate the GitHub with whatever, like a CLI or whatever.

Um, the problem becomes where like if it doesn't have a consistent set of rules to follow, it's going to just commit in a different way every time, or it's gonna have to go in and actually go to your history every single time, see the way you commit, and then do that same thing, which wastes tokens, right?

Like it, you're wasting its tokens when instead you could give it a seven-line file or a 10-line file in ru- for git rules, right? And then all it has to [00:20:00] do is go through that. It's very few amount of tokens every time, and then it just follows that every single time. Saves it time, is more consistent. It's just a, a, a better way to handle any sort of integration on top of it.

And another thing that I d- actually don't have mentioned in the notes, and I should, there's these things called plugins. So like I, I, I don't have it mentioned kind of on purpose 'cause I think this is like a fleeting thing, but just to get everyone on the same boat is when you see plugin, what really, what that, all that really means is just a skills file usually with a MCP hookup.

So it's a skills file explaining an MCP. Correct. It's essentially what that is. So you're connecting your GitHub account, and then you h- you have instructions on how that's supposed to work, and that's, that's what essentially a plugin is. There might be some more to it, but um, I just wanted to, yeah, clarify that when you're, when you're, when you're seeing it.

It's not, it's nothing like, it's not a traditional plugin where there's a whole bunch of code involved.

Matt: Well, I guess it's, it's just like a more guided [00:21:00] thing, like something somebody like, you know, ChatGPT has... I don't know what the approvals process or what have you, but it'll be like, I can con- I, I know that if I click on the GitHub integration and it asks me for my username and password or it asks me

Mikhail: Yep

Matt: I know that it's going to GitHub.

It's not just like, "Well, Git, I can just go to GitLab," you know, 'cause a bot can kind of hallucinate a little bit and be like, "I'm just gonna go to GitLab," like it just says Git. It's just sort of like a very guided, specific, uh, you know, kind of experience, experience with that. I was actually gonna say, I was gonna jump in there when you were talking about like the commits because we're rebuilding the Digital Dynasty website right now, and I, I was doing all the commits and stuff like this, and I was just like, "I'm just gonna see if it, if it'll do it for me," you know, what have you.

And it, it was like, it was assuming a lot of things. Like, even though it was just a simple like, hey, like I already had all the templates and all the pages all made up, and I was just telling it to take all the, these p- these images and, and this text and sort of display it nicely on this page. It quite literally was like, one point it checked the history, 'cause I did this a few different times.

At one point it did [00:22:00] check the history of my committing and then it was like, okay, like I'll kind of, you know, do that. And then at another point it's like, I'm assuming I just pushed to, pushed to the, to the one branch. Like it, it doesn't know, right? And so sometimes it literally says, "I'm assuming," and other times it says, "I need to determine where I should be pushing this."

And it's not like it's asking me, it's determining it by like a bunch of like checking and then it, and then it is at the end of the day making an assumption. And so like you... I can absolutely see in something that's much more complex than our l- like our marketing website, where you would wanna cut down on as many of those assumptions as possible.

You wanna make it as deterministic in its pattern, 'cause I know it's not deterministic at the end of the day, but you wanna make

Mikhail: Yes, ma'am.

Matt: it as deterministic in its thought pattern as possible

Mikhail: Yeah, that's exactly it. This is, this is our way of controlling the indeterministic side of LLMs as much as we can, and that's a good way to kind of like determine if you need a skill or not for this process. Is this something that's repeatable? [00:23:00] Is it, you know, the commit process, that's a repeatable process.

So you know you're, you're, you're probably set with you put a skill there, right? Is it a, you know, a random side, side thing that you do once in a while? Maybe that doesn't really require a skill. Um, but in- internally as like a, a team, uh, th- this is another good place to use skills is like, "Hey, do you have your own processes for deployment?

Do you have your own processes for testing? Do you have your own processes for, uh, evaluations?" Like whatever, benchmarking. All of that is good in- a good indicator a process can be translated into a skill, right? So whenever you have processes as an engineering team, you should be thinking how I can translate those processes into the, the most minimal skill that will benefit the workflows of the entire team.

It, it-- Individually, it's great. On a team, it's much, much better because again, you're introducing reproducibility into indeterministic [00:24:00] processes like an LLM agentic workflow. And as-- the more you can do that without bloating it and without making it bad, um, the better it's gonna be across the board. Like if, you know, if the pull request-- For example, a pull request process is a very common one for every team.

Like, "Hey, this pull request has to have this section, this section, this section. Here's a template of the pull request." You'll wanna put that in a skill so that every time any engineer, uh, creates a pull request, it just follows the skill. And part of the onboarding of engineers is downloading your skills repo, importing it into whatever agent you're, you're working with, and making sure that it's all, uh, you know, running, uh, before they even start coding.

Matt: Well, I, I was a part of like a little side project that never fully came to fruition, but I remember back in the day we were, we were starting to put together a, a landing page, and then we were starting to... We, we needed a bunch of content for the site, so we were adding writers and, and, and other things like that.

And I remember... I can't remember whether the guy was using, uh, some sort of external tool or whether it was just for glance ability in Git itself, but, uh, I [00:25:00] believe it was an external tool that he was using almost like a... I'm just gonna... I, I don't, I didn't use it myself, but almost like an RSS feed, like quick look so he could see who last committed and what committed whatever. And it was just more or less the commit messages. It was a custom little bit of software he was just kind of, you know, using for his own, uh, his own stuff. And one of the processes that we came up with was, okay, we're gonna informally tag our commits even though obviously if you go onto like GitHub, I think is what we were using, it'll say, you know, Matt published this, like Matt, Matt did this commit and this push. That wasn't coming through on his little custom whatever it was. And so we were like informally tagging things and w- you know, in square brackets we'd just put Matt. Now I know some p- some, some teams will put like dev or cre-creative or image or whatever the t- like the little informal tags that they've come up with. I mean, that would be something that would be super useful inside of a, an LLM skill where you're like, "Hey, like our team has come up with these eight tags. Always determine one of the tags." And, and you can even say, "Always determine which tag to use and ask me for approval before

Mikhail: Yes

Matt: mess up depending on how strict the, the [00:26:00] team is.

And in my-- in our case, it, it was just our name. Like we would just put Matt 'cause I was one of the devs and the other guy was creative 'cause it was so early. It was like, okay, like Bill or whatever, I'm not gonna give away names. But like Bill is the creative guy, so like it just says Bill and then wrote a story or what have you, what have you, right?

Mikhail: Absolutely. Yeah, exactly. As soon as you can find any of those patterns or any of those processes that are repeatable, like that's again, an indicator for you to write your own custom skill. Um, but there's not only custom skills because some-- like I do recommend you to spend time and figure out how to write these custom skills.

There's plenty of different, um, guides online on how to do it. One of those guides actually, or one of those-- There's even a skill to write a skill. Uh, it, it's from Matt Pocock. Uh, Matt Pocock has been kind of b- essentially the one guiding me into using different skills or creating skills myself. His are, I believe, like number one in terms of how many stars they have on GitHub right now, and there's a, a good reason for [00:27:00] that.

Like he's bat-- it's battle tested for the most part at this point. These aren't the only skills you'll want to have, I want to make that clear, but these are a good starting point for you to learn and a good f- set, a set of processes that will help you build projects in a more like repeatable, maintainable way.

There's a, there's a few things in here that he's kind of coined, um, a few skills in here that have essentially changed the way I interact with agents, and I want to start with those because it's, it, it, I think it's an important thing for everyone to understand. The number one thing here is Grill with Docs.

So it used to be a skill called Grill Me, right? So essentially when you're doing a plan mode, right, like when you're planning a task, what happens in the background of a lot of these agents is it will build a bunch of context of the application, and then it'll start going through and making decisions and decisions, decision, decision.

And a lot of times it makes those decisions autonomously [00:28:00] when it might not want-- Well, it might not, it m- it should not make those decisions in some cases, or it should inform you of those decisions, right, uh, before it, it creates the plan. Now, in plan mode, a lot of times you will get a couple questions like, I don't know, two, three questions on average, I would say.

Sometimes no, no questions because they're trying to make it as like streamlined and efficient as possible. They don't want to overload the user. But when you're building something serious, right? When it's not like a, you know, POC or something like that, but when you're building something serious, what you want to do is have better context of what the LLM is deciding, and that's really what Grill with Docs gives me.

So instead of asking me two to three questions, most of my Grill with Docs sessions to create a, a serious plan are between like fifteen to thirty questions. Now, every question has a lot of context in it, and it has a recommendation. So the recommendation is essentially what the plan mode would have chosen [00:29:00] regard- without your input.

And in my experience, I choose the recommended output or the recommended, uh, about eighty percent of the time. But that's not really even why I like it. It's the fact that every big decision that's being made is being passed through me. And by the end of a Grill Me with Doc session, I have a much better context of what the plan's actually gonna achieve from a technical standpoint, as well as like a UI/UX stand- Like the, I have a, a much better idea of what's gonna be presented at the end.

Whereas after a plan, I can read the plan and I can get, get kind of an understanding of it, but just reading a document top to bottom, a lot of times I'll lose some of that context. Whereas if I'm part of the decision, and if the, even if the decision is stick with the recommended, I feel like I'm more in control of that project, if that makes sense

Matt: Well, your mi- your mind would naturally wander. I mean, given like

Mikhail: Yes

Matt: document, eventually you're gonna start skimming.

Mikhail: Mm-hmm.

Matt: my case, [00:30:00] my-- one of my biggest problems with reading is I start reading and I immediately start skimming, and I always gotta like stop, myself back up, start reading again, and I start skimming again.

And I keep, I keep sort of doing that. And so being brought in to the decision-making process is gonna allow me to actually know more what the heck is going on. Like, I'm just gonna, like you said, have more context and more understanding. And also you're gonna find little issues too.

Mikhail: Yes, you do

Matt: "Oh, shoot, like this is kinda going off the rails a little bit.

I better like, you know, re-steer this," or what have you

Mikhail: And, and I do. I find l- I find it sh- uh, uh, like I said, about 80% of the time I'll, I'll take the recommended, but almost every single time, 20 to 30%, I'll be steering it and telling it different things and giving it more context. And the other thing that Grill Me does is that even if you give it a recommend-- like you say, like, "Hey, yes, recommend it," but you can give it a little more context and be like, "Hey, you, you know what?

You should probably know that we're gonna be using Tailwind for some of this." And it can go back and be like, "Oh, you know what? Then I have a few more questions for you here and a few more questions for you there." So

Matt: smart. That's

Mikhail: yeah, it, it, it, it [00:31:00] becomes kind of a back-and-forth session where you're building this, like, mass amount of knowledge, both on the LLM side and your side, and you, you have a, a better way to steer and better way to control the actual out-output that comes out of it.

The other thing is, like, the with docs portion of Grill Me or Grill with Docs, this is something new. Um, essentially it's a shared terminology. So when you're building something like an, a, a random application, let's say like an e-commerce website, right? A lot of times there's many different ways for calling a n- like, you know, a checkout, a cart, whatever.

A certain engineer will probably have a certain way of calling something, you know, something. And what Grill Me with Docs does is as it sees the way you're talking, it will actually put terminology into a context.md file, and then it'll be able to refer back to that terminology as it goes to understand the context of what you're gonna be talking about throughout the entire [00:32:00] existence of the project, not just a Grill With, Grill Me with Doc session, right?

And when you introduce a new word for that same thing, it will add that as well so that it knows that you're talking about the same thing here. And sometimes it'll clarify with you, being like, "Hey, are you referencing this that you referenced before?" And then it'll add that in. So again, it's building a little bit more context.

It's, it's starting to talk to you from a knowledgeable perspective of your own language and your own vocabulary, not just its own

Matt: That ha- has gotta be super, super helpful for companies also that really love their own little glossary of

Mikhail: Yes

Matt: uh, acronyms, little weird terms. Uh, maybe they don't call their HR team something, they call it something else, right? Like

Mikhail: Yeah, people

Matt: teams where they, they call their... It's like, "This is HR," but it's actually called like, you know,

Mikhail: Mm-hmm.

Matt: people.

I don't I don't

Mikhail: Yeah, heads, head of people. I, I've, I've seen head of people before, I think,

Matt: people,

Mikhail: which is weird

Matt: stuff like that. Organizational development, I've seen that one. Um, and stuff like that. So it's got... [00:33:00] This has gotta be huge for them because, huge for it because then it, it knows right away, like, hey, if I... Looking at it through the lens of someone who creates websites primarily, even just it writing content, instead of it writing human resources and HR everywhere, it knows immediately, you know, through this context file, 'cause as I'm like feeding it stuff and going through the grid with questions and stuff, it knows like, hey, if Matt says HR, he actually means people.

Or if he says people, he actually means HR, and HR has like its own implications as to like what department it is. And so there's like a, mean, a context there, right there being shared among, among multiple sessions as well, right? Like multiple agentic sessions with the same, with the same context file and stuff

Mikhail: Yes, exactly. And it, and it, it helps massively with those kinds of things. So Grill, Grill of Docs, if you're gonna take anything from what I'm gonna be saying, any of these skills, I think this is the one that you should start with. This is the one that's changed the way I develop with AI the most out of anything.[00:34:00]

The next skill here is very similar. It's called Wayfinder. This is a more bigger idea or bigger project Grill of Docs. So what this does is instead of being like a technical thing where it's trying to figure out how to implement something, this is trying to decide where the loose ends are of a project, what are gonna be the, the biggest challenges, what are the open-ended questions that are gonna be arising from that project.

So this is something that you wouldn't do for like a small feature that you're building on an already existing project. This is something you would do on a whole new like avenue that you're creating, a whole new project you're creating. Before you start creating it, you would run through a Wayfinder session, and it will create a, like a, a map of decisions essentially.

It'll actually like y- y- you'll see like essentially a chart in an MD file about which decisions and why you made them, right? Like, so every answer that you give it, it'll map that out, and then it'll give you a, a bunch of tasks that you have to do before you can even start implementing [00:35:00] things. Like, "Hey, figure out this open-ended question.

Is this, you know, technically possible? Is, i- will HR sign off on this? Will, is there a legal issue?" Like, it'll just give you a whole map of things that you have to resolve, uh, before you can start a Grill of Doc session or a, uh, what, what's next here is to spec, which is like actually taking a bunch of these decisions and putting them into a, um, a, a, uh, complete idea.

So what you're actually gonna be building, right? Like, so specs are essentially what comes out of a plan. So when you finish a planning session, you create a spec for what that feature should be, what, what f- what's the pr- you know, uh, completion criteria, what needs to be built, what files need to be touched, all that, et cetera, et cetera.

So that from a Wayfinder or a Grill of Doc session, you would go to a new skill called To Spec, and that will take it and put it into either one plan file or it'll put it into multiple different [00:36:00] plan files, right? Uh, depending on how big of a feature you're building or whatever you're building, and then you get from there to the next step here in the process, which is To Tickets.

W-

Matt: I have a

Mikhail: mm-hmm

Matt: before we jump into there. Um, I'm just curious, like, how, how, like, standardized do you think these are gonna become? And what I mean by that is, is like, are teams gonna start demanding, "Hey, always start with Grow with Docs," and then... Or in the case of it just being an idea in that with Wayfinder, right?

It's like, if you ha- if we're talking in, in abstract, if we're talking in grandiose really, with Wayfinder, and then, and then we will go then to Spec, and then we will... Or is this more of an, uh, an individual thing? 'Cause, like, for, for example, Wayfinder for me, I don't even use Wayfinder. What I actually use is I use the ChatGPT voice mode, and I ramble like an idiot, I will literally say, "Hey," like bring, you know, quite literally, "Bring me back down to Earth.

Let's talk. L- I don't wanna [00:37:00] build this yet. Let's talk about what's realistic, what isn't, what's possible, what isn't, what's within the budget, what isn't." And then we have a conversation back and forth, back and forth, back and forth. And then I'll say, "Hey, I'm gonna go over to Codex," or, "I'm gonna go over to an agent. What should I give them?" And oftentimes it will provide either a really good prompt or it will provide, not necessarily a skill, but an MD file where

Mikhail: Mm-hmm

Matt: say, "Hey, here you go." Uh, we-- I did that for the Digital Dynasty website. I was, like, working with it on some web design stuff, and when we kinda got a design language that worked, I said, "All right.

I need to give this to an agent. I would like you to distill this down into..." I knew I wanted a markdown file, so in that particular case, I specifically told it to give me a markdown file. But it could have generated, like, a PDF, right, to present to a design team or something. Um, and that was on the ChatGPT side, so not the agentic side, but the ChatGPT side.

And so that, like, that's sort of my Wayfinder. The reason why I mention that is obviously different people are gonna have different, uh, procedures, [00:38:00] but do you think that teams are going to start, if not have already started, being like, like, "You must use Grow with Docs. You must use Wayfinder. You must use Two Spec.

You must use Two Tickets"?

Mikhail: It's a good question. I, I do think that parts of these things will become standardized across teams. I don't know if Wayfinder will be particularly that. I, I do see a world where this workflow of grow docs to spec to tickets and then implement

Matt: Mm-hmm.

Mikhail: get pushed to like a actual workflow across teams, because again, it creates a very consistent, repeatable process that you can easily like hit-- like have a historic view on.

Because if everything is created to a spec and then every- from spec they go to tickets in like your linear board or your GitHub issues, whatever, wherever you handle your tickets, then just figuring out velocity, figuring out w- you know, who was w- in charge of what becomes really easy. And if it's repeatable, then it becomes, it makes more sense.

The Wayfinder stuff is a little bit more [00:39:00] iffy because it's more i-ID- idea based and like bigger. So it's very abstract, so I don't see that ever being pushed on teams, but... And, and the other thing is like, I really do think that a lot of this will be taking what we're given as a base from like Matt Pocock's skills, and then implementing your own versions of it to a certain degree.

And I, I highly recommend that everyone kinda do this as well as like, "Hey, these are great for the general population, but they might not work exactly for your team." Like, you might ne- not need a separate two spec and two tickets. Maybe you can combine those, or maybe you don't even do the tickets, maybe you do those manually.

Like, you don't need to follow this one for one, and you don't even need to use the exact skills one for one. You can go in and edit them yourself, they're just MD files, and see if that makes it better or worse or to make it fit into your workflows, whatever. That-- It's a good way for you to learn how these skills work.

So I [00:40:00] think at, at some point there will be a subset of skills that are going to be mandatory and a subset of workflows that will be mandatory in team environments. Um, but I don't know what those will be. So it's, it's kinda like it's gonna be very, very much dependent on how the team works.

Matt: A- and, and that is a, that is a good point because, I mean, this is not using skills. This is before agentic kind of started taking over. But when, uh, ChatGPT's memories were starting to get really, really good and, like, actually

Mikhail: Mm-hmm.

Matt: Like, I run two podcasts, Day One Patch Podcast,

Mikhail: Mm-hmm

Matt: also HTML All the Things podcast, which is what you're listening to now. And I would just say sometimes the podcast and... Or I would just use, you know, very sort of generic terms or what have you. Or I would say, "Hey, I need a full spread." Full spread is like I wanna see what marketing keywords and other kind of key points that I, I, that you recommend, and oftentimes I take it and kind of rip it to shreds.

But anyway, I still wanna see a full spread to sort of, like, get myself into the context of, okay, I'm gonna start marketing this episode or what have you. [00:41:00] Um, and so I would... I eventually just made, in ChatGPT, I made two projects, and I was like, "I run two podcasts. When I'm in this project and I say the podcast, I'm talking about this podcast.

This podcast is about this. Here's the link to the podcast page so you can see what it's about, and so you understand." It's like, okay. And I was like, "When I'm talking about podcasts in this project called HTML All the Things, I'm talking about this. There's our website. Here's our podcast page. Here's, uh, you know, a couple of the episodes that we, that define us or what have you. This is what HTML All the Things is." And it's like, okay, cool. And then it's like, okay, now that we have all this freaking context, now I can talk like a person 'cause, like, I don't go to... Like, if you were my host, Ryan, on H- on Day O- Day One Patch Podcast, I don't go to him and go, "Are we doing Day One Patch Podcast?"

Like, I would say, "Are we doing the podcast?" And so with the ChatGPT, I would wanna be quick and just sort of like, "Oh, hey, are we doing the podcast?" And it'd be like, "Sure." And then it started confusing HTML All the Things with gaming sometimes, and it would start being like, "Well, HTML All the Things talks about Xbox."

It's like, [00:42:00] "No, hold up. Stop." And so I could see how this, you know, comes into... Even though it was just using memories, it's kind of like the beginning, right? Like, ChatGPT/OpenAI definitely understood, okay, people are using app like this. They're having issues in these areas. This is how they're working around them.

This is how they're doing it. Let's ha- let's have these skill things allow us to, like, be a little bit more deterministic 'cause that's a deterministic thing. When I'm in Day One Patch Podcast project, w- we don't talk about web development

Mikhail: Yep.

Matt: Like

Mikhail: It's, it's a good little barrier that you could put in place, right? Like, and again, those are rare in the indeterministic nature, so the more you can add those, the better your output's gonna be usually,

Matt: Mm-hmm.

Mikhail: of if it's just like conversational or code-based. Yeah, that, that, that does make sense.

So couple of other ones here I'll kinda go through real quick. Uh, implement. So there's an implement skill. After you do the two tickets, you can run implement and g- pass it [00:43:00] the, the tickets that you wanna solve, and then it will go through and actually, you know, execute essentially. That's how I-- the implement skill is the same as kind of an execute.

Uh, it'll start creating them. Now, the implement skill has like a couple different processes in place, like do it, uh, based on the agreed-upon boundaries in the tickets, like where the success criteria is. Do tests around those boundaries so that everything that you're creating can be easily tested. So it has a little bit more structure in place than just like, "Hey, finish this plan."

Um, so that typically has a slightly better output. Uh, I, I don't use it all the time, I'll, I'll be, I'll be honest, because it's sometimes a little bit too robust and a little bit too lengthy of a process. So I'll sometimes just have it execute a ticket a-as a regular ticket, depending on how complex it is.

Um, that's one thing. Code review, uh, implement actually runs a code review, but if you wanna run it separately, like, uh, after you've finished doing a b- uh, a random implementation, you can use an, a code review skill, which will in-instruct the [00:44:00] agent to go through and make sure it follows, and make sure that the diff or whatever you're reviewing has the same code base standards as everything else in the code base.

Make sure it doesn't a-add any sort of code smell or unnecessary complexity. This one's important, unnecessary complexity. Uh, a lot of times AI will go down rabbit holes and like do a bunch of things to do something that could've been done very simply, just because it, it, it ran into some roadblocks along the way.

So having a code review go through and specifically implicitly say, "Hey, unnecessary complexity is something to look out for," I usually am able to reduce a bunch of lines of code based on that. Um, so that's, that's something that I usually include in my code reviews, as well as regressions. Like, "Hey, make sure that this doesn't have any regressions, it doesn't break any features that shouldn't be broken," and stuff like that.

Matt: I, I had a, I had a, a ChatGPT run rampant one time where I was just trying to make a very small, like, little custom change to Webflow, and it, it ran rampant with the idea that it... this, this slider needed to be touch sensitive, and it [00:45:00] was trying to make it stylus sensitive for, like, old window, like, tablet PC devices.

And I was like, "Hold up, like, people from the '80s can't run this website anyway. What are you, what are you doing?"

Mikhail: Yeah

Matt: I think it was up to 2001, was this, like, specific HP touchpad or some, some crazy thing. And I was like, "H- what are you doing?" It's like, "Oh, well, uh, like a stylus is, like, a touch point, and it, it, it acts as a finger, whereas when you use a mouse it's a pointer and it's different."

And it's like it was trying to, like, you know, equate them. And I'm like, we're not worrying about the, the one person that for a YouTube video booted up a ni- like a 2001 or 1999, like, HP touchpad tablet computer that was resistive and had a stylus that was acting as a finger. It's like, what are we doing? We're not

Mikhail: No, we gotta, we gotta worry about it. This is, this... We care about every single customer, Matt. How dare you? No, I'm kidding. I'm kidding, obviously

Matt: we'll leave that to L- I think it's [00:46:00] LGR Reviews. They, they... he does, like, retro tech and stuff. It's like we'll leave, we'll leave it to the people doing the retro tech stuff, and there's many other people other than him, uh, doing it.

Like, but he's not gonna be like, "Man, this website sucks. I can't use my 2001 HP," and then, like, 80,000 letters and numbers 'cause they don't name things correctly. It's like the... All computers do this, though. It'll be like, "Welcome to the IdeaPad 0X473X40XA-," wait, CA 'cause it's

Mikhail: Mm-hmm.

Matt: It's like,

Mikhail: Yep.

Matt: here we go. Here we go. And what, what does no country code mean? Well, does it mean US? oh, okay, here we go, 'cause some countries don't allow a dash. It's like, oh, like, no.

Mikhail: Mm-hmm. It's gotta work on everything, Matt. That's what you gotta...

Matt: we

Mikhail: If you wa- if you wanna burn your credits or if you, if you wanna burn your agent tokens, have at it. Like ma- like give it that goal. Work on every device you could possibly think of. It's gonna be running for a little while.

Matt: Thankfully, I was just using GPT, like just

Mikhail: Yeah, that's good. Yeah

Matt: like kind of... I [00:47:00] was really kind of exploring. I was way

Mikhail: Mm-hmm.

Matt: one might say.

Mikhail: All right

Matt: it went a little crazy

Mikhail: Heck yeah. Uh, yeah, other than that, I have one other skill, Handoff. Um, so a lot of these agent platforms, Codex, Cloud Code, will have a compact skill or, like, a compact mode where it'll take, like, a, a, a really long conversation and put it into, like, a short, you know, blurb.

Um, a lot of times those are not great, in my opinion, and they're not as easily reusable across sessions. So if you want something that you can kinda like refer back to in a later session, so, like, you know, you, you f- you fix something that you know you're gonna have to fix later, let's say, on a different computer or a different agent, you give it to a Handoff, it'll create you an MD file with whatever context was in that, was in that chat, as short as possible, and then you can start a new chat and refer to that MD file whenever you want, right?

So it, it's a, it's a good way of preserving context of important conversations that you've had [00:48:00] without having to resume a conversation or something like that or, you know, do, do it a different way That's it, though. Uh, other than that, for those basic skills, that's it. The last thing I wanna talk about is kind of like a more complex skill.

So I mentioned before that skills aren't sometimes just text, they're actually references to files to run or applications to run and different ways of using an application. One of the more, like, complex ones I would say is the computer use skill. So there's different skills for computer use. Uh, I'm just gonna give one example 'cause I've been using it recently, which is the Orca computer use skill.

So Orca is this, like, uh, application that allows you to run a bunch of your harnesses. Like you could-- Essentially you can run Codex, Cloud Code, Cursor all in one window and have them a little bit more related so you can, you know, go from one conversation to another conversation. It's like, just a, a little bit better organized rather than having them in all separate windows spread [00:49:00] out all across your computer.

Um, and Orca itself has like a bunch of its own skills, one of them being computer use, where you can ask it to use your computer. For example, like log into a website, do this, do that. Espe- It's especially useful for testing workflows, right? And computer use requires a lot of different applications, so it requires like being able to screenshot, it requires being able to move a mouse, it requires being able to, you know, change windows, it requires being able to read consoles, it requires, you know, ac-activity, activity monitoring, et cetera, et cetera.

And a computer use skill will have all of that instruction for the LLM to understand how to use whatever computer it's, it's on. So that's a more complex skill that you can look at. Um, and they can get even more complex technically. My, uh, the only like kinda like caveat here is, again, back to like the bloat.

You don't want to have a million different complex skills because it's going to overload your contacts window. It's going to make everything more expensive. You wanna have the ones that you [00:50:00] need on your, on your machine. And the other part of this is sometimes you need to go in and prune. So part of your process is maybe once a month, maybe once a couple months, I would recommend going through and seeing what skills you have active.

'Cause you'll s- you randomly see something on X or something and be like, "Oh, that's cool." And you'll add it to your project and you'll try to use it, and maybe you, maybe you won't use it again for like six months. But it's still there and it's still part of that table of contents, and it's still eating up resources every single time, even though they are ver- they are very minimal.

So I'd recommend an active prune. You can even prune w- using LLMs. So you can be like, "Hey, let's start a pruning act-- like a skill pruning session. Show me all the skills that I have active. Give me some recommendations on which ones overlap." And it'll like kinda guide you through it, so you don't even have to do that manually.

But yeah, that's, I think that's it for skills. Um, highly recommend you check out Matt Pocock's stuff. I'll have his, I'll have links to it in the show notes. Uh, he's the probably the best, you know, expert out there in skills at the moment.

Matt: Matt Pulcock or [00:51:00] Matt Lawrence is the best? Which

Mikhail: Matt, definitely Matt Lawrence. Yeah, definitely. I, I've seen all of your skill, all of your skill files.

You're, you're kicking ass. No, uh, Matt Pocock, um, I highly recommend you check him out. And yeah, that's it. Hopefully this was somewhat informational for you and you got something out of it because skills were kind of a black box for me for a l- for a long while, while I was kind of sussing out if they're actually a thing to pay attention to.

Matt: Well, you

Mikhail: Now I think they are. No, you can't.

Matt: away in like a day, and it's like,

Mikhail: Correct.

Matt: spent two hours looking at this, you know?

Mikhail: Yeah. I think, again, this is an indicator for you to start looking at it. That's why I'm making this episode because I do think that they're here to stay

Matt: And, and one thing I, I do wanna mention with the Orca Computer Use, especially for complete beginners, I mean j- just having Codex, for example, it can do a lot of stuff from the

Mikhail: Yeah

Matt: something like an Orca Computer Use. So that goes back to what you were saying where like don't overload.

If you're like, "Oh, I really want my ChatGPT, my Codex to be able to create files on my computer [00:52:00] and like do..." I don't have Orca Computer Use. You know, I don't need it. So like take a look ab- at, at that skill and make a decision like, "Okay, Orca's doing something that is outside of the scope of what Codex can do on my computer normally," so then, then add it.

Uh, would it be overstepping to say, Mike, or even maybe foolish to say that this is kind of similar to people downloading apps to their phone where they occasionally prune them? Or even the web developer space, something like people trying out WordPress plugins, where you don't want a million and a half WordPress plugins.

It's like, hey, you might try two form plugins, and you might decide, all right, I don't want this one

Mikhail: Yeah, I, I think this applies to anything that has that kind of, you know, marketplace or mentality or whatever, where you can, where you can try things pretty easily and, and freely. So this is-- it's a... Yeah, exactly. It's the same thing with like packages, you know. Package bloat is a thing where you just have-- Like I, I've seen projects that have like three or four different packages doing the same thing, [00:53:00] and they're-- some of them are used, some of them are not.

So like it's the same thing with that. So it's just something you wanna keep an eye on and make sure you're not overusing too, too much. It's not as big of a deal as overloading your agents.md file because again, it is saving on context by not, you know, writing the entire agent, uh, the entire skill file every single time.

But it will add up if you have like, you know, hundreds of skills or thousands of skills or whatever. I, I think thousands of skills is a little bit over exaggeration, but hundreds of skills, definitely

Matt: Yeah. Uh, I mean, I'm this conversation will absolutely evolve. Um, it'll skill up, one might say. Also a

Mikhail: Nice.

Matt: Um, but yeah, no, uh, it'll... It, it, it's something where, uh, like we'll, we'll, just like WordPress plugins, we'll come up with like, "Hey, don't be using too many of these. Use, use these.

Don't use these. These ones are standard for this. These ones are standard for that." And I, I think that we'll slowly but surely work our way there. [00:54:00] in the world of AI, I mean, just the world in general, nothing is guaranteed because things move extremely quickly. They're all over the dang place, and who knows if skills will be tossed by the wayside for some other MCP connection to this thing, API, blah, blah, blah, memories enhanced.

Who knows, right? Uh, as, as AI moves quickly, we, uh, we churn through, we churn through features like nothing. But I think that's it. That's the episode, an introduction to AI skills/agent skills. Hopefully you enjoyed that. If you have any questions or if you have any skills that you think that we should have looked at or if you're just like, "Hey Matt and Mike, you should check out this skill," like let us know, absolutely, 'cause I'm starting to play with skills.

I'm starting to play with more agent stuff lately, uh, so I'm totally down. Mike is a, is a little more, uh, versed in that stuff, so he might also be down if he hasn't heard of the skill that you're gonna recommend. So please let us know, and, uh, that, that's it for the episode. Thank you for, uh, listening, and if you wanna support episodes like this, you can [00:55:00] do so on Patreon.

That's patreon.com/htmlallthethings, like these $3 tier patrons did. Tim from The Web Hacker on thewebhacker.com, Jason from Geek Life Radio via geekliferadio.com, Garrett Sigal, Level Up Financial Planning via www.levelupfinancialplanning.com, Magnus from Yes Web via yesweb.se, Syntaxify from the HTML All the Things Discord server, and Stacy Mostiller from the website swoonworthydesigns.com. And remember that we have a contributing author. That's Michael Larocca on the HTML All the Things website. Michael is the author of Self-Taught: The X Generation blog at selftaughttxg.com. And if you wanna learn how to code and save on those courses that'll teach you how to code, can use Scrimba, more specifically Scrimba Pro.

Get up to 20% off their Scrimba Pro plan using our link, which will be in the RSS description as well as in the show notes on htmlallthethings.com, and in those show notes you'll also find details on how the link works. And that's it. Feel free to leave a comment or review in the platform you're listening to this on, and we [00:56:00] signing off