pstack: Lauren Tan's rules for agents you can trust

Most of us use coding agents the same way: open one, then another, then five more, and spend the evening reviewing pull requests we don’t quite trust. Lauren Tan takes the opposite route. She makes one agent trustworthy first, and only then lets it multiply. Secondary write-ups of a livestream she did in October credit her with about 2,500 merged PRs in August 2026, and she is careful to say that number was never the goal.

Her method is packed into pstack, a plugin of skills that now also runs inside Grok Bot, xAI’s always-on agents. I read the repository, the skill files and her own guide. Here is what I took away, with a clear line between what I could check and what I couldn’t.

Who Lauren Tan is

Lauren Tan goes by poteto online. The pstack README says she has worked on large codebases at Meta, Netflix and Cursor, and that she is on the React core team, where she helps build and maintain the React Compiler; her name is on the React Compiler announcements on react.dev. Secondary sources add that she spent about six years at Meta, left in March 2026, joined Cursor that spring (March or April, depending on the source), and now works on the engineering of Grok Bot. One profile describes her as self-taught and traces her path back to Excel macros. I couldn’t confirm that last part from a first-hand source, so take it as a nice story rather than a fact.

Three ideas

1. Trust one agent before multiplying. In her talk she says throughput comes from trust, not from opening more agents. She started like everyone, with one to five agents, reading every conversation and correcting constantly. Parallelism without trust just gives you more bad PRs, faster.

2. Fix at the root. When an agent makes a mistake, a reminder in the prompt is the weakest fix. pstack’s /correct skill climbs a ladder: change the architecture first, then the types, then a lint rule or a CI check, then a test, and only as a last resort, the docs. Each new check must fail on the real past mistake. The principle behind it is called encode lessons in structure: an instruction you repeat should become a lint, a script or a runtime check. Her mornings, by her account, include reading the commit history, reverting what looks wrong and adding a lint rule so it can’t happen again.

3. Verification is infrastructure. In The Complete Guide to pstack, she writes that verification simply means an agent can check its own work, and that a good verification skill is the most important tool a team can have. She suggests treating it like critical infrastructure, on-call rotation included.

What’s in pstack

The plugin lives in Cursor’s cursor/plugins repository under the MIT license. Its entry point, /poteto-mode, routes each request to one of 23 playbooks (bug fix, feature, refactoring, investigation and so on), delegates code to subagents, and refuses to call work done without evidence. The pstack page in Grok Bot shows 54 skills; the count moves with each release. As shown on that page:

Group	Skills
Start here	/poteto-mode, /setup-pstack, /poteto-help
Build	/architect, /arena, /swarm, /figure-it-out, /sharpen, /tdd, /blast-radius, /benchmark-checklist
Review and verify	/interrogate, /create-verification-skill, /maintain-verification-skill, /no-comments, /correct, /reflect
Write and personalize	/unslop, /technical-writing, /typescript-best-practices, /automate-me, /make-bot-ui
Understand and explain	/how, /why, /teach, /recall, /ketchup, /bro, /in-your-own-words, /show-me-your-work

On top of that come 24 principles (prove it works, fix root causes, test behavior, not implementation, subtract before you add…). The default model split, confirmed by the README, sends code to Grok (grok-4.7 on the page) and keeps the hardest changes, prose and judgment for Claude Opus 5.5.

Setting up an engineer bot

Here is the setup as I understand it from the pstack page and the Dr Eggbot listing:

1. Add the plugin. In Grok Bot, add pstack through Connect apps. It applies to the whole account, and typing / now shows poteto-mode.
2. Install Dr Eggbot. Lauren’s bot from the Bot Marketplace designs other bots. Coding bots follow the poteto-mode bar: one job, no slop, verified work. Non-coding bots get one job, one voice and explicit anti-jobs, things they must never do.
3. First run. Run /setup-pstack, then /create-verification-skill on a real repository.
4. Two health checks. Dr Eggbot installs two routines: on Mondays, an audit of routines that burn tokens for nothing; on weekdays, a re-read of recent chats to spot misunderstandings. Both stay silent when there’s nothing to propose.
5. Ask for the bot. Connect GitHub and Cursor, then describe the engineer you want. In my own words:

Build me an engineering bot for my repository.
Its one job: coordinate engineering work, not write it.
- Hand substantial coding to Cursor cloud agents or a Cursor Project, and follow up.
- Switch to /poteto-mode only when the task needs rigor: a tricky bug, a refactor, a perf issue.
- Before calling anything done, require evidence: a test that fails on the old code
  and passes on the new one, plus a before/after recording.
Anti-jobs:
- never write large chunks of code itself
- never merge a pull request that hasn't been verified
- never deploy
If there is nothing worth reporting, stay quiet.

6. Sanity check. Before letting it run, ask the bot to explain its job back to you (that’s what /in-your-own-words is for). If its summary drifts, fix the brief now, not after ten PRs.

The verification-first loop

The rule pstack enforces is simple: no “done” without proof. For a bug, the proof is a test that fails on the old code and passes on the new code. A test that passes both times proves nothing. For anything visible, Cursor’s cloud agents run on their own virtual machine, use the app in a browser and attach screenshots and videos to the pull request, so the agent can record a before and after video. A human then watches the evidence, not the diff alone, and decides whether to merge.

Case study: formal verification of notifications

Tests check the paths you thought of. Some bugs live in the orderings you didn’t: two devices, a sleeping laptop, a message arriving at the wrong millisecond. That’s where /create-formal-verification-skill comes in. It shipped in beta with pstack v0.15.27, and Lauren wrote that modeling their code in TLA+ had already turned up several bugs.

TLA+ in one paragraph. TLA+ is a language created by Leslie Lamport for describing systems, especially concurrent and distributed ones, with simple math. You describe the states (badge count, read or unread, Do Not Disturb on or off, laptop asleep or awake), the actions that can happen (a message arrives, you open it, you reply, the laptop wakes) and the rules that must always hold. A model checker, TLC, then walks through every reachable state and every ordering of actions within the bounds you set, and when a rule breaks, it hands you the shortest sequence of steps that leads there.

The use case described around the skill (I couldn’t find the original write-up, so read the details as illustrative) goes like this. The agent first draws a statechart of the notification system: badge, unread state, Do Not Disturb, laptop and phone sync. The skill turns it into a TLA+ verification kit, and the checker explores every interleaving. Three edge cases came out:

• a reply counted as a read, even though the message was never opened;
• the phone buzzing during Do Not Disturb;
• the laptop still showing unread after waking up, when the message had been read on the phone.

Each bug gets fixed, then the model is checked again. The skill also leaves behind a project-local skill so future agents can re-run the check after every change, and /statechart translates each violation into plain language.

Takeaways

• Start with one agent. Make its work verifiable before adding a second.
• Every repeated correction is a missing rule. Turn it into a type, a lint or a CI check, not one more line in the prompt.
• Treat verification as a product. A verification skill, a feature map and recordings are what let you review evidence instead of reading every diff.
• Give bots anti-jobs. What they must not do matters as much as what they should.
• Use formal methods where ordering matters. Notifications, sync and anything with two devices are good candidates, provided you replay the bugs on real code.

I haven’t run pstack on my own projects yet. In a follow-up article, I’ll set up the engineer bot on a real repository, try the verification skill and, if it fits, a TLA+ model, and report what holds up in practice.

Independent summary, not affiliated with Cursor or xAI. Figures and quotes come from the sources below.