Three AI Coding Agent Skill Packs Compared: Addy, Pocock, and P-Stack Selection Guide

In the age of AI coding agents, "Skills" are emerging as a new way for developers to improve code quality. Addy Osmani — former principal engineer at Google and now at Anthropic (the company behind Claude Code) — recently open-sourced his complete set of agent skills. The repo hit 100,000 stars shortly after launch, becoming one of the most popular AI repositories on GitHub.

YouTube and Bilibili creator Rob Shocks (Switch Dimension) had previously covered both Cursor engineer Lauren Tan's P-Stack and Matt Pocock's skill pack in separate videos. With Addy's release, the "big three" skill packs are finally all on the table. This article draws from Rob's comparison video to break down what each pack solves and how to choose the right one for your needs.

Addy Osmani: Handing the Software Engineering Lifecycle to Your Agent

Addy Osmani is a legend in the front-end world — he wrote Learning JavaScript Design Patterns, led Chrome developer experience, and drove Web performance work. If you've ever used Lighthouse^Ad or heard of Core Web Vitals, his influence is all over it. That's precisely why, when an engineer of his caliber puts "how agents should do software engineering" into Markdown, it's worth paying attention.

Addy's methodology is essentially a lifecycle: Design, Plan, Build, Verify, Review, and Ship — six phases, each mapped to a slash command. Compared to Matt's "Grilling/Wayfinder" or P-Stack's "Potato Mode/Arenas," Addy's approach hews closest to the traditional Software Development Life Cycle (SDLC). There are no invented metaphors to learn, which makes it the easiest to integrate into existing teams and enterprise environments.

In practice, spec generates a full PRD before a single line of code is written, covering goals, structure, code style, testing, and edge cases. plan breaks that into atomic tasks with acceptance criteria. build then implements one thin vertical slice at a time — implement, test, verify, commit, repeat. The full pack includes 25 skills and four reviewer personas: senior engineer, test engineer, security auditor, and web performance auditor.

One pattern worth highlighting is build auto: you approve the plan once, and subsequent tasks run automatically — but the verification step is never skipped. Each task still goes through test-driven development and gets its own commit; a failure halts the process. Rob calls this "autonomy done right."

The Software Development Life Cycle (SDLC) is a classic software engineering framework describing the complete process from requirements analysis, design, and coding through testing, deployment, and maintenance. Its value lies in giving teams a shared language and predictable quality gates — each phase has clearly defined inputs, outputs, and acceptance criteria. Mapping SDLC to an AI agent's workflow means the agent is no longer a single-step tool that takes one prompt and spits out code. Instead, it's embedded in a constrained, auditable engineering pipeline. This matters especially in enterprise settings: team members don't need to understand the agent's internals — they just follow familiar phase boundaries and can plug AI-generated artifacts into existing code review, CI/CD, and compliance processes.

The Engineering Wisdom Inside the Skill Files

Rob emphasizes that the slash commands themselves aren't the point — the skill files are. That's where an engineer's thinking is made concrete.

Each of Addy's skills includes an "anti-rationalisation table": a pre-emptive list of excuses an agent (or a junior engineer) might use to skip a step — things like "this is too simple to need a test" or "I already tested it manually" — with rebuttals written right alongside them. Anyone who's worked with agents or junior devs will recognize those excuses immediately. Writing them down in advance is genuinely clever.

The skills also reference some familiar names from engineering lore: Hyrum's Law in API design (any observable behavior of an API will be depended upon by someone), the Beyoncé Rule in testing (if you liked it, you should've put a test on it), and Chesterton's Fence in code deletion (don't remove the fence until you understand why it was put there).

One genuinely novel concept is "Doubt Driven Development": for any non-trivial decision, the system opens a fresh context review whose sole job is to challenge the claim — claim, extract, doubt, reconcile, stop. This effectively introduces adversarial review during the build process rather than only at the end. As Rob puts it, even if you never install these skills, simply reading through the skill files is worth more than most software engineering courses.

Hyrum's Law was formulated by Google engineer Hyrum Wright. The full statement: "With a sufficient number of users of an API, it does not matter what you promise in the contract — all observable behaviors of your system will be depended on by somebody." The law warns engineers that even undocumented behaviors may already have dependents, meaning any change can break downstream systems you never knew existed. Chesterton's Fence comes from the intersection of engineering and philosophy: don't remove something until you understand why it exists. This is especially critical for AI agents, which tend to delete seemingly redundant code or configuration during refactoring — code that may exist to handle a historical edge case. Encoding these principles explicitly into skill files is essentially turning an organization's engineering memory into constraints the agent can actually enforce.

Three Skill Packs, Three Different Questions

Each author is answering a different core question — and that's the key to choosing between them.

Matt Pocock's pack asks: "Do we actually agree on what we're building?" His focus is pre-coding alignment. His most well-known skill, grill me, has the agent interrogate you thoroughly before touching the keyboard, supported by ADRs (Architecture Decision Records) and a glossary. Matt has publicly stated he's anti-framework, arguing that systems like BMAD, Spec-Kit, and Superpowers strip developers of control. His skills are intentionally small, composable, and designed to be hacked.

Lauren Tan's P-Stack asks: "Can you prove it actually works?" She deliberately includes no planning skills. Her philosophy is that "the best spec is the code itself." All the weight is on post-hoc investigation, verification, and multimodal review — a passing build isn't evidence; you have to actually prove it works.

Addy's pack asks: "Did we actually complete the whole process?" It's the only one of the three to cover the full SDLC, extending all the way to CI/CD, observability, deprecation, and shipping. This makes it the most suitable for team collaboration and the most portable — it reportedly works with around 70 different agents.

Rob also notes significant overlap across all three packs — not because anyone copied anyone else, but because software engineers naturally converge on the same answers to "how do you build software well." Software engineering is opinionated by nature. You just need to pick the best opinions and apply them to your workflow.

Selection Guide: Don't Blindly Install Everything

Rob's own approach is to mix all three packs, but never run them all simultaneously. Instead, he works in three tiers — light, medium, and heavy:

• When the problem is fuzzy, you're unsure what you want, or you're working on a long-term core codebase: reach for Matt Pocock. grill me remains his top recommended first install.
• When collaborating with a team, needing a predictable process everyone can follow, or wanting ready-made quality gates: reach for Addy.
• When dealing with hard-to-reproduce bugs, needing swarm/arena tactics, data migrations, or long-running trusted tasks (like overnight jobs): reach for P-Stack. It performs best as a Cursor plugin working with multiple models.

Rob's core principle: ritual should match risk level. Changing a button color doesn't need a PRD, task decomposition, a five-axis arena review, or a security audit — just change it and look at it yourself. A small feature warrants grill me plus test-driven development. A large, ambiguous feature needs a spec and a phased plan. Only production, security, or irreversible operations call for full review, Doubt Driven Development, and security hardening.

Even Addy himself recommends an incremental, verification-first onboarding strategy — don't try to run all 25 skills at once. There are real costs: every installed skill is something the agent has to account for. Too many skills can trigger false activations and introduce context bloat and confusion. More skills does not equal a smarter agent.

Context bloat is a concrete limitation in real-world LLM engineering. Every AI agent relies on a finite context window that holds conversation history, loaded skill files, code snippets, and system instructions. When too many skills are loaded, the agent must process large amounts of instructions irrelevant to the current task before every response — consuming token budget and potentially causing the model to become ambiguous or mis-trigger rules. For example, a skill intended for security auditing might accidentally activate during a routine style change. This is why both Rob and Addy recommend activating skills on demand rather than installing everything at once: a leaner context keeps the agent focused, reduces noise, and often outperforms a context stuffed with rules.

What Skills Really Are: Good Engineering Practice in Executable Form

At their core, these skills are really just solid software engineering practices — test-driven development, thin vertical slices, aligning on requirements before building, writing down decision rationale, not removing the fence before understanding why it's there, and actually proving your code works against reality (green tests don't mean the app works).

None of this is new: Matt draws from The Pragmatic Programmer and Domain-Driven Design; Addy's approach is essentially Google's engineering standards; Lauren's comes from years of React and Meta experience. Skills are just a way to encode these ideas into a format agents can act on.

So don't treat any of these packs as doctrine — treat them like an O'Reilly book. Install them, read through them, take what's useful, and build your own skills on top. As models keep getting stronger, Rob believes skills are increasingly about expressing "this is how I like to work" rather than actually teaching agents something new. He encourages developers to regularly review and trim their agents.md and installed skills — you might be surprised how capable the model already is on its own.

When an agent makes a mistake, don't get frustrated with it — update your skills based on what you've learned. That's exactly how all three of these packs were built, and it's how you build a working style that's genuinely yours.