Transcript: Pocock vs Pstack vs Osmani: Which Skill Pack Wins?

Source video ID: sU9MW8Ycq2M

Transcript

• 0:00 — So, Addy’s money, he’s probably one of the most respected engineers at Google for well over a decade, and he’s recently just moved to Anthropic, the maker of Claude code. And he’s just gone and open-sourced all his agent skills. So, 100,000 stars later, it’s probably one of the most popular AI repos on GitHub right now. So, if you’ve been following the channel at all, you’ll know I’ve already broken down P Stack from Loren Tan at Cursor, and then also Matt Pocock’s skills. So, Addy is the third of the big three. Now that we’ve got all three, you can see that they’re solving different problems.
• 0:31 — By the end of this video, you’ll know what Addy’s doing, when to reach for each pack, and why I think you don’t need to run all of these across all of your projects. They can be a bit of overkill sometimes. I’m Rob, this is Switch to Mention, and let’s start with how Addy thinks about his skill set. So, quick context, if you don’t know who Addy is, he’s a bit of a legend in the JavaScript world. He wrote Learning JavaScript Design Patterns, he led the Chrome developer experience and web performance work at Google. If you’ve ever run Lighthouse or read about Core Web Vitals, you’ve probably been affected by his work at some stage. So,
• 1:02 — I think that’s really relevant because when somebody like Addy writes down, “This is how you want an agent to engineer software,” you want to pay attention. What you’re really getting is a seasoned engineer’s brain compressed into markdown. And that’s what I love about skills. Before we read tons of O’Reilly books on best practices, now we’re basically studying and examining skills from the top performers. So, here’s the big idea. Addy’s approach is a life cycle, six stages: define, plan, build, verify, review, ship. And each
• 1:32 — stage has a slash command to go with it. If you’ve been watching my videos for the last 2 years, or you’ve done any kind of spec-driven development with B Mad or Superpowers, this will feel very familiar. And that’s kind of the point. Matt’s skills have their own vocabulary, grilling and wayfinder and fog of war. P Stack has potato mode and arenas. Addy’s is the most traditional to the software development life cycle. You don’t have to learn a metaphor, it’s the software development life cycle done properly with an agent. So, I think of all the stacks this can fit in very well with an
• 2:02 — existing development team or in the enterprise. So, spec writes a proper PRD covering objectives, structure, code style, testing, and boundaries before a line of code. Plan breaks that into small atomic tasks with acceptance criteria, and build implements one thin vertical slice at a time. You implement it, you test it, you verify, you commit it, then you test review and ship. So, there’s one mode that I really like, it’s called slash build auto. So, you approve the plan once and then it runs every task autonomously after that. It
• 2:33 — removes you kind of having to step in between tasks, but it doesn’t remove the verification, which is important for you to look at. So, every task is still test driven, and it’s committed on its own, and then it stops if something fails. So, I think that’s kind of like the right way to do autonomy. So, slash constraints basically is another style of interview just to test out what your quality level or quality bar is, and then it writes this to a constraints.md file. Then there is a slash web perf for web performance. It does a performance audit, which you know, given who wrote
• 3:04 — this, Addy Osmany, the the king of web performance, you’d hope this is going to be good. And then slash code simplify is for when the code works, but nobody really wants to touch it, and you want to simplify or break it down. There’s a lot of overlap between what Lauren talks about and also what Matt Pocock talks about in terms of similar skills. So, there’s 25 skills in total plus four reviewer personas. There’s a staff engineer, a test engineer, a security auditor, and a web performance auditor. Okay, so let’s look inside the skills. As always on this channel, the slash
• 3:35 — commands aren’t the interesting part. The skill files are. Here’s where we really get inside a software engineer’s brain. So, every skill has what Addy would call a anti-rationalization table. It’s a list of the excuses an agent will make to skip past a step. We see agents doing this all the time. And then you’ve got the rebuttal to why it would skip right next to it. So, it’ll test for things and reasoning traces like this is too simple to test or I tested it manually. So, if you’ve worked with agents or you’ve worked with juniors, you’ve heard all of these excuses
• 4:05 — before. And writing the excuses down in advance is really a smart move. Here’s a quick tip on working with multiple agents, thanks to our friends over at Neon. When you’re developing new code with agents, you’re going to want to have multiple different feature branches just to be sure that you don’t impact the main production branch. Unfortunately, it gets a bit more complicated than that. We have the main branch, but we also need a database branch and maybe even some storage. Otherwise, what you get is a preview branch, maybe it’s got a copy of Postgres and that’s okay, but then it might end up uploading the file to the
• 4:35 — wrong storage. And we end up with a production break. I’ve been using Neon for years for my database needs just because of their superior branching and a whole lot of other reasons. But what you might not have noticed is now they’re a full platform, database, storage, functions, auth, and AI gateway. Why is that a beautiful thing, you might ask? So, your agent using the CLI can now create a branch of everything it needs to be safe. That includes your database, your functions, your buckets, your auth user, anything that you need. Each agent gets its own copy instantly. Rob Shox viewers can
• 5:07 — sign up to Neon for free via the link in the description down below. So, this one is really interesting. It’s called [snorts] doubt-driven development. We’ve heard of domain-driven development, this is doubt-driven development. So, for any non-trivial decision or important decision, it spins up a fresh context review and the one job is to doubt the claim. So, claim, extract, doubt, reconcile, stop. It’s basically adversary review during the build, not just at the end. As you start to read through the rest of the skills, you start spotting some old friends and
• 5:38 — paradigms. Hiram’s law in the API design skill, so every observable behavior of your API will eventually be depended on by somebody. And then the Beyonce rule in the testing skill, if you like that you should put a test on it. I’m not going to sing this. And Chesterton’s fence in code simplification, don’t delete the fence until you know why it’s there. Trunk based development, small atomic commits, code as a liability. So, that’s basically Audia Imani’s software engineering brain turned into agent
• 6:08 — instructions. Honestly, if you never install this, just reading through the skills is a better software engineering course than most. So, how does this compare to the other two? So, Matt Pocock’s skills basically are asking, do we agree on what we’re building? So, do you and the agent agree? You’re setting up the domain. His most popular skill would be grill me, and that’s basically where the agent interrogates you before it writes anything. Then there’s the idea of a shared language glossary, which would be ADORs, which are decision records, and then you’ve got specs and
• 6:38 — tickets. Matt still falls in with the traditional SDLC, it’s just he is approaching it in a different way. A lot of his skills put the effort up front before you actually begin to code. And he’s openly said he’s anti-framework. He thinks things like BDD, Spec It, Superpowers take away your control. So, his skills are deliberately small, they’re composable, and you can use them where you need to and hack them yourself. My interpretation of Lauren Tan’s peace talk is really about can you prove it
• 7:09 — works. Lauren deliberately has no planning skills. Her line is the best spec is the code. All the weight really is on the investigation, the verification, and multimodal review after the fact. The build passed doesn’t count as evidence. We need to prove that out. Adi’s skills then are more around did we follow the whole process. He’s the only one of the three that really covers the full SDLC life cycle right through to continuous integration and deployment, observability, uh deprecation, and shipping. It’s probably
• 7:39 — the most team friendly and the most portable since it installs into something like 70 different agents. What I’ve ended up with personally is a mix of all of these together and I don’t use them all at the same time. I’ll use different skills at different points. I’ve got light, medium, and heavy versions of my skill runtime. So, reach for Pok Arc when the problem is fuzzy, when you’re not sure what you want, or you’re working on a code base you live with for years and you really care about the design. Grill me is still the single best skill I’d install first to do that.
• 8:10 — I’d reach for when you’re on a team shipping to production and you want a predictable process everyone recognize, or when you want all the quality gates without designing them yourself. My own skill set falls more in this kind of a process because I’m working with teams of developers and teaching them how to apply agents. Then I’d reach for P Stack when it gets really gnarly. It’s a bug you can’t reproduce. You’re looking to apply swarms and arenas against a problem. There’s a migration. You’ve got long-running agents. Maybe it’s an
• 8:40 — overnight run and you need to trust them when you wake up. And of course, if you’re running Cursor and you’ve got several models because her skills work really well as a plugin with Cursor. And you’ll also notice that there’s huge overlap and they borrow from each other constantly. It’s not that they’re actually borrowing from each other. It’s just that software engineers converge on how to build software all together at the same time. So, there is going to be a lot of overlap. And again, software engineering is opinionated. You just pick the best opinion and apply it to your own workflow. They’re basically just three angles here all on the same
• 9:11 — craft. So, my actual opinion on all of this, you really don’t need all of these skills on every single project. That is a massive overkill. Agents are getting super smart now and one of the best things you can do is actually run through your agents.md file or your existing skills and actually start to pair them back and prune them because you’ll be surprised at how powerful the models are. I’m thinking that skills now are more about this is how I like to work as opposed to necessarily teaching the agent anything new. In fact, having
• 9:41 — really long skill files and an excess of skills is just going to bloat and confuse your context window. So, if you’re just changing a button color, you don’t need a PRD, a task breakdown, a five-axis arena review from P stack, or a security auditor. You just need to change the button and look at it. So, the way I think about it is effort level. Ceremony should match the stakes of what you’re working on. So, a small tweak, just do it and then check it yourself. If it’s very visual or prototype-based, just do it yourself, check it quickly, refresh, and move on.
• 10:12 — You’re iterating with the agent. If it’s a small feature, a quick uh grill me or discovery session so that you’re aligned, and then some test-driven development. If it’s a big or fuzzy feature you’re trying to figure out, then a spec and a plan broken down into phases, and then you verify each one in between. If it’s production, uh there’s security involved, or anything irreversible, that’s when you bring out the full review, doubt-driven development, and then all the security hardening that comes with it. So, even Adi says this about his own skills. His adoption guide to them is a
• 10:43 — gradual verification-first rollout on an existing codebase. Don’t install 25 skills and try to run everything. That’s complete overload. And there is a practical cost here, too. Every skill you install is something the agent has to consider. And then you might end up auto-triggering these skills by accident when you don’t want them. More skills doesn’t necessarily mean a smarter agent. So, I guess the real lesson here is, and I’ve kind of been saying this for a while, learning these skills is really learning good software development practice. Test-driven development, small vertical slices,
• 11:15 — agreeing on requirements before you build, writing down why you made a decision. You’re not deleting the fence until you know why it’s there. Don’t go deleting anything until you know specifically why it’s there. And then proving it works against the real thing. If you just see green light test, that doesn’t mean your app works. You need to actually test it properly. And none of this is new. It’s not like any of these guys invented this. Matt Pocock credits the pragmatic programmer and domain-driven design. Andy is basically Google’s engineering book. Lauren has years of React and meta experience. The
• 11:45 — skill there is just those ideas in a format that an agent can follow. So, don’t treat any of these packs as a religion. Treat them as kind of like an O’Reilly textbook. You can install them, read them. You steal what works and then build your own skills on top of them. And that’s basically encoding how you work. You’re sharing the best of that with your team and they share back. It’s your stack and it’s your own quality bar. This is basically your own team or your own personal harness. And that’s going to be bespoke to you and help you move a whole lot faster. And every time
• 12:16 — your agent screws something up, don’t be a child. Don’t swear at it. Just go and update your skill based on new learnings. That’s exactly how all of these three packs were built. So, if you want to go deeper on building your own skills library and agent workflows, that’s exactly what we do with Switch to mention the course and community. The link is in the description below and you can get on the wait list. So, I’d love to know in the comments which skill packs are you running right now? Have you written skill sets of your own? Feel Feel free to share them in the comments. I’d love to know what people are actually building and using in production. If this is useful, subscribe
• 12:46 — because this is a series. If you missed them, the P stack breakdown and Matt Pocock video are on the screen right now. You should watch those next.