Auditing AI Skills: Why Matt Pocock and Potato's Markdown Prompts Change Agentic Coding
A pragmatic audit of over 40 agent skills across GitHub repos, testing concision prompts, architectural stress tests, and parallel sub-agent workflows.
You use AI coding agents like Claude Code, Cursor, or Codex and find agent outputs verbose or evasive.
You want structured engineering workflows such as decision-tree architecture grilling or automated blast-radius checks.
You are curious about managing cross-machine agent skills without polluting local agent environments.
SKIP IF…
You do not use terminal-based AI coding agents or LLM-driven development environments.
You expect turnkey prompt templates that require zero contextual adaptation.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Theo introduces Matt Pocock's AI skills repository and explains why simple markdown prompt collections became some of the most starred projects on GitHub.
01:58 – 03:24
02 · Pstack and Sponsor Break
Introducing Potato's Pstack repository alongside Matt Pocock's tools, followed by an overview of CI/CD bottleneck elimination using Depot's sandboxes.
03:24 – 04:20
03 · First Principles: Do Not Copy Setups Blindly
A warning against blindly importing skill libraries, emphasizing that developers must treat repositories as reference points rather than universal templates.
04:20 – 05:15
04 · Auditing Skills Against Real Usage Logs
Using Opus 5 to analyze past command-line transcripts and machine activity to programmatically rank which skills offer the highest marginal utility.
05:15 – 09:24
05 · The Power of the Unslop Skill
Deep dive into the Unslop prompt: eliminating AI puffery, verbosity, em dashes, and corporate phrasing to maximize technical semantic density.
09:24 – 12:25
06 · Comparing Agent Responses With and Without Skills
A side-by-side test in T3 Code versus vanilla ChatGPT shows the striking difference in speed, readability, and structural conciseness.
12:25 – 16:05
07 · Testing Matt Pocock's Engineering Suite
Reviewing Matt Pocock's engineering directory, dissecting user-invoked versus model-invoked execution, and manually testing 'grill-with-docs'.
16:05 – 20:05
08 · Live Architecture Grilling on Lakebed
Running the grilling skill on a live project (Lakebed) forces the LLM to generate strict multi-choice decision trees before implementing features.
20:05 – 23:45
09 · Teach, Wayfinder, and Wizard Walkthrough
Examining stateful learning skills, decision-mapping via Wayfinder, and bash setup scripting through the Wizard skill.
23:45 – 30:20
10 · Writing for Agents and Context Pointers
Exploring how to write markdown that sub-agents interpret cleanly without introducing ambiguity or high cognitive context overhead.
30:20 – 35:30
11 · Arena, Blast Radius, and Show Me Your Work
Analyzing parallel agent competition in Arena, verifying breakage with Blast Radius, and generating audit logs via Show Me Your Work.
35:30 – 38:21
12 · Conclusion and Practical Recommendations
Final thoughts on treating agent environments as personal dotfiles, continually pruning unused prompts, and learning to write precise markdown.
Atomic Insights
Lines worth screenshotting.
Skill descriptions in agent markdown files function strictly as model triggers, not comprehensive user documentation.
The 'unslop' skill forces LLMs to eliminate corporate buzzwords, puffery, and conversational filler, dramatically improving scanning speed.
Blindly copying developer configurations without adapting them to specific repos is equivalent to paying for boilerplates you do not understand.
Prompting an LLM to evaluate your shell and agent command history is the most effective way to rank which external skills you actually need.
The 'grilling' skill forces an agent to challenge project assumptions via branching decision trees before writing any implementation code.
Parallel agent exploration via an 'arena' pattern yields higher quality code synthesis but significantly multiplies inference costs.
Writing instructions for AI agents requires tighter semantic density because weak pointers create variance bugs across multi-agent handoffs.
Engineering velocity with coding agents shifts modern developer work from writing boilerplate code to editing markdown directives and configuration variables.
Takeaway
Curate and Refine Your Agent Prompts Like System Dotfiles
CORE STRATEGY
Effective AI coding requires actively pruning skill files, auditing past agent session transcripts, and enforcing strict concision standards over raw verbosity.
Audit your command history with an LLM to identify the exact procedural failure points in your current agent setup.
Enforce concision directives like Unslop to eliminate conversational fluff, corporate marketing buzzwords, and distracting em dashes.
Treat skill descriptions as functional regex triggers rather than documentation so that models only activate them when strictly necessary.
Use structured interview skills like Grilling to build decision trees and clarify scope before letting agents generate code.
Isolate automated skills from user-triggered workflows to prevent agents from hallucinating complex multi-step procedures during simple edits.
Maintain a centralized dotfiles-style repository to synchronize verified agent skills across all development machines seamlessly.
00:00 – 05:15steadyEvaluating viral AI skill repositories and prompt standards
05:15 – 12:25denseThe Unslop skill and eliminating AI text artifacts
12:25 – 20:05denseInteractive testing: Grilling, Lakebed architecture, and decision trees
20:05 – 35:30denseMulti-agent orchestration: Teach, Wayfinder, Wizard, and Arena
35:30 – 38:21steadySynthesis: Managing agent dotfiles and selective skill adoption
The Script
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
17px
metaphoranalogy
There 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 has continued to refine them and be realistic with them.
And what he's created is a set of small and simple markdown files 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've 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 has 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 3AM for this. Long overdue. Finally, three streams ago.
Since this was put in Notion, Matt's updated the skills multiple times. Yeah. Because I've wanted to get my honest thoughts 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.
Pstack, created by Lauren, otherwise known as Potato, one of my old favorite React core team members who is now at Cursor, and built a 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 you 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 a 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, 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 55 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 Action 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 parallel, 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 Claude code. If you already have depot set up, you can just run depot Claude instead of Claude directly, and is now running in a remote sandbox instead.
Ship faster and unblock yourself at soydev.link/depot. Couple things I wanna say upfront before we go too deep into all of these skills that have been provided by these different places. The first thing, and I really wanna 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 things, 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 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's one of the biggest contributors there. She's unbelievably talented. Yeah, PStack is gonna be the underrated gem in this, and I think you guys will like it a lot.
I wanna start first with how I set this all up. I started with a prompt. I wanna figure out which potato PStack 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, Leftbook, and BB one. Compare my usage against the skills in PStack. Make a nice list ranking all of them by how well they fit me and how much they could benefit me.
Pull history here first, then break up sub agents to do auditing, Opus five for all. I had a bunch of Opus five 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 dive 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, because it's just fucking markdown.
The only point of the description is to trigger the skill when it should trigger. You should 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 kinda similar to a YouTube video thumbnail where the role of the thumbnail is into 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 skill is useful.
I should pull that in. It shouldn't be called the description. It should be called the trigger.
All of these standards were written in the old Anthropic days before anyone knew what the fuck they were doing. We're stuck with it, it is what it is. Anyways, let's take a look at what the skills actual content is.
So again, if you're 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 me right now based on its description. I'm gonna 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 you 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 unprofessional.
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 3AM. Don't call me out like this.
Patterns to detect and fix. This is one of the things LMs 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 gotta 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 evolving 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 dash I n g 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's 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 writing 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 chatbot 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 two SQL returns the exact string sent to the database. That's so much better. Ask what the sentence tells the reader to do or 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 five six high fast.
You know what? We'll give it something harder. I'll use Opus five.
That's gonna take too long. I'm gonna stick with Sol for this just because it will be done faster. What is this project?
Help me understand it and why someone would be interested in using it. Or I can just grab like any of my other existing Codex threads, and you'll see the difference.
Here's one where I asked it to update my SwiftUI app. Build 26 is uploaded to App Store Connect and Processing, also completed. Bullet point list of the exact things done.
Public distribution cannot yet be verified because the App Store Connect browser 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 so 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.
T three code is an open source control center for coding agents. Instead of using Codex, Cloud Code, Cursor, Grok, or OpenCode through separate terminal tools, you control them through one desktop, web, or mobile app. I'll show you the comparison and the easiest way I can think to do it.
I'm gonna ask in ChatGPT directly where I don't have my skills to look at t three code, same rough prompt, just like said what it was specifically to make it easier. Let's see how it does here without these skills.
The core idea is already clear. T three code is not another coding model and not mainly an editor. Ugh.
God. I didn't realize how quickly I adjusted to unslopped text, and now when I read the slopped text, it hurts me. It's actually insane how much of a difference I can already see just from that.
Again, t three codes at Open Source Control Center for coding agents. The core idea is already clear. Ugh.
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. T three 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, t three codes across Firewall Control Center. This is the, like, quote from the docs.
It turns these providers from separate terminal programs into one coherent agent workspace, Emdash, with desktop, web, iOS, and Android clients.
There's like t three code is and t three 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, ugh, versus why someone would use it.
One interface works with several providers. Threads persist so it works 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 one markdown file.
It's so much more readable. I have been enjoying coding so much more since I saw this one stupid skill. Thank you, potato, and thank you, pstack, for providing me this wonderful unslop skill.
Hopefully, 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 Pstack 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 linked 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 Pstack for a bit too long, so let's hop over to Matt's skills instead. The main directory that we care about is skills slash skills slash engineering.
There's ask Matt, code review, code based design, diagnosing bugs, domain modeling, grill with docs, which is an update to his grill me one, implement, improve code based architecture, prototype, research, resolving merge conflicts, set up Matt Pocock skills as a skill itself, TDD, to spec, to tickets, triage, wayfinder, and wizard.
I want to start by playing with a few of these. I'm going to grab the improve codebase architecture and grill with docs. If you're ever curious about a skill and how it behaves, the easiest thing to do isn't to install it and then hope for the 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 planner design, which also creates docs, ADRs, glossary as we go. He also has disable 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 command or a dollar sign command or something like that, which I think is a very good call, because it was how some of his skills work. But some of them that isn't necessarily 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 indicate 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 grilling 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 prereqs are already settled. God, why is he using Em dashes in his skills? Matt.
Matt.
How many are on this? There's nine em dashes in this page. Matt, I was wondering why I was getting em dashes again.
It might be math skills. There's at least one per paragraph for most paragraphs. Oh, this hurts me.
I'm still gonna try it. And I told you guys, there's an easy way to try skills. You copy the text, go to your agent, you do whatever you wanna do, and then you paste it.
So I'm gonna ask it to grill, not me. Ask it to grill lake bed. Lake bed.
Paste, pick machine. I want you to grill me about Lakebed.
The project itself and its goals, everything in the agents, MD, Claude, etcetera.
I want to make sure we are on the same page about what we are building. I want to use Matt Hocock's grill 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, 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 text.
And now we have this Opus five run on my remote Linux box running, and it will grill the fuck out of me momentarily. It took almost two minutes, but it has its first pass here. CloudMD is badly stale.
The repo counter has its own v zero rule, and there are two competing execution models in the tree.
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?
Because there's a mess of 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. Q three, is the capsule format a spec or just our 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 Sol with the exact same thing. Oh, Oh, I already have the grilling skill installed. Yeah, I did carry that over.
God, the five six autism is so real. The grilling skill requires me to find repo facts 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 because 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 Hi version does.
Oh, and Hiatt spun up some sub agents in the background to do more hunting, to get more data for future questions. Start with the same, what's Lakebed, who is the primary user, all with, like, quick answers, which makes it really easy to go through just like one a, two b, three a, etcetera.
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. This is a lot quicker to just blast through. So one, I'm gonna say it's the autonomous app platform.
Two, I'm gonna 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 should do everything other than payment details.
Four, how much should Lakebed own? 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's the product boundary? Should Lakebed remain a real, open, and useful system while the hosted cloud platform is the production path?
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 quick 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 disable 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 the 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.
I wanna 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 grill with docs that we talked about before. Triage, which helps move issues through a state machine of triage roles.
Improve code based architecture. This is one I actually wanted to try. A lot of these are self referential, where like the code based architecture one will say to run the code based design skill in order to get the vocabulary.
Present candidates as an HTML report. Nice. If somebody likes HTML skills, like this a lot.
CodexMD vocabulary for the domain. Ta ta da. Then it calls out grilling 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, because 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 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, there'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. Do I have this one?
Because if I don't, I'm gonna 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 things.
I did all of this in a thread in t three 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, 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, because since I last worked on this, I added my new Mac Mini, so I wanna just give it a quick little hint that the new Mac Mini exists so that it will touch that as well. Apparently, I should've 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 it into a spec, then to tickets to cut that into tickets for Jira, linear, GitHub issues, whatever you wanna use, implement for actually building it, and then code review 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 verifying their claims if you just ask. Then we have improved code based architecture. This one seems fun.
Diagnosing bugs, resolving merge conflicts, triage, and wizard. I am excited to try out wizard. Productivity skills like grill me, hand off, to questionnaire, teach, wait what, and writing for agents.
Then the reference skills like code based design. Vocabulary for deep or designing deep modules, start reading the words a project uses and writing them down. Domain modeling, I think, a really helpful one.
I've been in, like, writing down my own grammars and, like, glossaries with agents in every project on, like, what terms we use to do different things. The idea of it being a skill does make sense to me. I am increasingly tempted to just install all of them, but I'm 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 running, let's see the follow-up here.
Okay. We got a bunch more questions. Which form of simplicity matters most?
Oh, this is brutal, because I want all of these types of simplicity. God, this is, this gets deep. I don't wanna answer these questions.
That's the point, isn't it? I I really don't wanna have to answer this, because my answer is all three of these. I want them all.
Okay, I said I will begrudgingly pick A, even though I want 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, etcetera?
Dev chooses nothing but app functionality.
Cool. That's it. That is answered.
10, does everything include irreversible actions? Authorize agents be able to delete production data? Yes, they should be able to do whatever.
Whereas the payment boundary will be sub plus monthly limits. Agents can use them as they please.
12, what must the local simulation preserve be? Cool.
This is great. I'm actually disagreeing with the recommended answers pretty often too. Fuck.
This is actually gonna help me. I'm annoyed. Now this skill is on all my machines.
Cool.
Opus 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, 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. It's installed now.
Whereas, like, if I scroll back far enough to things from before I had these set up, just like any old thread, here's a recent changes summary. Here's a ready to share write up. I treated landed as changes that reach main.
T three code the last three days. Oh, no. This is it trying to, like, match my tone.
Release publication now uses the job scoped GitHub token instead of competing for the shared release app API quota, fixing repeated nightly failures. Oh god, the m dash hell.
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 per 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, em dash.
That was the hard blocker, and my context dot reference approach is a lighter remedy. Oh god, I can'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 gonna 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 t three code that I'm I have new ideas for now, too. I was working on a skill manager feature in t three code.
Yeah, this cross computer skill manager page that I was working on that 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 Matt Pocock skills, 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, but 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 take an implement code review.
I don't necessarily want this much prescription 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 gonna play more at the code based design and the, like, follow-up cleanup 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 instructions 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 Simplify 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 this only repairs one message. It doesn't prevent the next sloppy one.
The solution and the cure for this type of jargon is a shared language built upfront using the grill me with docs skill. Reach for wait what when you don't have that setup done yet. I am very excited for Wizard.
I'm gonna be using that a ton. I 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 again, disable model invocation.
It means you just type in the one skill invocation with the slash command dollar sign whatever. Wait. Not em dash.
I almost wanna make a dm dashed Matt Pocock skills fork, where it's just the exact same repo, but all the em dashes removed.
The description, stop. That last session did not land. Em dash, repitch it.
God, I I almost wanna see how many em dashes are in this project. Yeah. It's just one regex to remove it all, I know.
This is one I was actually really excited about, the the writing 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 clotMD, 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 router 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.
Align an 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 goddamn.
Ow. Versus unslopped.
There's a chunk of it. No. No.
I don't trust these anymore. Does it just see 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, because 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 if they're both AI generated, I find PStack writing to be a lot more readable, and also the behaviors from these skills to be a lot more applicable for my day to day. The arena one has been super fun.
Fan out end parallel attempts at the same task. Read every candidate end to end, pick the strongest as the base, graph 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, because we have a bunch of usage to get through.
Start with the do list with one entry per phase before launching anything. The arena runs autonomously, and the list keeps phases from silently disappearing. Frame, fan out, cross judge, pick, graft, verify.
Then descriptions of each phase. Surprisingly little text for how much this does. Like, this one scale has cost me hundreds of dollars of inference because it just does the same thing multiple times.
This write up is very much tied to cursor specifically, which is the biggest issue with PStack. I honestly would be pumped if somebody, like, cloned all the PStack 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, I believe it was originally Dylan Mulroy, the effect and functional programming JavaScript guy.
Restate your last message. Stop using jargon and speak coherently. State it more simply and concisely, like one human talking to another.
I think it was 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 thing. 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.
Compare us in your companion to how and why. How tells you what the code does, why tells you why it's shaped that way, blast radius tells you what it breaks somewhere else. I know 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 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 that 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 PStack versus Pocock skills. I didn't intend for it to be that at all, but I am 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 wanna 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, commit it when a 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 so that it's easy to, like, read and do in other things.
One row is one decision or checkpoint. If it doesn't fit one line, the decision isn't crisp yet. Append only.
A wrong call gets a new row that supersedes it. Refer evidence produced by committed scripts over handmade one offs so a reviewer can rerun it. Interesting.
This one seems really cool, actually. Gonna play with 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. 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 shit 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 should have Onslaught at this point.
This skill has fundamentally changed my willingness to read the things that my agents say to me. It's been great. God, this video could be hours long, or it could be a forty five 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 PStack, and tell it about Matt Pocock's skills, and ask it to look through them, and then look through your histories, and figure out what makes sense based on what you do.
Maybe you should install the unslop 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 like I do.
I think it's really powerful. You have 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 their clod files in like the dot clod and the dot agents directory on their machines.
That's silly, and you have to get over it. Because there is so much cool shit you can do the moments you start digging in and playing with these things.
You gotta 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 at 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 PRs with so little breakage over the last weekend. The way I work's 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 that 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 math 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, peace nerds.
The Hook
The bait, then the rug-pull.
Theo highlights the astonishing star count of markdown-based AI skills, pivoting quickly to why most community skill packs are low quality unless audited with precision.
Add Modern Creator as a preferred source and Google shows you more of our breakdowns in Search, Top Stories, and AI Overviews. It only changes what you see, and you can undo it in your Google settings anytime.
Add to Preferred SourcesOpens your Google source preferences with us pre-loaded. Tick the box and you're done.
Theo walks through Anthropic's own usage guide for Opus 5.5, line by line, and adds the real prompts and a six-and-a-half-hour mistake to prove which parts actually hold up.
Theo spends forty minutes inside Anthropic's own Fable 5.1 prompting guide, rebuilding his habits around effort levels, finishing the whole task, and trusting the model's defaults instead of babysitting them.
A developer who shipped 89 merged PRs in 24 hours breaks down Claude Fable 5.1's pricing, benchmarks and real-world coding behavior against Fable 5 and GPT-5.6 Sol.
Theo spends a week testing two rival "skills" repos for AI coding agents, Matt Pocock's 215,000-star collection and Cursor engineer Lauren's PStack, and finds the real value in a handful of specific files, not the whole install.
Six weeks, sixty-seven projects, and somewhere between $180,000 and $240,000 in inference spend on early access to a frontier coding model — before the official review even starts.
A developer who used to type 160 words a minute lost the use of one hand, and rebuilt his entire coding workflow around a whisper, a fleet of machines, and agents he no longer reviews before they merge.
00:02
01:11
01:40
02:09
03:06
03:35
05:02
05:30
06:28
06:57
07:25
07:54
08:23
08:52
09:20
09:49
10:18
11:15
11:44
12:13
12:42
13:10
13:39
14:37
15:06
15:34
16:03
16:32
17:01
17:29
18:27
18:56
19:24
19:53
20:22
20:51
21:19
21:48
22:46
23:14
23:43
24:12
24:41
25:10
25:38
26:36
27:05
27:33
28:02
28:31
29:00
29:28
29:57
30:26
30:55
31:11
31:52
32:21
33:18
33:47
34:16
34:45
35:14
35:42
36:11
36:40
37:37
38:06
28:41
41:32
55:06
38:21
26:09
38:21