pstack · Lauren Tan (Cursor) · as of October 5, 2026

pstack skips the spec, and no agent signs off its own work

Its author’s answer to AI slop is not a better plan. It is deeper work on each task: settle questions by running code, and let nothing land until an agent that didn’t write it says it works. That is what lets one engineer run many agents at once.

This guide is written by EnsoDynamics, which makes the Enso Method. We compare our method with others as fairly as we can, and we recommend another method when it fits you better.

Two philosophies at a glance

pstack

Go deep first: settle questions by running code, keep agents unblocked, and land nothing on the word of the agent that wrote it.

The Enso Method

Write down what the people who decide want, keep it current as the system changes, and prove each requirement before the user commits it.

Where they differ

Specs serve one change Specs live as long as the system pstack sits at the “Specs serve one change” end; the Enso Method sits at the “Specs live as long as the system” end.
Starts from a prompt Intent written down first pstack sits toward “Starts from a prompt”; the Enso Method sits at the “Intent written down first” end.
One change at a time A body of work defined in full up front pstack sits at the “One change at a time” end; the Enso Method sits at the “A body of work defined in full up front” end.
The developer at the keyboard decides Someone who isn’t at the keyboard decides pstack sits at the “The developer at the keyboard decides” end; the Enso Method sits at the “Someone who isn’t at the keyboard decides” end.

What they share

Passing tests are enough Every requirement proven against real systems pstack sits at the “Every requirement proven against real systems” end; the Enso Method sits at the “Every requirement proven against real systems” end.
Built to be watched Built to run unattended pstack sits at the “Built to run unattended” end; the Enso Method sits at the “Built to run unattended” end.

Neither end of a line is the right one. Every comparison uses the same lines, so you can compare across methods.

Go deep first, then go fast

“If you want to go fast, go deep first.” That line opens pstack’s plugin description and appears at the top of its README. Further down, the README says why pstack has no planning skills: “i don’t believe in planning. the best spec is code.”

Lauren Tan, who ships code at Cursor and works on the React core team, built pstack against “slop code”. Her reasoning: once you trust one agent to write good, verifiable code, you can run many in parallel with confidence. So the rigor goes into each task. Any question the agent could answer by running something, such as a layout, a timing or an approach, “is not the human’s to answer”: it builds a throwaway prototype and lets the result decide. Nothing counts as done on a green build either. Done needs the real command, value or screen behind it, and “Tests alone are not sufficient verification.”

One command, twenty-three playbooks

Say the goal and the check. “repro first, then fix and verify.” /poteto-mode matches the task to one of 23 playbooks and copies its steps into the to-do list. A skipped step stays visible with its reason.
Understand. /how traces the code; /why digs through history, tickets, chat and logs.
Design. For code that crosses a function boundary, models from three different families (by default) sketch competing designs, each starting from how a caller would use it.
Build and prove. A subagent writes the code; the lead reviews it and verifies on the running app or command.
Land. A pull request, then “land the stack”: a fresh agent checks each one live, and only verified ones merge.

The README’s example of using it: “/poteto-mode i’m going to bed. land the stack even if ci flakes. i want everything merged by morning.”

Built for an engineer running many agents

pstack fits an experienced engineer in a team codebase who decides what to build, already trusts an agent with a task it can check, and wants many running at once, some overnight. It is strongest where running the software shows whether the work is right: bug fixes, features with a visible result, refactors, migrations and performance.

Its guide names the price: “pstack spends extra tokens on subagents and review panels. That’s the price of the rigor.” It runs in Cursor, with Cursor’s team kit beside it. It suits you less if someone else must read and sign off the requirements, or for small edits, where its guide itself says to skip it.

Where the Enso Method made a different call

Both keep the agent working instead of asking questions it can answer itself, and both want proof beyond a passing test suite. They part on three things.

Where the spec lives

pstack

In the code. A prompt states the goal and the check, prototypes settle open questions, and a written plan is optional and deleted when the work lands.

The Enso Method

In a PRD and technical design written before the build and amended before every change.

Choose by situation: if you own the code and judge it by running it, pstack’s way is lighter. If others must later read what the system is meant to do, the Enso Method keeps it written down.

Who answers the product questions

pstack

You do. A question no experiment can settle goes to you, or under a full-autonomy grant a default is reported to you.

The Enso Method

Business questions go to the people who own them as written proposals, and the build continues while they confirm.

Choose by situation: if you own the product, pstack. If you answer to a client or business owner, the Enso Method.

What lets a change land

pstack

“a verdict from an agent that did not write the code.” With your grant, verified changes merge without you reading each one.

The Enso Method

A fresh-eyes review and test hardening, then you read the diff and commit it.

Choose by situation: if you run many agents on your own codebase, pstack keeps you out of their way. If you deliver work someone else pays for, the Enso Method keeps one person accountable for every change.

Where pstack shines

Proof from the running app. It generates a skill that drives your app the way a user does and captures screenshots and video. The Enso Method has no scripted way to drive the app; its one such step is a browser check on UI changes.
Reviewers from other model families, on designs, diffs and even its own overnight decision log. The Enso Method’s reviews use the same model.
Mistakes fixed in the repo. /correct turns a mistake agents keep making into a type, lint or test that fails on the old mistake. The Enso Method has nothing like it.
Overnight runs you can audit, from a decision log checked against what actually happened.

How the Enso Method differs, and why

The code is the only spec pstack keeps: prototypes settle the questions, the person at the keyboard makes the product calls, and a change lands on the verdict of an agent that didn’t write it. The Enso Method writes the work down first and keeps it current for the life of the system, sends business questions to the people who decide as proposals while the build continues, and leaves each commit to its user.

How the Enso Method works Compare all the methods

Get started

pstack is free and open source (MIT), a Cursor plugin installed with /add-plugin pstack; its README at github.com/cursor/plugins/tree/main/pstack links the guide. A community port for Claude Code, Codex and Pi, github.com/michael-denyer/pstack-claude, tracks the original with a few changes of its own.