Cursor pstack review: 51 skills with a built-in manager, and the 5 pieces we took

Every week a new skill pack takes off in the feed, shared with a one-line install command, and the first reaction is always the same: let's install the whole thing. pstack is one of those, a Cursor plugin by Lauren Tan (known online as poteto), released under MIT, with 51 skills. After the README you want all of them.

Once we read every file inside, our question changed from "is it good?" (in the parts we read and tried, yes) to "where would it sit in the way we already work?" pstack isn't just a toolbox. It comes with its own manager. If you already have a way of working, installing the whole pack is like hiring an entire new team, manager included, into a department that already has a manager.

We are Productize, the blog you are reading. We use Claude Code and AI agents for real work every day, and we already have our own way of running work: each task goes through plan, implement, and review, each step on a set model, and a person approves before code is merged. Productize read all 51 skills in Cursor's pstack and took 5. Your setup won't match ours, but the way we chose should carry over to anyone who already has a way of working.

Part 1What is pstack, and how is it different from mattpocock and 9arm?

Inside, pstack is Lauren Tan's whole way of working, packed into skills. Of the 51 in version 0.15.15, the one we read, 24 are principle- rules, one idea each, such as "fix the root cause, not the symptom". The other 27 do actual work: explain code, find what a change could break, keep a decision log. At the center is poteto-mode, the orchestrator. It matches a task to one of 23 playbooks (bug fix, feature, opening a PR, an overnight run, and so on), then has the main chat hand the work out to subagents. Those playbooks are recipe files inside poteto-mode, not separate skills.

"The model can call it" means the AI loads a skill by itself when your request fits; "slash-only" means you have to type /skill-name. mattpocock and 9arm hand you tools. pstack hands you the tools and the decision-maker.

Part 2The 4 questions we used to choose

Before going through the skills one by one, we set 4 questions. A piece had to pass nearly all of them to make the cut.

1. Will it take over decisions we already make? If something already decides which work goes where, who reviews, and who merges, a piece that decides the same things will collide with it.
2. Does it run code, and is there a rule that says what its result means? More below.
3. Does it fill a gap you really have? Two things doing the same job slowly drift apart.
4. Is it worth porting to your tools? pstack was written for Cursor.

Question 2 has two halves. A rule written as text, with nothing that runs behind it, only works if the AI remembers it at the moment it matters, and over time a rule like that decays into "hope it remembers". Code that runs checks every time it's called, but all it hands you is a signal. For example, watch-pr says a PR is READY, meaning ready to merge. What "ready" covers is a separate rule, and Part 6 shows what it covered for us.

In pstack, the strongest-sounding promises, such as "nothing merges without a clean verdict from the reviewers", aren't enforced by any code: they are instructions, and the main chat is trusted to follow them every time. Only a handful of pieces in the whole plugin are real code you can run: watch-pr, log.sh inside show-me-your-work, orch, check-plan.mjs, and worktree-audit.sh. Of those, only two work without the orchestrator. watch-pr is a command-line program that watches a PR through gh (GitHub's command-line tool), and log.sh is the script that writes the decision log for show-me-your-work. The other three are parts of the orchestrator. Pulled out on their own, they have nothing to do.

Those two are the ones we took: watch-pr, and show-me-your-work, which carries log.sh. The other 3 of our picks are prose we re-scoped. The lesson: take the code and the rule that reads its result; if that rule stayed behind in pstack, bring it or write your own. When you take prose, narrow its trigger so it can't steal work from what you already have. Part 5 shows how we narrowed it.

Part 3The 5 pieces we took, and where they sit in the SDLC

1 · Understand code: code-how and code-why

Before you touch unfamiliar code, code-how explains how that part works: where it starts, what the data passes through, which files matter. code-why digs through commits, PRs, tickets, and docs for why the code ended up this shape.

Our first real task was small: in our own lab repo, add a test proving that a spec parser (a program that turns a spec file written in markdown into data) gives the same result every time. Before writing it, we had code-how walk the parse path. It showed which whitespace the parser already ignores, so the test could vary it on purpose, and that nothing inside reads the clock, a random number, or a cache, so a second run has no reason to differ. The test came from that reading, not from guesswork.

2 · Before changing: blast-radius

Once you've picked a fix, blast-radius asks what else could break. Its core move is to find the one fact that makes the change safe, then prove it by running real code. It asks you to say how far up a 5-step ladder the proof got:

1. You asserted it.
2. You pointed to the file and line.
3. You showed the bad case can't reach the changed code.
4. You ran a test that calls the code you're shipping and fails loudly if the fact is false.
5. You reproduced it in the running app.

The usual target is step 4: little effort, and the evidence can be rerun. blast-radius has no code of its own, but the target it sets is running code, so it leans on the AI's memory less than an ordinary rule does.

3 · After opening a PR: watch-pr

Our PR skill stops once the PR is open. After that, someone has to watch CI (the system that runs tests automatically), pending reviews, and whether it can merge. watch-pr does that with a real program: it polls through gh and returns a verdict, without merging anything itself.

4 · Unattended runs: show-me-your-work

When an AI works while you're away, you see the result but not why it took each turn. show-me-your-work has it write every decision as a row: what, why, the evidence, the result. Rows can only be appended. Before handing back, a model from another family reads the log (for us, OpenAI's Codex reads Claude's work), because self-review doesn't count.

Part 4Verdict table: what we took, what we skipped

This table runs the 4 questions from Part 2 across the main groups in pstack, not all 51. Each reason in the "Why" column comes from the piece itself; check it in the repo. The 5 pieces we took share one reason: each finishes inside one stage, so it can't take over decisions we already make (question 1). 4 of the 5 are skills from the 51. The fifth, watch-pr, is not a skill of its own: it is a script inside poteto-mode, the orchestrator we otherwise skipped, and we wrapped it in a SKILL.md we wrote.

Nearly everything we skipped wants several stages at once, or is tied too tightly to Cursor.

What do the pieces we took lose without pstack's orchestrator? watch-pr's script decides READY (the verdict that a PR can be merged) from the PR's checks and review threads, so what READY covers depends on the checks your repo runs. pstack's PR playbook is what decides what to do once READY comes back, and we did not take the playbook. The 24 principle-* skills, the rules the orchestrator reads before every task, stayed behind too. So we wrote our own: show-me-your-work logs a check as unproven until it has been seen to fail (Part 5, step 6), and merging stays with a person, because Part 6 shows what READY really meant.

Part 5Can you use pstack with Claude Code?

Yes, but port it one skill at a time rather than installing the plugin. (On Cursor, /add-plugin pstack installs it directly.) pstack's SKILL.md files already use Claude Code's format; what changes is the body and two fields in the frontmatter (the header at the top of the file), name and disable-model-invocation, and each skill needs something different. For our 5: how and why were renamed to code-how and code-why so they don't steal other skills' triggers, code-how's subagent calls moved to Claude Code's Agent tool, from poteto-mode we took only the watch-pr script (it needs bun), and show-me-your-work lost its Cursor transcript paths and can now be called by automation.

A good shortcut is backnotprop/pstack, a copy of the same upstream that differs in 26 files. It adds a Harness section mapping names per tool: Cursor's subagent tool Task becomes Agent in Claude Code or spawn_agent in Codex, and its question tool AskQuestion becomes AskUserQuestion. Some Cursor ties remain, such as hardcoded model names and cloud-run parameters. Its scripts passed for us: bun test orch watch-pr gave 52 pass, 0 fail.

To port one yourself, follow these steps. We read version 0.15.15 and upstream is now 0.15.21, so check what changed first. Not every skill needs every step.

Part 6What real use showed that the README doesn't

An honest note first: the evidence is thin. Four pieces got one real run each, on the parser test from Part 3. code-why got none, and we ran none of pstack's orchestration playbooks. Each heading sets a README promise next to what happened.

blast-radius. README says: prove the one fact that makes the change safe, by running code

The change only added tests, so it couldn't break the parser. The fact that mattered was somewhere else: does the repo's real test runner pick up the new tests? The repo runs npm test on Node 22, and that runner fails if any test is skipped. Running it gave 1,652 pass, 0 fail, 0 skipped, and our new tests were among them (tests 1424 to 1426 in its output). The near miss: until then we had only run one file with node --test on Node 20, which is not what the repo runs. Had we stopped there, we would not have known the real runner picks the new tests up. A test the real runner never runs protects nothing.

Our added rule: a check you've never seen fail

To prove the whitespace test could fail, we planted a bug on purpose to make it fail: delete the line that trims spaces from a value, and the test should go red. It stayed green. That green could mean the test catches nothing, or that the planted bug broke nothing. It was the second: the parser trims in three separate places, and any one of them keeps the result clean. We redesigned the planted bug to remove all three, the intended test went red, and we put the file back. A check you've never seen fail may be a check that can't.

watch-pr. README: "drive a pr or a stack to merge-ready"

watch-pr's script answers READY when the PR's checks pass and no review thread is left open; in this repo those checks are CI and a review check. Ours came back all green seconds after we opened the PR. That looked too fast, so we checked what each green measured. The repo's "reviewed" check only asks for a reviewer's note when a file touches a risky area, and our diff touched none. READY was true, but it meant "no review was required", not "someone reviewed it". Merging stayed with a person.

show-me-your-work. README: "logs decisions to a tsv you can commit"

A tsv is a plain table file, one row per decision. The log is only as good as whoever reads it. Codex read ours along with the commit and found a weak new test. It claimed to check that the parser keeps a field's list of choices, but the text it looked for also appeared inside another check, so it would still pass if the choices broke. We changed it to compare the whole parsed list, saw it fail on purpose first, then pass. This is separate from the planted bug above, which was ours, to test whether a test can fail. The weakness we have to admit: rows were written in batches after the work, so the timestamps cluster. The order is right; the timing isn't.

Part 7How to choose for your own workflow

If you use Cursor and don't have a systematic way of working yet, trying all of pstack may be worth it, because that's how it was designed (we haven't tried that path). But if you already have a way of working, even just steps you do by habit, take the tools, not the manager.

However big a skill pack is, you can take just the pieces your work needs. In pstack we found 5; yours may be others. Thanks to Lauren Tan for making them free to take.