So I tried Matt's skills...

0:00There is one particular GitHub repo that I've been eyeing for a long time and just never took the time to dive into. It's by a person that I've interacted with a bunch in the past who, if you've been around for a while, I am sure you're familiar with. I've often called myself the second best TypeScript YouTuber, and the reason is because of this individual, the number one, Matt Pocock. He published a set of AI skills for real engineers that I honestly kind of dismissed initially, but over time he's continued to refine them and be realistic with them. What he's created is a set of small and simple markdown

0:33files that have racked up over 200,000 stars on GitHub, making it one of the 10 most starred projects on all of GitHub. Truly insane. All for markdown files. I wanted to see what the hype was about for a while here, and I've seen people saying really good things about them, especially the grill me skill. And this is also been a video I've planned for a while to the point where my whole Twitch chat is freaking out. Thank you, I stayed up till 3:00 a.m. for this. Long overdue. Finally, three streams ago, since this was put in Notion, Matt's updated the skills multiple times. Yeah, you guys have wanted to get my honest

1:06thoughts on these skills for a while. In order to do that, I had to use them. So, I did. Over the last week, I installed a bunch of the skills from Matt Pocock's skills repo, which is full of gems that are worth talking about, from his process to the actual skills themselves. If I only covered Matt's skills though, I'd be doing this ecosystem a disservice. The vast majority of these skill repos are absolute slop and should be ignored, but there is one other I'm excited about. Pee Stack, created by Lauren, otherwise known as Potato, one of my old favorite React core team members who is now at Cursor, and built

1:41a wild set of skills that are really fun and surprisingly powerful. I have went through and audited the majority of the skills in both of these suites, pulled in my favorites, and I've been using them actively. I cannot wait to show show everything I've learned after a real quick break for today's sponsor. Let's be honest with ourselves. We've moved past the era of doing one thing at a time. And as great as this is, there's

2:03a lot of random problems it's caused. Things like knowing where to run your code when you're working on it, things like making sure your CI is actually running performantly and well, and that it's doing things in parallel, and just knowing what's going on across all of the projects that are shipping at your company. All of this is obnoxious to do by hand, and it's becoming more and more of my work. Well, it was before I started using today's sponsor. You've probably already heard me talk about Depot. They're the best place for your GitHub CI and for your Docker builds, which makes everything way faster, up to

2:2855 times faster for a lot of real-world use cases. Their best-in-class runners make everything faster, and their cache helps everyone on the team get started quicker, too. The cache is shared across your entire team and your CI for your Docker builds, which helps a ton with speed. GitHub Actions are also way faster, too, up to 10 times faster when you use them on Depot than with traditional GitHub Actions CI. And if you add the Depot CI runners, things go even faster because they can do actual parallelism. But that's not what I promised. I was talking about working in

2:55parallel, not just building in parallel. Well, that's where Depot's remote agent sandboxes come in, making it trivial to spin up your real images and your real projects in the cloud with your cloud code. If you already have Depot set up, you can just run Depot cloud instead of cloud directly, and it's now running in a remote sandbox instead. Ship faster

3:11and unblock yourself at swyd.link/depot. Couple things I want to say up front before we go too deep into all of these skills that have been provided by these different places. The first thing, and I really want to emphasize this, you do not get anything out of blindly copying other people's setups. You should treat these things not as a set of steps to take, rather as a set of information to consider as you build your own systems for coding with AI. If you just copy-paste my code base and change

3:39things, you're not a very good engineer. But if you use my code base as a reference point to learn and build your skills as you craft your own code bases, then you're a good engineer. The same difference applies here. If you just blindly copy my exact setup, it's like paying a bunch of money for a code template. It's cringe and bad. It means you suck at engineering, period. So, don't just blindly install all of the skills here. At the very least, start with a slightly better entry point. I see my chat realizing that potato was one of the builders of the React compiler. She was one of the biggest

4:10contributors there. She's unbelievably talented. Yeah, P stack is going to be the underrated gem in this, and I think you guys will like it a lot. But, I want to start first with how I set this all up. I started with a prompt. I want to figure out which potato P stack skills would map well to the work that I do. I want you to audit my usage across my main machines, which were this MacBook, left book, and BB1. Compare my usage against the skills in P stack. Make a nice list ranking all of them by how well they fit me and how much they could

4:37benefit me. Pull history here first, then break up sub agents to do auditing Opus 5 for all. I had a bunch of Opus 5 to burn at the time, so that's why I was testing this. And I linked to P stack. It then created this document for me where it pulled in all the skills and then ranked them based on how strong of a fit they were, as well as how beneficial they would be to my work, and then a little brief why. So, it immediately called out the interrogate skill, blast radius, technical writing, arena, the prove it works skill, and a few others. I will say that this deep

5:08dive was inspired by one particular thing. It was the interest I had in the unslop skill because I had seen Lauren posting some of the pros that her agents wrote, and I was like, "Oh, that looks significantly less cringe than I'm used to Claude writing." So, I quickly grabbed this unslop skill, which is very, very simple. There's also some fun prompting details here in the descriptions potato uses because again, as I mentioned before in my like markdown overhaul video, the description's role isn't to accurately describe everything the skill does cuz it's just markdown. The only point of the description is to trigger the skill when it should trigger. You

5:46should treat the description as the thing that gets the model to do this, rather than as an accurate description of everything the model can do with the skill. I see it kind of similar to a YouTube video thumbnail, where the role of the thumbnail isn't to accurately encapsulate everything that the video has in it. It is to get the right person to stop scrolling and click it and watch it. The goal of the description is similar. It's to get the right agent for the right task to decide, "Oh, that

6:12skill is useful. I should pull that in." It shouldn't be called a description, it should be called a trigger. All of these standards were written in the old Anthropic days before anyone knew what the they were doing. We're stuck with it. It is what it is. Anyways, let's take a look at what the skill's actual content is. So, again, if you're not familiar with how skills work, they have a name and a description. The models have access to all of your skills. They just see the name and the description, and then they decide, "Oh, that skill could be useful to be right now based on its description. I'm going

6:39to pull it in now." And then what it does is it just reads this markdown file into context. So, when it pulls in the unslop skill, here's what it reads. "Edit text to remove AI patterns and add a human voice. The process is simple. Scan for the patterns, rewrite, preserve meaning, match intended tone, add some soul, and then self-audit. Quote, 'What makes this obviously AI-generated?' Then

7:01you go and fix the remaining tells. Adding soul. Removing patterns is half the job. Sterile, voiceless writing is just as obvious. Have opinions. React to facts instead of neutrally listing pros and cons. Vary rhythm. Short sentences, then longer ones that take their time. Mix it up. Acknowledge complexity. Quote, 'Impressive, but also kind of unsettling.' Beats impressive. Use I when it fits. First person isn't

7:24unprofessional. Let some mess in. Perfect structure looks machine-made. Be specific. Not, 'This is concerning.' Rather, 'There's something unsettling about agents churning away at 3:00 a.m.' Don't call me out like this. Patterns to detect and fix. This is one of the things that LLMs are really good at. It's if you give them an example of bad and then show them good, they will follow good very well. But if you don't have certain things in those examples, they will continue to do them bad, so you got to find the balance there. The patterns to detect and fix. The first is in content puffery. So lots of these phrases, pivotal moment, testament to,

7:57evolving landscape, setting the stage. Cut the puffery, say what happened. Name dropping, listing media outlets without context. Just pick one and say what was said. Superficial -ing phrases. Like highlighting, ensuring, reflecting, showcasing. Delete them. Promotional language as well. Vague, you get the idea. It also calls out m-dash overuse. Somehow I still see a lot of m-dashes coming out of Opus. The others have followed this much better. Chat saying that it's a good thing to point out how good the semantic density is here. I agree. This is not slop. This is very easy to read and the info is communicated very effectively. It's just well written. And when you have good

8:39writing in your history, the models are more likely to follow it. And if you tell said models to follow it, they're much more likely to. There's also a whole section here to remove chop out phrases like, I hope this helps, let me know if. Found the smoking gun. All those types of things. No mention of load bearing sadly. There's a whole section about jargon. This is my favorite piece though. Say what it does, not how it feels. Instead of, the database stays close at hand, say something much more direct. dot to sequel returns the exact string sent to the database. That's so much better. Ask what the sentence tells the reader to do

9:12or know, then write that. If you can't restate it as a concise instruction, fact, or number, cut it. One more check. If the sentence could appear unchanged in another project's docs, it says nothing about this one. Cut it. So let's see how this works. I will just ask with GPT 56 high fast. You know what? We'll give it something harder. I'll use Opus 5. Ah, it's going to take too long. I'm going to stick with Sol for this just cuz it will be done faster. What is this project? Help me understand it and why

9:43someone would be interested in using it. All right, I can just grab like any of my other existing Codex threads and you'll see the difference. Here is one where I asked it to update my Swift UI app. Build 26 is uploaded to App Store Connect in processing. Also completed. Bullet point list of the exact things done. Public distribution cannot yet be verified because the App Store Connect process session expired. Sign in at link. Then I can assign build 26 to the public beta group if automatic distribution does not handle it. This is

10:12so easy to read. It's so much better. And you'll notice when I make new prompts, one of the first things that happen is implying of the unslop skill. I'm also applying the required unslop writing skill so the answer stays direct and easy to scan. And then it did. And now it wrote a very simple, easy-to-read blob of text. T3 Code is an open-source

10:33control center for coding agents. Instead of using Codex, Claude, Code, Cursor, Grok, or Open Code through separate terminal tools, you control them through one desktop, web, or mobile app. I'll show you the comparison in the easiest way I can think to do it. I'm going to ask in ChatGPT directly where I don't have my skills to look at T3 Code. Same rough prompt, just like said what

10:50it was specifically to make it easier. Let's see how it does here without the skills. The core idea is already clear. T3 Code is not another coding model and not mainly an editor. God. I didn't realize how quickly I adjusted to unslop text. And now when I read the slop text, it hurts me. It's actually insane how much of a difference I can already see just from that. Again, T3 Code is an open-source control center

11:16for coding agents. The core idea is already clear. What using it looks like. A normal workflow is run the command, open a project, start a thread, ask it to inspect or change the project, review messages and code changes, continue from your desktop, browser, or phone. T3 Code also manages terminal terminals, agent sessions, get diffs, and checkpoints. Each turn can have a checkpoint, which lets you inspect or revert what the agent changed. Short version, T3 Code's a cross-platform control center. This is the like quote from the docs. It turns these providers from separate terminal programs into one coherent agent workspace {m-dash} with desktop, web, iOS, and Android clients. There's like

11:55T3 Code is and T3 Code is not. The strongest pitch is not chat with AI in nicer windows. It is operating several autonomous developers without living in several terminal tabs. Remote agents become practical. One interface across providers. It's designed for parallel work. The especially compelling use case for your setup {uh} versus why someone would use it. One interface works with several providers. Threads persist, so work's easier to resume. You can control agents on another computer from your phone or browser. Your files and provider credentials remain on the machine during running the server. It's insane these both came from the same model for adding

12:34one markdown file. It's so much more readable. I have been enjoying coding so much more since I installed this one stupid skill. Thank you, Potato, and thank you, P-Skill, for providing me this wonderful unslop skill. Hopefully, you can now understand why I so quickly went down this rabbit hole. It's because I was really impressed with that skill once I installed it. So, I then went through all the P-Skill skills to see which other ones might fit me, too. And as I was doing this, I had the realization that I'm sure you guys could have predicted that I also should probably look at the Matt Pocock skills. So, I

13:09linked that as well and ended up getting another document of all of Matt's skills and which ones fit my use case as well. Now, it's time to dive in to all of these skills and what value they can bring you. I've been focused on P-Skill for a bit too long, so let's hop over to Matt's skills instead. The main directory that we care about is

13:28skills/skills/engineering. There's ask Matt, code review, code base design, diagnosing bugs, domain modeling, grill with docs, which is an update to his grill me one, implement, improve code base architecture, prototype, research, resolving merge conflicts, set up Matt Pocock skills as a skill itself, TDD, to spec, tickets, triage, wayfinder, and wizard. I want to start by playing with a few of these. I'm going to grab the improved code base architecture and grill with docs. If you're ever curious about a skill and how it behaves, the easiest thing to do is into to install it and then hope for

14:06the best. It's actually quite simple. You can usually just copy-paste it. In this case, this skill is calling for other skills. It's actually hilarious how simple the grill with docs is. It's a relentless interview to sharpen a plan or design, which also creates docs, ADRs, and glossary as we go. He also has disabled model invocation on for a lot of his skills, which means the model won't enable it itself. You have to manually pull it in with a slash command or a dollar sign command or something like that, which I think is a very good call, especially with how some of his skills work. But some of them that isn't

14:38necessarily the case. Like when I'm going through the diagnosing bugs skill, this one I probably shouldn't have to manually pull in. And sure as hell, he doesn't have this as a manually pull in skill. This is a skill that will invoke itself when it's helping debug issues. And I've had this skill fire and help with a lot of my debugging stuff over the last few days, and it's been pretty solid. It seems like my agents find the root cause and can communicate what's wrong much more effectively. So, let's look at the new grill me and grilling skills because these are the ones that are referenced there. Here is the

15:09grilling skill. Grill the user relentlessly about a plan decision or idea. Use when the user wants to stress test their thinking or use any grill trigger phrases. Interview the user relentlessly until you reach a shared understanding. Map this as a design tree. Every decision branches into the decisions that hang off it. Work the tree in rounds. The frontier is every decision whose pre-reqs are already settled. God, why is he using m-dashes

15:33in his skills? Matt. Matt. How many are on this? There's nine m-dashes in this page. Matt, I was wondering why I was getting m-dashes again. It might be Matt's skills. There's at least one per paragraph for most paragraphs. Oh, this hurts me. I'm still going to try it. And I told you guys there's an easy way to try skills. You copy the text. Go to your

15:58agent. You do whatever you want to do. Then you paste it. So, I'm going to ask it to grill not me. Ask it to grill Lakebed. Lakebed. Paste. Pick machine. I want you to grill me about Lakebed, the project itself, and its goals, everything in the agents, CMD, Claude, MD, etc. I want to make sure we are on the same page about what we are building. I want to use Matt Pocock's

16:32grill skill. Don't have it installed. I will paste the text below. And now I have successfully used the skill without installing anything by just copy-pasting the text. Obviously, this will not work with skills that have other things like scripts associated and whatnot, but you can copy the script over, it's fine. Or just tell the model about it. It can go find the script and download it. It's fine. But this is the easiest way to test out a text-only skill. Literally just copy-paste the

17:01text. And now we have this Opus 5 run on my remote Linux box running, and it will grill the out of me momentarily. It took almost 2 minutes, but it has its first pass here. Claude MD's badly stale. The repo countries its own V0 rule, and there are two competing execution models in the

17:20tree. Question one, who is the user and who pays? As well as example answers we could give. Question two, what is the actual next milestone? Cuz there's a massive like launch prep files, HTML files with like random plans, the to-do MD that's in organized from a PR cleanup program not as launch. Q3, is the capsule format a spec or just

17:45our implementation? What is the ceiling of one capsule? These are actually good questions. And now I'm curious, do we get similarly good questions if I ask a different model? Let's switch over to Soul with the exact same thing. Oh, I already have the grilling skill installed. Good, I did carry that over. God, the 5-6 autism is so real. The grilling skill requires me to find repo

18:06facts instead of asking you. I just realized I use this on low and slow. I should be using this on high and fast. Get better answers faster. I will stop that cuz I don't care anymore. Oh wow, it finished before the stop even persisted. That's hilarious. What is Lakebed? Who is the primary customer? What does full autonomy mean? And what is a capsule? All good questions. Let's see how the high version does. Oh, and high it spun up some sub-agents in the background to do more hunting to get more data for future questions. So I wrote the same, what's Lakebed? Who is the primary user? All with like quick

18:41answers, which makes it really easy to go through just like 1A, 2B, 3A, etc. Again, like the question asking tools in a lot of these harnesses and agents just aren't good enough to have the like question asking UI come up. So this is a lot quicker to just blast through. So one, I'm going to say it's the autonomous app platform. Two, I'm going to say these two are the users that matter. Three doesn't give me a simple answer, but I can just tell it what I don't want, which is agents to do everything other than

19:10payment details. Four, how much should Lakebed own? Uh own everything as needed. Five, which rule wins? The current guidance contains principles that will conflict. I want simple where possible, but also rewrite where beneficial. Six, what is the product boundary? Should Lakebed remain a real, open, and useful system while the hosted cloud platform is the production path? Uh local is only dev sim. That's nice and easy. And I'm already realizing that I need to clean up this project based on the simple

19:46quick start of this grilling section. Okay, I'm seeing the light. This is useful. I should have tried this before. Let's keep going through these skills. Teach is one I've heard really good things about. This one is also disabled model invocation, so you have to trigger this with {slash} teach. The users asked you to teach them something. This is a stateful request. They intend to learn

20:06the topic over multiple sessions. Interesting. Treat the current directory as a teaching workspace. The state of their learning is captured in this directory in several files. Very interesting. So, you're supposed to use the teaching skill in like its own folder. Huh. I want to read more from the top level. I feel like I am not going through this the right way. Interesting. One of the skills is ask Matt, which is specifically meant to help you figure out what skills or flows fit your situation. There's grow with docs, which we talked about before. Triage, which helps move issues through a state machine of triage roles. Improve code

20:40base architecture. This is one I actually wanted to try. A lot of these are self-referential where like the code base architecture one will say to run the code base design skill in order to get the vocabulary. Present candidates as an HTML report. Nice. Somebody likes HTML skills, I like this a lot. Context and D vocabulary for the domain. Da da da. Then it calls out

21:02grilling as well as domain modeling. Wayfinder's a fun one, too, for planning huge chunks of work. I also really like the separation in the docs between user invoked and model invoked cuz these are very different. Like these are effectively plugins that you call when you want them yourself. Model invoked is more steering the model to do different things in different ways. And these ones are very useful. Like I said mentioned before the diagnosing bugs one has helped me a ton already. Wizard seems really cool too. To walk human through steps only they can perform. This is super cool when like an agent can't access some dashboard it needs to or

21:36there's a pseudo call that it can't run. Wizard is a guide to help the agent set things up so that you can just run the one script and then handle things from there. Uh do I have this one? Cuz if I don't I'm going to go add it now. I don't. I guess here I'll give you the spoiler of how I actually set up all of these

21:55things. I did all of this in a thread in T3 code in a repo that I already made called fleet where I manage all of my like skill files and things. So in here I'm going to do this specifically. I'm going to ask a did we set up the wizard skill from Matt's repo? If not, set it up now. Note that we have one more machine in the fleet to deal with. Well, cuz since I last worked on this I added my new Mac mini so I want to just give it a quick little hint that the new Mac mini exists so that it will touch that as

22:29well. Earlier I should have been reading the docs the whole time. My bad. Yeah, the getting started is the setup skills command which helps you like set up issue tracking and whatnot in a way that the skills will handle it. The main flow is to start with grill with docs, get interviewed about a plan and record the decisions, then to spec turn into a spec, then to tickets to cut that into tickets for Jira, linear, GitHub issues, whatever you want to use. Implement for actually building it and then code

22:53review for reviewing it after. Shaping is fun for turning vague ideas into real executable plans. Wayfinder helps you chart a large effort as a map of decisions and settle them. Prototype is for actually like making designs and mocking things to see what you really want before you ship it. Just deletable code. And the research skill for getting cited answers from primary sources. I don't know if I would ever need that. I feel like the agents are pretty good at

23:20verifying their claims if you just ask. Then we have improved code base architecture. This one seems fun. Diagnosing bugs, resolving merge conflicts, triage, and wizard. I am excited to try out wizard. For activity skills like grill me, hand off, to questionnaire, teach, wait, what, and writing for agents. Then the reference skills like code base design. Vocabulary for deep or designing deep modules, sharing the words a project uses and writing them down. Domain modeling I think is a really helpful one. I've been in like writing down my own grammars in like glossaries with agents in every project on like what terms we use to do different things. The idea of being a

23:56skill does make sense to me. I am increasingly tempted to just install all of them, but I am very happy with my current setup and I don't want to muddy it too much more. So I'll continue doing what I normally do, which is just telling my agent to rip the parts I want and keep them in my fleet directory. This little fleet repo saved my ass so many times. While that is

24:17running, let's see the follow up here. Okay, we got a bunch more questions. Which form of simplicity matters most? Oh, this is brutal cuz I want all of these types of simplicity. God, this is This gets deep. I don't want to answer these questions. That's the point, isn't it? I I really don't want to have to answer this cuz my answer is all three of these. I want them all. Okay, I said I will begrudgingly pick A even though I

24:40want them all. What apps must Lakebed support? A and B, not C. How do the two primary users divide control? If the developer and agent are both primary, what does each one own? So like who chooses architecture, data models, deploy timing, etc.? Dev chooses nothing but app functionality. Cool. That's it. That is answered. 10. Does

25:03everything include irreversible actions? Authorized agents be able to delete production data? Uh yes, they should be able to do whatever. Where is the payment boundary? Will be subs plus monthly limits. Agents can use them as they please. 12. What must the local simulation preserve? B. Cool. This is great. I'm actually disagreeing with the recommended answers pretty often,

25:29too. This is actually going to help me. I'm annoyed. Now this skill is on all my machines. Cool.

25:42Opus caught all the changes to my systems. I know it's silly, but like all this text is so much more readable than older agentic stuff I was doing in like the same project with the same code base and the same agents and models and everything. I asked a question and it gave me a direct answer. No, Wizard was never set up. It ranked seventh in the previous report, but you only pick seven skills and it wasn't among them. I It's installed now. Whereas like if I scroll back far enough to things for before I had these set up, just like any old

26:10thread. Here's a recent changes summary. Here's a ready to share write up. I treated landed as changes that reach main. T3 code the last 3 days. Oh no, this is it trying to like match my tone. Release publication now uses the job scope with GitHub token competing for the rate the shared release app API

26:29quota. Fixing repeated nightly failures. Oh god, the M-dash how. I said push straight to his branch. Done. The follow-up commit is now on his PR branch directly. M-dash 5561 shows it's the fifth commit and the review bots are rerunning against the new head. His PR is still based on one merge behind. The thread pagination PR landed since. It's still mergeable for GitHub, so no action needed. Rebasing his branch under him felt more intrusive than the situation called for. Worth watching whether the effect service convention check goes green now. M- That was the hard blocker in my context. reference approach is a lighter a lighter remedy. Oh god, I

27:03can't even like read this and I'm trying to like read it out loud for you guys in a video. It's so much worse. God, life post slop is unbelievably cool. Oh god, I got another like 10 plus questions for me. I'm going to do this off stream, but I'm actually going to do it because these are good questions. This does remind me that I have a branch I was working on in T3 code that I'm I have new ideas for now, too. I was working on

27:28a skill manager feature in T3 code. Yeah, this cross computer skill manager page that I was working on to make it easy to just manage skills on your machines through like one layer. What I want is now is the ability to disable them en masse, like to have groups of skills, like the P stack skills and the map poll skills and be able to turn them all on or off or just turn on the ones I want. Oh, that would be so nice. Yep, the wizard skill has now appeared on all of my machines. Yay. I don't have anything that needs wizard right now,

28:01but I am very excited to try that one. It makes a ton of sense to me. I will say most of these skills feel more like prescribing like mental workflows and like giving you an easy entry point to try them out. Especially stuff like the main flow section here with the grill with docs to spec to ticket implement code review. I don't necessarily want this much

28:22prescription on how I go step by step. Like I've been building my own workflows and they don't map quite as well to traditional stuff. There's a ton of good things that I'm grabbing from here, like the wizard skill, the grilling skill is clearly super super useful. I'm going to play more of the code base design and the like follow up clean up ones. I have heard wait, what is really good, as well as the writing for agents. The writing for agents one I've actually been using a bunch. Writing great skills was turned into writing for agents. This is useful because agents are really bad at writing

28:55instructions to other agents. If you let your agents write skills for you, write markdown for you, write prompts to sub agents for you, all those types of things, it can do a very bad job. So, giving it better instructions on how to do it right sounds very compelling to me. Wait, what's another one that I'm really excited about. It pulls in simplified technical English, which a dedicated video on this bit coming in the near future. It's a simple skill that's user invoked and three lines long. The point is to get a simpler easier to digest description of something when you get a response that makes no sense. He does call out that

29:28this only appears one message, it doesn't prevent the next sloppy one. The solution in the cure for this type of jargon is a shared language built up front using the grill me with docs skill. Reach for wait, what when you don't have that set up done yet. I am very excited for wizard. I'm going to be using that a ton. I I can think of like four things I should have used it for yesterday. I really like how he's documenting all of this stuff. Like this is a good docs page. There's a lot to learn from here in the best sense. Here we are, wait, what? Super simple. And

29:55again, it disabled model invocation. It means you just type in the one skill invocation with the slash command dollar sign whatever. Wait, not m- ah, I almost want to make a d-m-dashed Matt Pocock skills fork where it's just the exact same repo with all the m-dashes removed. The description, stop. That last message did not land. M- repitch it. God, I I almost want to see how many m-dashes are in this project. Yes, just one regex to remove it all, I know. This is one I was actually really excited about, the the

30:26writing for agents. Oh, this one's long. Good, it should be. Reference for writing any document that an agent consumes, a skill, an agent or CloudMD, a doc reached by a pointer. I've mostly been using this for prompting sub agents and it's been very helpful there. Too many m-dashes still. When the document you're writing is a skill, read the skill mechanics md file for front matter invocation choice and

30:46router skills. Context pointers. Context pointers are reference held in the agent's context that names some out of context material and encodes the condition for reaching it. The skill's description is one. A line in agent md naming a doc is the same object. The pointer's wording, not its target, decides when an agent reaches the material and how reliably. A must-have target behind a weakly worded pointer is a variance bug. This is unreadable. I mean, I'm not surprised, but god damn. Ow. Versus Unslop, just a

31:17chunk of it. No. No. I don't trust these anymore. Does it just seem markdown as AI generated? Is that my problem here? Cool, I passed 100% human written. Yeah, very likely all of these were written by AI, which is annoying cuz I have had not great luck with AI written stuff. I'm amazed that the Unslop one is allegedly AI though, because that skill read very easily and was very dense and well-written. I will say, regardless of if they're both AI generated, I find P Stack writing to be a lot more readable, and also the behaviors from these skills to be a lot more applicable for my

31:58day-to-day. The Arena one has been super fun. Fan out and parallel attempts at the same task. Read every candidate end-to-end, pick the strongest as the base, graft the best ideas from the others into it, and verify the synthesized results. This has been a very fun skill for those of us who are token burners cuz we have a bunch of usage to get through. Start the to-do list with one entry per phase before launching anything. The Arena runs autonomously and the list keeps phases from silently disappearing. Frame, fan

32:25out, cross judge, pick, graft, verify. Then descriptions of each phase. Surprisingly little text for how much this does. Like this one skill has cost me hundreds of dollars of inference cuz it just does the same thing multiple times. This write-up is very much tied to cursor specifically, which is the biggest issue with P Stack. I honestly would be pumped if somebody like cloned all the P Stack skills in a generic not cursor specific way because there's so much gold in here. But a handful of these are just a little too cursory. She did also pull the bro skill from uh I believe it was originally Dylan Mulroy, the effect in functional

33:04programming JavaScript guy. "Resate your last message. Stop using jargon and speak coherently. State it more simply and concisely like one human talking to another." I think this is basically identical to wait, what? Yep. Pretty much identical. Also one of the few that potato has is disable model invocation, which is interesting. She normally just lets the model do its

33:24thing. Blast radius is awesome, too. I've been using this one a ton. "Find what a change breaks somewhere else before it ships. Use blast radius of X, what could this break?" Or "Reviewing a small diff that you don't trust." Comparison companion to how and why. How tells you what the code does, why tells you why it shaped that way, blast radius

33:41tells you what it breaks somewhere else. I love this calls out you can't trust your own write-up specifically saying that like the history of this thread is not trustworthy, so don't hand back the write-up. Find the one or two facts the whole thing depends on and prove them by running code. This one is great and has cop a couple of things that would have been miserable if I didn't have it. It also calls out that it should write the response through unslopped to make sure

34:02that it's not a mess. This is great. I didn't want this to be like a one or the other thing where it's like P Stack versus PoC skills. I didn't intend for it to be that at all, but I'm much more philosophically aligned with what potato is cooking over here. Oh, yeah, she also has the show me your work skill, which is really cool if you ever want to understand why an agent did something to like keep track of what's going on. Keep a reviewable decision trail for long-running and unattended work. A TSV log with one row per decision, what, why, evidence, and result. Local by default, committed when

34:37a reviewer needs the trail to trust the result. Use for slash show me your work, autonomous or multi-phase runs, or work a human reviews after stepping away. Gives it a format on how to log its work and its decision-making process all in a simple TSV format that is easy to like read and do with other things. One row is one decision or checkpoint. If it doesn't fit one line, the decision isn't crisp yet. Pend only. A wrong call gets a new row that supersedes it. Prefer evidence produced by committed scripts over handmade one-offs so a reviewer can rerun it. Interesting. This one seems really cool actually. I'm going to play

35:11with this more later. This video is supposed to be an overview, but what you're getting instead is my actual process. I did pretty much exactly everything you're seeing here, but with slightly less depth a few days ago. And that's how I found the cool skills that I did find. And this is what you should be doing as well. You shouldn't just blindly install a bunch of when you could take the time to read the things that map up to the work you do and how you do things and pull over the parts that you actually want. And it all should start with something small. Like grab the one you like. I think everyone

35:42should have on slop at this point. This skill has fundamentally changed my willingness to read the things that my agent say to me. It's been great. God, that this video could be hours long or it could be a 45-second short. It could be a lot of different things. It isn't quite what I expected it or wanted it to be, but I hope you can get some good takeaways from it still. The first thing you should do is you should grab your agent and you should open it up and tell it about Pystock and tell it about Matt Pocock's skills and ask it to look through them and then look through your

36:15histories and figure out what makes sense based on what you do. Maybe you should install the on slop skill before that though because then you'll actually want to read the responses you get. Afterwards, you should look through that. You should read the markdown for the skills you're installing before you install them. Then you should decide which ones you want. You can tell your agent to set it up. You can do a single repo that represents all your skills

36:37like I do. I think it's really powerful. You've a lot of options here for how you choose to manage all of this. But you should be managing it. You shouldn't be blindly copying someone else's setup. You shouldn't be running commands that install 500 skills you don't know anything about. You should take this opportunity to refine your toolbox based on what you see working for others and what you try setting up yourself. You should, based on your own history and your own usage, make subtle adjustments and changes. And you shouldn't be scared of editing these files. I've noticed a lot of people are scared of opening up

37:07their quad files and like the dot quad and the dot agents directory on their machines. That's silly and you have to get over it. Because there is so much cool you can do the moments you start digging in and playing with these things. You got to be willing to edit those files. I joke now that the only time I open my code editor is to edit markdown files, but like it's barely a joke at this point. It's markdown files and environment variables

37:33at this point. And it has helped a ton. It's one of the biggest shifts that has allowed me to do way more parallel agent work. It's a huge part of why I was able to ship so many PR's with so little breakage over the last weekend. The way it works really different now. And it's largely because I took the time to go deeper in these directories and pull together skills for myself and others

37:55that make sense for the work that I do. And I hope this inspires you to go do the same. Explore these collections of skills people have published. Don't blindly install them. Poke around at them. Try them out. Pull the parts you like. Ignore the parts you don't. Play. I think I've said all I have to here. There's some really good stuff in Matt's skills and even more good stuff in potato skills. Check both out and maybe make some of your own, too. I'm curious how this affects your workflows. Let me know. And until next time,

38:20peace, nerds.