Comparing Three Agent Skill Sets: How to Choose Between Pocock, Addy Osmani, and Cursor pstack

304K ⭐️ Skills For Real Engineers @mattpocockuk 111K ⭐️ Agent Skills @addyosmani Cursor official plugin pstack @poteto

How to choose among the three Agent Skill sets: fuzzy alignment, full workflow, or proving it actually runs?

In his latest video "Pocock vs Pstack vs Osmani: Which Skill Pack Wins?", @robshocks analyzed and compared these three Skill sets, and the conclusion is: there is no "one-size-fits-all champion." Pocock asks "are we even building the same thing"; Addy asks "did we go through the entire engineering lifecycle"; pstack asks "can you prove it actually works." Rob's core advice is: ceremony should match risk; don't install the full skill set on every project, because that floods the context and easily causes false triggers; the real goal is to learn the engineering habits behind them, then trim them into your own harness. https://t.co/ORRzr2dzs9

What is Addy's set about? Using Addy passing 110K stars as the lead-in: he condenses the classic SDLC into six stages for agents, Define → Plan → Build → Verify → Review → Ship (corresponding to commands like /spec, /plan, /build, /test, /review, /ship). There is also /build auto (after the plan is approved, it can do tasks continuously, but still tests/commits per task and stops on failure), /constraints, /webperf, /code-simplify; about 25 skills, multiple reviewer personas (senior engineering/testing/security/performance). Each skill commonly includes anti-rationalization (an excuse table), such as "too simple to need tests," "I tested it manually," with rebuttals written alongside.

He also emphasizes doubt-driven development: write important decisions as short claims → strip out your reasoning and leave only the code and goal → use a fresh context specifically to find flaws → reconcile and fix → stop after a limited number of rounds. The old principles tucked in: Hyrum's Law, the Beyoncé Rule (if you like it, you should write tests), Chesterton's Fence (understand before you tear down). Suitable for teams, production, and scenarios that need predictable quality gates; its lineage leans toward Software Engineering at Google.

Three-question comparison (Rob's framework) 1. Pocock Are we aligned on what to build? Used at: before coding (grill, terminology, decisions, spec, tickets) For: fuzzy requirements, long-lived codebases, wanting control

2. Addy Has the whole process been completed? Used at: full coverage before, during, and after For: teams, production, quality gates

3. pstack Can it be proven to work? Used at: leaning toward investigation and verification (deliberately little "planning religion") For: hard-to-reproduce bugs, migrations, overnight runs, multi-model adversarial testing

Pocock: small and composable, opposed to big frameworks; signature /grill-me (one question at a time). pstack: a Cursor plugin, with /poteto-mode as the main entry point, arena/swarm, using evidence rather than "the build is green." The three overlap, and there is no need to treat them as opposing sects; engineers often arrive at the same place by different paths.

Ceremony ladder (more important than "which pack to install") · Small change: just do it, take a look yourself · Small feature: short grill + test-first · Large/fuzzy feature: short spec + phases, acceptance between phases · Production/security/irreversible: full review, doubt, security hardening · Bypass: for stubborn problems, bring in pstack anytime; if the agent makes the same old mistake again → change the skill, stop piling on instructions

You don't need all of them The model is already strong; skills are more about how you like to work, not remedial lessons for the model. Installing too many takes up context and auto-triggers on work where it shouldn't; two "master routers" will also fight over names like /tdd. Rob suggests light/medium/heavy self-use configurations, borrowing individual skills from others, and not running two primary routers in parallel.