pstack: run your agents like a Michelin kitchen

Watch it run

Rob Shocks installs pstack, builds a small app with it, and compares the result to plain Fable 5.1 with no skills. 13 minutes. A good first look before you read the articles.

0:00 Intro and setup
1:33 The skills: poteto-mode, arena, swarm, why
4:10 Sponsor (OpenRouter), skip to 5:20
5:20 His favorites: recall, interrogate, verification, unslop, bro
7:49 What one run did, read from show-me-your-work
9:12 The principles that matter most
11:53 pstack vs no pstack

Twice as long, much sturdier

Same app. Fable 5.1 with no skills and no plan mode: about 30 minutes. With pstack: about an hour, and a much more robust app.

It caught itself

The verification pass found three things the agent had made up, and fixed them before calling it done.

Tokens add up

Arena, swarm and interrogate run several models at once. Worth it for important work; overkill for small UI tweaks.

Read this first

Three articles and a talk, all on her X. This page pulls them together. In order:

Who she is: she has worked at Meta, Netflix and Cursor, is on the React core team (React Compiler), and now works on Grok Bot at SpaceX AI. pstack is open source (MIT) and is what she uses every day.

Words on this page

15 terms, in plain words. Skip this if you already run coding agents.

Cursor: The AI code editor pstack is built for. The install, Custom Modes and cloud agents on this page are Cursor features.
Grok Bot: The bot product she works on at SpaceX AI. pstack installs there as a plugin, and its routines can start agent work on their own.
Skill: A saved set of instructions an agent loads when needed, called with a slash command like /how or /reflect. Each pstack skill is a plain SKILL.md file.
Playbook: A step-by-step recipe for one kind of job, like a bug fix or a feature. You don't call them yourself; /poteto-mode picks the one that fits your task.
Subagent: A helper agent that a main agent starts to handle part of the job, so several pieces get worked on at once.
Worktree: A second copy of your code on your own computer, so one agent can work without touching another's changes. She dropped them because they fill your disk and top out around 10 agents.
PR (pull request): A proposed change to the code, sent for review before it joins the main version. A stack is a chain of small PRs that land in order.
Diff: The exact lines a change adds and removes. Her order: read the proof first, then the diff.
CI: Checks that run automatically on every PR, like tests and builds. When CI flakes, a check fails for reasons that have nothing to do with the change.
CLI: A tool you use by typing commands instead of clicking. The verification skill includes one so agents drive your app the same way every time.
Lint rule: An automatic check that reads code without running it and flags a pattern you've banned. On her correction ladder it sits just below changing the codebase itself.
Slop: Work that looks finished but isn't good. Her word for what you get when many agents run with no way to check their own work.
Formal verification: Checking code with math instead of examples. A model checker like TLA+ tries every possible order of events, so it finds race bugs that tests miss. Slow to set up; worth it only for the riskiest code.
Claude Code, T3 Code: Other coding-agent apps. pstack now installs in Claude Code too, and t3-pstack is a port for T3 Code.
Token: The unit AI models count and bill in. Skills that run several models at once, like arena and swarm, use a lot more of them.

The kitchen

Every part of pstack has a place in her kitchen. Click a station, or follow one ticket from the door to the dining room.

Service · one ticket, left to right

the pass has the darker border

Behind the line · what keeps the kitchen good

Service · station 1 of 6

Source: Pt. 2

Tickets = Your prompt

In a kitchen

An order comes in. It can be clear, or it can be a scribble.

In pstack

A task you type, or a Slack thread with a blurry screenshot and three question marks. Say the goal and how you'll know it's done, in your own words. Don't name playbooks. If the ask is fuzzy, make the agent restate it before it cooks anything.

You use

/poteto-mode <what you want>. <how you'll know it's done>
restate in your own words what you think my goals are and what the problem i'm trying to solve is

“Instead of telling the agent exactly what I want, I try to draw it out of the agent instead.”

Why a kitchen and not a factory: “we're not mass producing a product on an assembly line.” Building software is creative work. Agents cook the parts, but the dish is still yours.

The trust curve

She started out babysitting 1 to 5 agents, correcting every chat, and calls it the hardest stage to get out of. Spawn 100 before you trust them and you get “a ton of slop pull requests.” Trust is built in this order. The stages are from her talk. She names only the start (1 to 5) and the goal (100); the counts in between are our estimates.

11–5 agents
Verification
A way for agents to run your real app and show proof, so you stop being the tester.
Done when: An agent drives your app and hands you a screenshot, value or trace from it.
/create-verification-skill
2~5 · our estimate
Craft
pstack itself. Verification proves it works; craft makes it good code.
Done when: One real task done through /poteto-mode, with evidence and a diff you reviewed.
/poteto-mode
3~10 · our estimate
Encode corrections
Each time you correct an agent, push the fix up the ladder below: codebase, static analysis, then prose.
Done when: The same mistake gets caught without you in the chair.
/correct · /reflect
4Dozens · our estimate
Parallelize
Cloud agents instead of worktrees, fanned out with /swarm and /arena, left running overnight.
Done when: You go to bed and find verified PRs in the morning.
/swarm
5100+
Outer loop
Routines and automations that start work from Slack, Sentry and alerts without you.
Done when: Bug reports get reproduced and fixed with video before you've read them.
Grok Bot routines · Cursor Automations

fewer agents, low trust · more agents, high trust

Whenever you correct your agent, push it upstream

A correction you only say in chat is gone next session. Put it as high up as it will go. In her talk (Sep 21): “If there's only one thing you take away from my talk, it should be this.” On Oct 16 she redrew it as four levels, an upside-down pyramid: “you want most of your effort at the top, least at the bottom.”

01Codebase improvementsImpossible
Better architecture, stronger types, clear boundaries. Agents copy what exists, so change the code until the mistake can't be written. “make the easy thing the right thing. categorically eliminate problems through code and you won't need to think about it again.”
02Static analysisCaught early
Checks that run on every change and catch the mistake before anyone reads the code. Formal verification lives here too. “lint rules, tests, CI, verification (eg TLA+). very token efficient ways to catch issues ahead of time.”
03ProseGuidance
Anything written down that an agent has to choose to follow. Rules, skills and comments are now one level. “comments, rules, AGENTS.md, skills - anything that can't be enforced and requires agent judgment. use it minimally, but do use /create-verification-skill.”
04Human reviewHuman only
At the rate agents land code you can't read every PR. Spend your effort on the levels above instead. “the hardest to scale.”

What changed from the talk: rules, skills and comments are now one level (prose), formal verification sits with static analysis, and human review is the bottom level.

/correct climbs it for you · new Oct 3

/correct finds the mistakes agents keep repeating in your repo and fixes each one as high up as it will go: architecture first, then types, then a lint whose error names the fix, then a test, docs last. It proves each new check fails on a real past mistake. Run it again each time you correct an agent. /reflect is its partner one level down: it turns a finished run into a skill edit.

The gardener

Agents copy whatever they see. One workaround with a comment explaining it becomes the house pattern in a week. So every team needs a gardener: someone watching the PRs go by and pulling weeds. “Every weed you pull becomes a rule, so it can't grow back.” In her Grok Bot codebase, that even meant banning code comments, because agents used them as an excuse not to fix the real problem.

Her prompt: make your codebase agent-friendly

From the same post, word for word. It mines your past feedback and commits for the mistakes agents repeat, then plans a rearchitecture backed by prototypes. Step 4 makes the agent restate the job before it starts.

Lauren's prompt · Oct 16

install https://github.com/cursor/plugins/tree/main/pstack and create a new Project:
1. look through my slack/chat messages and code review comments where i've given feedback on PRs, code, architecture
2. use /recall on my past transcripts to learn how i steer agents
3. /poteto-mode use /correct and /architect on past commits to find the most common pitfalls agents fall into, then propose a plan to rearchitect the code i own so it's more agent friendly. answer open questions with prototyping rather than defer to me, and back the plan with real data.
4. before you begin, use /sharpen + /in-your-own-words and confirm this prompt with me

When to use what

Most of the time you only type /poteto-mode and your goal. It picks a playbook and runs the right skills. Use this to learn what's in there, or to call one directly.

1Reads your ticketGoal and done-when, in your words.
2Picks a playbookOne of 23. Its steps go into a todo list, word for word.
3Calls skillshow, why, architect, swarm, interrogate… as each step needs them.
4Opens a PRSmall commits, a briefing-style description. Then stays on for the next turn.

Start here · it usually picks the rest for you

Grouped by where each skill usually shows up. These aren't steps to follow: /poteto-mode calls them in whatever order your task needs. Tap one to see when to use it and what to type. 9 are new since Sept 29.

Understand

8

Before any code

Design

3

Try shapes before you commit

Build

3

While the code gets written

Check

11

The pass: prove it, attack it

Long runs

2

When you step away

Improve the kitchen

4

So the next run is better

The 24 principles/poteto-mode reads these before every task. You rarely call one yourself.

attack-the-premise Two fixes failed for the same reason? Test the shared assumption before a third.
boundary-discipline Check inputs where data enters the system; trust it inside.
build-the-lever Build the tool that does or proves the work, instead of doing it by hand.
encode-lessons-in-structure Said the same thing twice? Make it a lint, check or script.
exhaust-the-design-space No precedent? Build two or three prototypes and compare.
experience-first User delight over what's easy to build. Fewer, polished features.
explain-the-number Before you trust a measurement, find what limits it.
fix-root-causes Trace the symptom to where things first went wrong, and fix it there.
foundational-thinking Get the data structures right first; the rest gets obvious.
guard-the-context-window Send bulk reading to helpers; keep only summaries in the main chat.
laziness-protocol The smallest change that solves it. Lean toward deleting.
make-operations-idempotent Running it twice, or after a crash, ends in the same place.
migrate-callers-then-delete-legacy-apis Move everyone to the new API and delete the old one together.
minimize-reader-load Fewer layers and less hidden state between a question and its answer.
model-the-domain Lots of branching? Model the real states instead.
never-block-on-the-human Don't ask permission for work that's easy to undo.
outcome-oriented-execution In a rewrite, head for the target; skip throwaway in-between states.
prove-it-works Check the real thing, not a proxy or “it compiles”, before saying done.
redesign-from-first-principles A new requirement may mean a new design, not a bolt-on.
separate-before-serializing-shared-state Two writers on one thing? Stop the sharing before adding locks.
sequence-verifiable-units Small steps, each checked before the next, in an order a reviewer can follow.
subtract-before-you-add Remove dead code first, then build on the simpler base.
test-behavior-not-implementation Test what users see, so tests survive a refactor.
type-system-discipline Make illegal states impossible to write in the types.

Her prompts use /control-app. That's her name for the verification skill that /create-verification-skill makes; yours will be named after your app. Full lists: the README and the 10-chapter guide. The map idea is borrowed from Eric Tech's pstack map; the 33 skills and 24 principles here come straight from the pstack 0.15.30 repo.

Inside the pass

The skill she treats as critical infrastructure, “you may even want to put an oncall rotation on it.” Two parts: a CLI to drive your app, and a Feature Map so agents know where everything is.

What /create-verification-skill writes (her example app, Atlas)

.cursor/skills/verify-atlas/One project skill, named after your app
SKILL.mdHow and when agents use it
control-atlas.mjsThe CLI: doctor, new-session, send, click, screenshot …
references/features/The Feature Map
README.mdThe map: every feature, with links to details
preferences.mdOne feature: what it is, how a user reaches it

poteto/verification-skill-example

The CLI: a lever, not a script

Agents run the same command every time instead of writing a throwaway script to click a button. Fewer tokens, same result twice. Make it agent-friendly:

Easy to compose (deep modules)
--dry-run on anything destructive
Subcommands reveal features gradually
Errors say what to do instead
Rich --help
Machine-readable output (JSON)

The Feature Map: memory in markdown

Every feature, what it does and how a user gets to it. It exists because a user posted a tiny screenshot and three question marks, and agents couldn't tell which part of the app they meant. The agent writes it for you. Run /maintain-verification-skill daily so it doesn't drift.

Later, only for risky code: formal verification

Tests check the cases someone thought to write. Races, retries, state machines and parsers break on the case nobody wrote. /create-formal-verification-skill proves one rule across every case with a checker such as TLA+, and /maintain-formal-verification-skill keeps that model true as the code changes, the way the regular maintain skill keeps the Feature Map true. Both arrived Oct 18 and 19. Build the regular verification skill first.

Then: cloud agents, not worktrees

Worktrees eat your disk and cap out around 10 agents. Cursor cloud agents each get a real machine that can run your app, record video and take screenshots.

Plan with code, not plan mode

“Abstract plans only give you the illusion of progress.” pstack has no planning skill on purpose. She plans by prototyping, and trusts what actually ran.

1 · Draw it out of the agent

Don't tell it your theory. Ask it to restate your goals in its own words. You catch misunderstandings before any code, and you don't lead it down your wrong guess. Since Oct 13 that's a skill: /in-your-own-words.

2 · Measure a hundred times

Two common mistakes: accepting the first design, and polishing a plan with no evidence. The prototype playbook builds a few throwaway versions and measures them.

3 · Work backwards

For shared code, write the tutorial first, then build what it describes. /technical-writing keeps tutorial, how-to, reference and explanation apart (Diátaxis).

/architect for bigger changes

1GroundRun /how and /why over the systems it touches.
2SketchSeveral runners, often different model families, each draft types, signatures and the caller's usage.
3Cross-judgeA different model scores the sketches against a strict rubric and merges the best.
4ImplementFill in the sketch. Surprises like an extra parameter get flagged, not hidden.
5Scrap if wrongCasts, `any`, or the same workaround in many places mean the design is wrong. Start over.

Still want a plan? After the design is settled: /poteto-mode turn this design into a plan. Every task in it has to be proven by running the code, not just by tests. For week-long projects she commits the plan so other agents see it, then deletes it when done.

Set it up

In Cursor, about 10 minutes plus however long the verification skill takes to build. Also on the Cursor Marketplace.

01Install in Cursor
In a Cursor chat. In Grok Bot, add the pstack plugin instead.
```
/add-plugin pstack
```
02Pick your models
Asks for a reasoning budget and which model does each job. Then start a new chat so the rule applies.
```
/setup-pstack
```
03Build the pass
Setup offers this if your project has no way to prove app behavior. Say yes, or run it yourself.
```
/create-verification-skill
```
04One small real task
Describe it like you would to a colleague. Watch the todo list: the playbook's steps come first.
```
/poteto-mode add a --json flag to this command. text output stays byte-identical. verify both.
```

Press Opt + Enter when you autocomplete /poteto-mode to pin it as a Custom Mode, so it's reminded every turn.
Optional: cursor-team-kit adds deslop, control-cli and control-ui, which poteto-mode mentions but pstack doesn't bundle.
On Grok Bot: install the pstack plugin, and add Dr Eggbot, her bot that builds bots. Ask it for an engineer bot that runs /create-verification-skill and a daily /maintain-verification-skill routine.

Not in Cursor?

Two other ways in, checked Oct 23, 2026. Same skills, fewer Cursor-only features. In both, steps 2 to 4 above still apply.

Claude Code

Official, from Lauren's repo, since Oct 16

Her skills with an adapter. Commands get a prefix: /poteto-mode becomes /pstack:poteto-mode. Run /pstack:setup-pstack to pick models. Roles set to a non-Claude model run on your session's model, and steps that need Cursor (cloud agents, Bugbot, Automations) are skipped with a one-line note.

Install in Claude Code

/plugin marketplace add cursor/plugins
/plugin install pstack@cursor-plugins

The Claude Code adapter

T3 Code

t3-pstack, by Christian Houmann. Not Lauren's

Her skill text with only the Cursor parts rewritten for T3, synced from her repo. Review panels can mix Claude, GPT and Grok. Then run /t3-pstack:setup-pstack. Still a release candidate (2.0.0-rc.18 on Oct 23).

Install in T3 Code

npx -y github:chhoumann/t3-pstack install

t3-pstack on GitHub

FakeNerd's take

Start at the pass, not the line

The temptation is 20 agents on day one. Her whole story says the opposite: without a verification skill, more agents just means more slop to review.

You need an app agents can drive

Verification leans on rich runtimes: Chrome DevTools for web and Electron, the simulator for iOS. If your stack is hard to debug, she'd build the tools, or even pick a different stack.

Cursor first, but not Cursor only

Custom Mode, cloud agents, Bugbot and Automations are Cursor's. Since Oct 16 there's an official Claude Code install that skips those steps with a one-line note. You get her skills, minus the parts that need Cursor's machines.

The PR counts vary

2,000 in the talk and Pt. 1, 2,462 for August in an image caption in Pt. 2, 2,500 in the talk's tweet. All her own claims. The method matters more than the number.

Attribution

Lauren Tan (@poteto): Loops You Can Trust (Jun 24, 2026), The Complete Guide to pstack Pt. 1 (Aug 31), Pt. 2 (Sep 9), her talk (Sep 21), and her post redrawing the correction ladder (Oct 16). Her prompts are quoted word for word.
Rob Shocks · Pstack Is Agent Overkill. Use It Anyway! (Sep 8, 2026), an outside walkthrough and test.
pstack 0.15.30 README, guide and SKILL.md files, MIT, for playbook and skill names, checked Oct 23, 2026. The Claude Code install and its adapter are in the same repo.
t3-pstack is Christian Houmann's port for T3 Code, MIT, built on Lauren's pstack and Michael Denyer's pstack-claude. Not Lauren's.
The skill map idea is from Eric Tech's pstack map. We didn't use his data, which mixes an older pstack with a Claude Code port.
FakeNerd's: the kitchen floor plan and the station names beyond “head chef”, “line cooks” and “the pass”, the skill map's groups and plain descriptions, and the in-between agent counts on the trust curve.