All thoughts

How I Use pstack

Lauren Tan's pstack, explained plainly, and where it sits in my own workflow: an outer loop above the coding agents, proof before merge, and a person who says GO.

How it works

The agent factory, drawn as an isometric stackSix platforms stacked from bottom to top: spec and skills, agent builds, self-check where the agent runs its own work, the eval gate, a human GO, and ship. The self-check screen, the eval gate and the ship platform are lit in amber. A dashed line on the left carries repeated mistakes from the eval gate back down into skills and lint rules.repeat mistakes → skills + lintSpec + skills01 intentAgent builds02 harness + loopSelf-check03 runs itEval gate04 passedHuman GO05 approveShip06 release
Read it bottom to top. Only the parts that are switched on glow: the agent running its own work, the eval gate, and Ship. Repeated mistakes drop back down into skills and lint rules.

What pstack is

pstack is a pack of skills for Cursor, built by Lauren Tan (@poteto). A skill is a markdown file of instructions an agent reads before it starts working. Think of it as the onboarding doc you'd hand a new engineer who can code well but doesn't know how your team works.

She didn't set out to build a product. She watched agents fail, and each time she wrote a skill for that failure: stop guessing, read the code, use subagents, check your work before you say it's done. Over time those skills became pstack. The name is a joke. P is for potato (potato sack), a riff on Garry Tan's gstack. Same last name, no relation.

Her own advice on it is the part I repeat most: don't trust it blindly. Fork it and make it yours.

The idea underneath

The most important skill in her toolbox is verification. The agent has to run what it built the way a user would see it: open the app, click through, read the traces. If the agent can't check its own work, you become the checker. You copy screenshots and error messages back and forth, and you can only run one agent at a time because you're the bottleneck.

Two more ideas sit on top of that:

  • Evals are unit tests for skills. When you change a skill, you re-run a small test to make sure it still makes the agent better. pstack ships an eval playbook for this.
  • Hard rules beat soft ones. Agents forget written guidelines. If you keep leaving the same comment on pull requests, turn it into a lint rule or a CI check so the mistake can't land again.

The same loop in plain text:

watch an agent fail  ←──────────────────┐
        ↓                               │
write a skill for that failure          │
        ↓                               │
agent checks its own work (runs it)     │
        ↓                               │
evals check the skill still helps       │
        ↓                               │
trust it locally, where you can watch   │
        ↓                               │
hand it to cloud agents                 │
        ↓                               │
repeated mistakes → lint / CI rules ────┘

Lauren's ladder ends with auto-merge in the places where trust allows it. Mine stops one step earlier. More on that below.

My take

I build what I call the factory: agents, the harness around them, and an eval gate before anything ships. pstack is one part of that. It isn't the whole process, and I don't run it on everything.

I size the work first. Small fixes and docs go through my normal AI SDLC steps. Anything non-trivial gets its own Cursor Project. Complex work, the kind where a wrong first design costs days, gets pstack on top. Running the full pstack loop on a one-line change is just ceremony.

An outer loop sits above the coding agents. I keep a bot whose only job is to gather context from the codebase and docs, write the prompt, launch a cloud agent, and follow the work through review. It doesn't write the code itself. The prompt describes the problem and what good looks like. It doesn't spell out the patch.

On complex work, pstack changes how the agent starts. Before any code, the agent restates the problem in its own words, so I can catch a misunderstanding while it's still cheap. Then it grounds itself: how the code works today and why it ended up that way. Planning happens with code and quick prototypes rather than long plan documents, and the build lands in small pieces that can each be checked.

Proof means "what good looks like," written before the work starts. I write one to three done-when lines that a stranger could check:

  • A UI change: a before and after screenshot or video showing the exact state I named.
  • A bug: the repro fails before the fix and passes after, recorded with the same steps.
  • A refactor: nothing visible changes, and the main path still works.

Green lint, typecheck and tests are table stakes. They aren't the proof.

I review the artifacts, not the explanation. An agent's summary of what it did is a claim. The screenshot or the recording is the evidence.

I fix the system, not the pull request. This is Lauren's hard-rules idea applied to my setup. If I correct the same thing twice, it becomes a skill, a test or a lint rule, so no agent makes that mistake again.

No auto-merge. A person says GO. This is where I part ways with the furthest rung of her ladder. Lauren talks about autopilot merges where verification is strong and changes are easy to undo. I want a person accountable for what ships, so the agent stops at "ready for review," pings a human, and waits. I earn trust in a loop by running it by hand first and automate only after it has proven itself.

What I'd tell a teammate starting out

  1. Turn your second correction into a skill. The first time is a one-off. The second time is a pattern.
  2. Fork pstack and read every skill before you use it. Keep what fits how you work and delete the rest.
  3. Save it for hard problems. Plain prompts with clear proof cover most days.
  4. Keep the merge button for a person until a loop has earned your trust. Even then, keep it for anything you can't undo.

Try this

  1. Start with verification. Give the agent a way to run and see what it built. Until it can, you're the bottleneck no matter how many agents you open.
  2. Write the done-when lines before the prompt. If you can't say what good looks like, the agent can't either.

Sources

If you want it from her directly, these are the three I'd watch:

  • The pstack talk (about an hour). Verification, skills from failure modes, evals, hard enforcement. Start here.
  • Lauren with Matt Pocock (live Q&A). Inner and outer loops, moving the predictable parts of a skill into scripts, and reviewing by sampling instead of blocking.
  • Lauren and Roshan Sadanani on MTS (about 30 minutes). Where she describes herself as a head chef who trains the kitchen and owns quality control.