Pocock vs Pstack vs Osmani: Which Skill Pack Wins?

Summary

Rob Shocks compares three AI-coding skill packs: Addy Osmani’s, Matt Pocock’s, and pstack, associated with Lauren Tan at Cursor. His main point is that they reflect different software-engineering priorities, so the best choice depends on the work—not on installing every skill everywhere.

Addy Osmani’s approach: Follow the full development lifecycle

Osmani’s pack organizes work into six stages, each associated with a slash command:

1. Define — Establish what is being built, including objectives, structure, coding style, tests, and boundaries, before implementation.
2. Plan — Break the work into small, atomic tasks with acceptance criteria.
3. Build — Implement one thin vertical slice at a time.
4. Verify — Test and check each slice rather than assuming implementation is correct.
5. Review — Examine the result for quality and potential issues.
6. Ship — Complete the delivery process, including practices such as CI/CD, observability, and deprecation.

Rob describes this as a conventional software-development lifecycle adapted for AI agents. He sees it as especially suitable for teams and enterprise settings because it provides a recognizable, end-to-end process.

Other features he highlights include:

• /build auto — After the plan is approved, the agent can execute tasks autonomously. It still tests and commits each task separately and stops if something fails.
• /constraints — Interviews the user about their quality standards and records them in a constraints file.
• /web-perf — Audits web performance.
• /code-simplify — Helps simplify working code that has become difficult to maintain.
• Reviewer personas — Staff engineer, test engineer, security auditor, and web-performance auditor.
• Anti-rationalization tables — Record common excuses an agent might use to skip good practices, alongside rebuttals. Examples include “this is too simple to test” and “I tested it manually.”

Rob also highlights doubt-driven development: for an important or non-trivial decision, a fresh review context is asked to challenge the claim. The process is to state the claim, extract its assumptions, doubt them, reconcile the findings, and stop. This introduces adversarial review during development, not only at the end.

The pack also incorporates familiar engineering principles, including testing, small commits, trunk-based development, and caution when changing existing code—illustrated by Chesterton’s fence: understand why something is there before removing it.

How the three packs differ

• Matt Pocock’s skills focus on clarifying what is being built and aligning the user and agent before coding. His “Grill Me” skill has the agent question the user, while shared terminology, decision records, specifications, and tickets help establish a common understanding. Rob characterizes Pocock’s skills as small and composable, with much of the effort placed up front.
• pstack focuses on proving that the result works. As Rob describes it, it emphasizes investigation, verification, and multimodal review rather than planning. He says it is useful for difficult bugs, migrations, agent swarms or “arenas,” and long-running tasks where the agent’s work needs careful checking.
• Osmani’s pack focuses on whether the whole development process was followed, from requirements through implementation and delivery. Rob describes it as offering the broadest lifecycle coverage and being particularly team-friendly and portable.

The approaches overlap, but Rob cautions against treating them as competing doctrines. He sees them as different perspectives on software engineering and says engineers often converge on similar practices.

Choosing an appropriate level of process

Rob recommends matching the process to the risk and complexity of the task:

• Small tweak: Make the change and check it yourself.
• Visual or prototype work: Iterate quickly, refresh, and inspect the result.
• Small feature: Use a brief discovery or “Grill Me” session to align on the request, then apply testing practices.
• Large or unclear feature: Write a specification, break it into phases, and verify each phase.
• Production-critical, security-sensitive, or irreversible work: Use more extensive review, doubt-driven checks, and security hardening.

He warns that installing every skill for every project can create unnecessary process, consume context, and cause skills to trigger when they are not needed. Even with Osmani’s pack, he recommends a gradual, verification-first rollout rather than enabling all the skills at once.

Broader lessons

• Skills are useful partly because they encode and communicate engineering practices—not necessarily because they teach an agent something entirely new.
• Useful practices include agreeing on requirements before coding, writing tests, working in small increments, recording why decisions were made, and checking behavior in the actual application rather than relying only on a green test result.
• Skill packs can be read and adapted like reference books. Teams should take what works and shape it into their own standards.
• When an agent makes a mistake, update the skill or workflow with what was learned instead of simply adding more instructions indiscriminately.
• The aim is to build a lightweight, team-specific “harness” that reflects the team’s quality bar.

Speakers and sources featured

• Rob Shocks — Video narrator and reviewer.
• Addy Osmani — Discussed as the author of the agent-skills pack.
• Matt Pocock — Discussed as the author of the skills pack that includes “Grill Me.”
• Lauren Tan — Discussed in connection with Cursor’s pstack.
• Neon — Sponsor mentioned in an advertisement about branching databases and related development resources.