Matt Pocock's Skills vs Pstack: Claude Code Plan-to-PR Workflows

I'd been running Claude Code on real features for a while, and what kept bugging me wasn't the code it wrote but the decisions it quietly made for me along the way. So when people kept pointing me at Matt Pocock's skills, and then Pstack turned up as a plugin in Cursor's repo, I wondered which one really fixes that, or whether I'd be swapping one pile of prompts for another.

I went through both packs stage by stage, from the first interview to the merged pull request, and looked at where each one hands the call back to a person. After reading this, you'll be able to map your own feature workflow onto both packs, see where you sign off as the human, and pick which skills to install into your agent first.

One agent, a shelf of skills: why Claude Code skill packs beat a zoo of agents

Hand an agent a one-line task and it won't stop to ask. Every decision you left unstated gets filled with its own guess, and the work keeps moving.

Ask for a pause button on a subscription, and the agent will quietly decide how billing, edge cases and emails behave. Nobody asked you.

Both packs fix this the same way at the architecture level. Instead of spinning up a separate agent for every job, you give one agent a library of skills.

Think of a skill as a recipe card in a drawer. It's little more than a folder holding a single file, usually SKILL.md. The agent sees only each skill's name and description until a request matches, and only then loads the full instructions.

That lazy loading is why a big pack stays cheap. Sixteen of the twenty-seven skills in Pocock's plugin stay hidden until you type their name, and in his tutorial the entire installed set used about 660 tokens.

Pstack applies the same idea to rules. Its engineering principles live as separate skills with an index of when each should fire, rather than as one bloated system prompt.

Skills also follow an open standard, so a single skill folder works in Claude, Codex, Cursor and other agents. You can mix pieces from both packs without locking yourself into one tool.

Matt Pocock's skills and Pstack at a glance

Pocock's pack is built around getting decisions out of your head before any code exists. It walks a feature through an interview, a spec, sized tickets, a test-first build, fresh-eyes review and a retrospective.

Pstack comes from Lauren Tan, who open-sourced her workflows, skills and engineering principles as a plugin in Cursor's public plugins repo. Its planning skills mostly target brownfield projects, where a codebase already exists and you're changing it.

Where Pocock relies on one model and your answers, Pstack skills often bring in several models to design, attack and verify.

So which one fits? It depends on your project. If you mostly ship new features on a codebase you know well, Pocock's planning flow fits naturally. If you're running large migrations inside an unfamiliar existing system, Pstack's learn-the-code and multi-model steps earn their keep.

Planning: the grill me skill interviews you vs. learning the code first

Pocock's grill me skill flips the usual conversation. Before a single line is written, the agent puts you through a thorough interview about your plan.

You don't have to remember every decision up front, because the agent goes looking for them.

It works in rounds. The agent maps the feature into a branching set of decisions and picks out the open ones whose parent is already settled. That set is called the frontier (the edge of what's been decided so far).

All of it arrives as one numbered list, and every question comes with the agent's own suggested answer, so you can often reply in a few words. Then the next layer opens up.

Anything that can be found in the code is the agent's job, and it sends a helper agent to read it. Decisions belong to you.

Expect roughly six questions for a small change and about twenty for a typical feature.

Pstack starts from the other end. On an existing codebase, you first learn how things work before deciding anything. A how skill explains how the code works, and a why skill explains the reasons it was built that way.

Your sign-off comes later, once you understand the terrain.

Design and spec: one human-approved spec vs. an arena of models

In Pocock's flow, once the interview runs dry, the to spec step writes up everything you agreed on. The spec holds the problem, the fix and a numbered list of user stories.

It becomes the reference that both the build and the review check against.

The spec then gets cut into tickets sized for a fresh session. The rule of thumb is to estimate the tokens a job will need and divide by 150,000. A refactor of around a million tokens becomes seven tickets, each starting with a clean context.

Pstack handles design differently. Its architect skill settles the module shape and types before code is written, and its arena skill runs several parallel attempts at the same task and keeps the best parts of each.

In other words, your decision is made against a comparison rather than a single model's first idea.

For high-stakes architecture on a large system, that extra cost is worth it, because it buys you options. For a routine feature, Pocock's single interview is still the lighter option.

Build: test first, then strip the slop

Pocock's implement spec skill, new in version 1.3 (released October 4, 2026), builds a whole spec in one pass. Every ticket that is ready gets its own agent working in a separate repo copy, and all results land on a single branch.

Inside each ticket the order is strict. First comes a test that fails at the seam you agreed on, then only as much code as it takes to make it pass, then the next slice.

Every piece of code has a test that justifies it. That keeps the agent from wandering off into work nobody requested.

A cleanup pass on the resulting diff comes from deslop, which ships in a separate Cursor plugin, cursor-team-kit, rather than in Pstack. Here's the usual AI slop it hunts for and removes:

• comments that add nothing,
• try-catch blocks with no real purpose,
• variables without types,
• deeply nested logic.

Pocock's loop controls what gets written, and the deslop cleanup controls how the result reads.

If you adopt only one piece here, take the test-first loop, because it's what keeps each slice honest.

Review and testing: fresh eyes vs. models that try to break it

An agent that wrote some code tends to believe it's fine. So both packs hand review to someone else. Pocock uses fresh agents. Pstack uses fresh agents and different models.

The layers do different jobs. Spec review catches drift from what you agreed during planning. End-to-end verification catches problems that unit tests miss.

Diff attacks and premise checks catch the things nobody thought to ask about.

If you work solo, a sensible starting point is spec review on every feature, plus a multi-model diff attack before merging anything that touches money or data.

PR and after: babysitting the merge and running a retro

Once review passes, the pull request still has to land. Pstack includes a babysit playbook, run through its poteto-mode router, that drives a PR to merge-ready, handling conflicts, review threads and failing CI checks.

Pocock's final step is the retrospective. Before you clear the chat, you run retro. The agent rereads the session it just finished and proposes changes to its surroundings, meaning the repo, the checks and the instructions.

But Pocock pushes back on running retro on autopilot, because an agent acting on whatever it flagged itself tends to chase false positives. So this is another sign-off point. The agent suggests, and you pick the fixes worth keeping.

How fast can this go? On September 25, 2026, in one of Pocock's own projects, a spec with 41 user stories was split into 10 dependency-linked tickets within four minutes.

Everything landed on one branch, 28 commits and close to 14,000 lines, and the merge happened just over two hours after the spec existed.

Key terms

• Skill – A folder with a SKILL.md file whose name and description tell the agent when to use it and whose body says how to do the job.
• Progressive disclosure – Loading only skill names and descriptions until a request matches, then opening the full skill.
• Frontier – The set of open decisions whose parent decisions are already settled, asked together in one round.
• Brownfield project – A project that already has existing code, as opposed to building from scratch.
• Seam – An agreed place where tests probe the feature; ideally there is just one.
• Arena – A step that runs several parallel attempts at the same task and keeps the best parts of each.

Verdict: where you sign off and which skills to adopt

If you run one agent with a skill library, here's the set to start your Claude Code skills workflow with. Grow it as you go:

• Install grill me and run it on your next feature before any code
• Write the spec and size tickets by dividing estimated tokens by 150,000
• Build each ticket test first
• Send every diff to fresh-agent review against the spec
• Run retro before clearing the chat and keep only the fixes you agree with

Check yourself

1. You ask your agent in one sentence to add a pause feature. It works, but it made calls on billing timing you never discussed. What is the root cause?

• A. The tests were too weak
• B. The model is not capable enough
• C. The agent filled unstated decisions with guesses

2. Your team mostly evolves a large existing codebase. Which planning approach fits best?

• A. Writing one long prompt with every rule
• B. Learning the code first with how/why skills before planning
• C. Skipping planning, since the code already exists

3. During an interview the agent asks how billing is currently implemented. What should happen?

• A. Skip it and start coding
• B. The agent should look it up in the code itself
• C. You should answer from memory

4. A refactor will need roughly six hundred thousand tokens. How should you split it?

• A. One ticket per file
• B. One long session so the agent sees everything
• C. Into about four tickets, each starting in a fresh session

5. Why hand the diff to fresh agents or different models for review instead of the agent that wrote the code? (Select all that apply.)

• A. Different models can try to break the change from different angles
• B. The agent that wrote the code tends to believe it is fine
• C. Fresh agents always run a bigger model