Inside pstack: how Lauren Tan's skills turn a coding agent into an engineering process

In short: pstack is the set of skills, playbooks and subagents that Lauren Tan (poteto) open-sourced in the cursor/plugins repo. Its core is /poteto-mode, a router skill that picks a playbook for each kind of task, asks the agent to copy the steps into its todo list verbatim, and to name the principles it applied. The part worth learning is not the number of skills but three design decisions: almost every skill runs only when called, adversarial review uses several model families, and the verdict that lets code merge must come from an agent that did not write it.

Lauren Tan is on the React Compiler core team and wrote these skills while working at Cursor (the README calls them "the same skills i use every day to ship high quality code at Cursor"). The code lives in cursor/plugins/pstack under the MIT license.

This piece is based on the source at commit 9580c23 (pstack 0.15.32, committed at 10:27 on 24 October 2026, Indochina Time (UTC+7)), Lauren's posts on X, and community reactions. What this piece says about pstack's behavior is what the docs and source show. Most of pstack is Markdown instructions to a model, so when I write that something "asks the agent", read it as what the skill asks, not something the plugin enforces.

What pstack is

pstack is a plugin for coding agents with five kinds of parts:

Part	What	Role
Router skill	`/poteto-mode`	Reads the request, picks a playbook, applies principles
Playbooks	23 Markdown files in `skills/poteto-mode/playbooks/`, most under 25 lines	Steps per kind of work: bug fix, feature, refactor, opening a PR, overnight autonomous runs
On-demand skills	`/how`, `/why`, `/architect`, `/arena`, `/interrogate`, `/swarm`, `/reflect` and more	Investigation, design, review, verification
Principles	24 `principle-*` skills	One file per principle, read when needed
Subagents	`poteto-agent`, `comment-sicko`	The delegate that does assigned work, and a reviewer that hunts needless comments

Lauren explains the motivation at the top of the README: "throughput without quality is not a goal i aspire to. if you want to go fast, go deep first." When announcing the open-source release on 25 May 2026, Lauren added the line that sums up the whole pack: "The bottleneck with agents is verification." (post)

Installing

From the README:

In Cursor: type /add-plugin pstack.
In Claude Code: run /plugin marketplace add cursor/plugins, then /plugin install pstack@cursor-plugins. Commands get a prefix, for example /pstack:poteto-mode. For third-party marketplaces, Claude Code turns auto-update off by default. Turn it on, or update by hand with claude plugin update pstack@cursor-plugins.

After installing, run /setup-pstack once to choose a reasoning budget and a model per role. Lauren summed up usage in a post on 15 October 2026: run /setup-pstack, put /poteto-mode in front of any prompt you want done rigorously, and ask /poteto-help when unsure which skill to use (post).

Some playbook steps call skills that are not bundled: deslop, control-ui and control-cli ship in the cursor-team-kit plugin. The README suggests installing it too if you want the full set.

Architecture: one router, many small playbooks

The part most worth taking apart is how pstack routes work without loading everything into context up front.

Six steps of a task in /poteto-mode: you call the skill, it checks the task table and opens one playbook, the agent copies the steps into its todo list, each round goes to a fresh subagent, a different agent verifies, and the answer names the principles — One task through /poteto-mode. The points below explain each step.

Almost every skill runs only when called. Of the 58 main skills, 57 set disable-model-invocation: true. The exception is setup-pstack. The model does not load these skills just because their descriptions match the question. You type /poteto-mode, and poteto-mode calls the other skills by name. Lauren wrote on X that this means installing pstack costs no tokens until you invoke it (post). Note also that /setup-pstack writes a model rule file the agent loads into every new session.

A router short in lines. skills/poteto-mode/SKILL.md is 149 lines, but many are long, about 20 KB in total. It holds a task table, a one-line index of the 24 principles, autonomy rules, how to delegate to subagents, reply style, and the playbook list. It does not hold the playbook bodies. Each playbook is one line in this file, and the agent opens the playbook file only when the task matches.

The todo list is the contract. This is the line I like most in the whole repo:

"Open a todolist whose first items are the matched playbook's steps, copied in verbatim [...] A step you choose not to do stays in the list with a one-line skip: <reason>."

The skill asks the agent not to summarize the playbook or follow its "spirit" but to copy the steps. A skipped step stays on the list with a one-line reason. Anyone reading the session later can see which steps were skipped and why.

Name the principle and the decision it changed. poteto-mode asks the agent, in its reply, to name each principle that shaped a decision and the specific choice it changed. It may only cite principles whose full file it read in that session. The rule aims to block citation for show: naming "prove it works" without doing anything differently.

Fresh subagents by default. Each fix round, retry or follow-up goes to a new subagent with consolidated scope: the original brief, every later directive, and the previous agent's report and branch. The reason is stated plainly: "Interrupt-chained resumes silently drop directives". An existing agent is reused only when the new work truly needs state that lives in it, such as uncommitted changes or a running dev server.

The lead owns every subagent's work. "Review the diff and write your own summary, don't pass through what it said." The routing agent may not forward a subagent's report as is; it reads the diff itself.

What a playbook looks like

The bug-fix playbook is 15 lines. It asks the agent to reproduce the bug itself on the right surface (UI, CLI) before asking the user, find the cause by eliminating hypotheses, delegate the fix to a subagent, verify again on the same surface, and stage commits so the failing repro lands before the fix in git history. The closing rule: "Belt-and-suspenders that "might help" is a hypothesis, not a fix. It does not ship."

Not every playbook is short. multi-phase-plan.md is 155 lines and orchestrate.md is 112.

24 principles as a steering vocabulary

Each principle is its own skill, 9 to 34 lines long. The official guide (08-principles.md) explains how to use them: you don't invoke principles, you steer with their names. A phrase like "apply prove it works. run the real import flow and show me the written records." redirects the agent more precisely than a paragraph of instructions, because the agent has already read the full rule behind the name.

The 24 fall into five groups: core (how much to build, when to rethink the design), architecture (where state, validation and compatibility live), verification (what counts as proof), delegation (context and autonomy), and one meta principle about learning itself. The five I find most distinctive:

Principle	Gist	Line worth remembering
Build the Lever	Write the script, codemod or generator that does or proves the work, so a reviewer can rerun it	A deterministic script turns "trust me" into "run this"
Attack the Premise	When two fixes sharing one premise fail, suspect the premise, not the fixes	"Do not start the next fix before the premise is written down and tested."
Explain the Number	Name what limits a measured number before trusting it	Ask "why not double?": if you can't say why the number isn't twice as good, you don't know what you measured
Fix Root Causes	Fix the first wrong decision, not the place the symptom appeared	"If a workaround needs a paragraph-long comment to justify it, the code is wrong."
Encode Lessons in Structure	Turn a repeated instruction into a lint, check or script	"If the fix is structural, only use the structural fix. The instruction is the symptom."

The last one runs through the whole repo. The /correct skill mines commit history, reverts and review comments for recurring classes of mistakes, then fixes them in a fixed order: architecture first, then types and lint, then tests, then docs last. The reason docs come last is blunt: "Nothing fails when an agent skips them." Every new check must be shown to catch a real past mistake.

Lauren wrote on X that many principles came from correcting agents since the start of 2026, and that "Attack the Premise" was inspired by @VictorTaelin (post). The commit history shows the principles getting shorter and more abstract: commit e5136d8 rewrote four of them "as reasoning, not rules", so an agent can derive the call in cases the text never names.

Adversarial review across model families

Many review skill packs use personas: one agent plays the "security expert", another the "architect". For code review, pstack goes another way. The first line of /interrogate reads: "The adversarial signal comes from model diversity, not assigned personas." That is the author's design choice; the repo includes no experiment comparing it with personas. pstack doesn't drop role-based angles entirely either: /reflect still splits into three lenses, and comment-sicko is an explicit persona.

The multi-family idea repeats across skills:

Skill	How it runs	How results merge
`/interrogate`	One adversarial reviewer per configured model (Opus and Grok by default)	The lead sorts findings into act on, consider, noted, dismissed. Findings two models raised independently are the strongest signal
`/arena`	N candidates on the same prompt, each in its own output location (a worktree where possible), plus a cross-judge that preferably comes from a different family than the lead	Pick one as the base and hand-graft one or two good parts from the losers. If they diverge wildly, the prompt was under-specified: rewrite it instead of averaging
`/swarm`	Partition the work or race N workers	Each worker returns `PASS`, `ISSUES` or `BLOCKED` with evidence. "A gap does not count as a pass."
`/why`	One investigator per evidence source found at runtime (git, tickets, chat, logs, errors)	Separates what was found, what was inferred, competing hypotheses, and unknowns
`/reflect`	Three lenses over the session transcript: judgment, tooling, divergent	Waits for the user's approval before editing any skill

The same diff goes to an Opus reviewer and a Grok reviewer, and the lead agent sorts findings into do, consider, note and reject; a finding both reach is the strongest signal — /interrogate with the two default model families. The reviewer count follows the models you configure.

The lead is not a score adder either. /interrogate's lead-judgment.md warns about "nitpick gravity": reviewers that find no critical issue inflate nits to fill the report. The lead has to filter out hypothetical findings and "I would have done it differently" findings.

By default pstack gives code to Grok 4.7 and judgment and prose to Opus 5.5. The commit history shows these defaults changing with every new model, so /setup-pstack writes your choices into a separate rule file that shields you from the churn.

Verification is the bottleneck, so most of the real code lives there

The Markdown files under pstack/skills/ add up to about 432 KB. Executable code sits where verification needs it:

Part	What it does	Kind
`statechart`	Takes a TLA+ model and draws a Mermaid statechart, with each bug as a numbered path	About 5,100 lines of JavaScript, plus a test file declaring 150 test cases
`watch-pr`	Watches a PR or PR stack and returns typed verdicts (`READY`, `WAITING`, `BLOCKER`...) with distinct exit codes	TypeScript on Bun, with tests
`orch`	Bookkeeping for the multi-day orchestration playbook: work units, inbox, gates	TypeScript; records only, never spawns agents
`check-plan.mjs`	Lints a multi-PR plan file and requires a verification block per section	JavaScript, with tests
`create-verification-skill`	Generates a project-local `verify-<app>` skill: launch, doctor, drive, capture evidence, clean up, helper scripts, plus a feature map in `features/`	A prompt that generates a skill and scripts

On 30 July 2026 Lauren called /create-verification-skill and /maintain-verification-skill the two skills everyone should use or copy (post). A generated skill must run end to end once before it counts: "A generated skill that was never executed is a draft, not a deliverable." After cleanup, the evidence must still be where it was recorded.

/create-formal-verification-skill entered the source on 17 October 2026 (commit 4382e68, already in 0.15.26). Lauren introduced it on X with 0.15.27, called it beta, and said modeling their code in TLA+ had already found several bugs (post). The guidance on when to use it is practical: only when the code has concurrency, retries, a state machine or a parser, where bugs are costly and tests rarely reach them. The skill also states its own limit: "A pass covers the model or the bound, not the whole system."

The shipping rule lives in shipping.md: "Only a verdict from an agent that did not write the code counts, because an author checks what it meant to build." Per this playbook, green CI and an approving bot review are not verdicts, because they don't run the change the way a user would. That is pstack's own standard: your CI may well have end-to-end tests, but pstack still wants an independent agent to drive the change. To decide whether an old verdict still applies, the playbook compares git patch-id at the verified SHA with the current head. There is a narrow exception when only tests, docs or lint config changed and the build is equivalent, but the changed part still gets fresh checks and review.

How Lauren uses pstack: the first two parts of the guide on X

The source shows what pstack contains. Two guide posts Lauren published on X show how the author puts it together day to day: part one on 31 August 2026 and part two on 9 September 2026. In both, Lauren describes using pstack to keep the codebase of Grok Bot, a desktop app many people contribute to every day, in good shape, and pstack can also be installed as a Grok Bot plugin.

If you would rather watch than read, the video series Teardown: How Lauren Tan works with coding agents has five short episodes on Lauren's talk: agents that check their own work, skills and evals, trusting local agents first, hard constraints, and tokens as an investment. Much of it runs in the same vein as the sections below, especially the first episode on verification.

Part one: the verification skill is infrastructure

Lauren treats the verification skill as "critical infrastructure", not "just" a skill, something to maintain and even put on an on-call rotation. Three main ideas:

A small CLI instead of Markdown. This is the "Build the Lever" principle applied to verification. Instead of letting the agent write throwaway scripts to click things, the verification skill ships a CLI with commands such as doctor, snapshot, screenshot, wait-settle and feature-flag. Lauren lists what makes a CLI agent friendly: easy to compose, a --dry-run for anything destructive, subcommands that disclose functionality gradually, error messages that tell the agent what to do instead, rich --help, and machine-readable output such as JSON.
The Feature Map. A folder of Markdown listing every feature of the app, how to reach it as a user, and how to drive it with the CLI. In the source, /create-verification-skill generates a features/ folder with exactly four sections per feature: Sub-features, How to get to it (user POV), Driving it with <harness> and Gotchas. Lauren calls it "materialized memory": the codebase is the real memory, and the feature map is a compact form of it that saves tokens. To keep it current, Lauren recommends running /maintain-verification-skill at least once a day, and adds that agents usually update the map in the same PR that changes the app, with the automation catching what slips through (reply). Lauren also published an example repo for a fictional app called Atlas.
Cloud agents instead of worktrees. Lauren advises against running agents in parallel through local worktrees, since they eat disk and machine resources and top out around ten agents depending on the machine. Cursor's cloud agents get their own machine to install dependencies, run the app and record video. This is why the "tied to Cursor" point below matters: the Claude Code path turns cloud workers into worktrees, the very setup Lauren advises against.

On that base, Lauren pairs the verification skill with /swarm to have many agents measure a performance change with a large enough sample, and puts it into automations that try to reproduce user reports posted in Slack.

Part two: supervising an agent smarter than you

Part two is about deciding what to build, which Lauren calls "the art of supervising someone smarter than you". Lauren names two common failure modes: the agent misreads intent because the request is underspecified, and the agent lacks the context to do the work right. The responses:

Make the agent restate the problem in its own words. Instead of stating a hypothesis, Lauren asks the agent to read a Slack thread and "restate in your own words and in plain english" the underlying issue. This forces the agent to compress a noisy conversation into a clear problem statement, catches misunderstandings early, and avoids leading the agent down the asker's wrong assumptions.
Build a mental model with /teach and /recall. /teach runs /how and /why and weaves the results into one plain explanation. /recall rebuilds context from chat history so a fresh agent doesn't start from zero. Lauren notes this research helps the agent too, since models still state things confidently without reading the code.
Plan with code. pstack's README has a "why are there no planning skills?" section with the line "the best spec is code". In practice Lauren still plans, but through a README written first (with /technical-writing, which splits docs into the four Diátaxis modes), through the prototype.md playbook that builds throwaway variants behind a switcher, and through /architect. /architect grounds the problem with /how and /why, has several models sketch the interfaces and types through /arena, then implements against the sketch. If the types need escape hatches such as any or casts, that is evidence the architecture is wrong, and the agent scraps the sketch and starts over.
No adversarial review of abstract plans. Lauren writes that when reviewing a plan that is still on paper, agents "start hallucinating theoretical risks". Open questions should be answered with prototypes. The source agrees: /architect only suggests running /interrogate on the synthesized sketch, which already has types and function signatures, not on a document of ideas. When a plan is really needed, the multi-phase-plan.md playbook splits the work into small PRs, each with a verification section, and check-plan.mjs checks the structure. Lauren says plans usually get deleted once the work is done.

Part two opens with a screenshot reading 2,462 PRs to production in August 2026. That is still Lauren's own number.

How the repo grew in five months

The pstack/ directory has 162 commits. Dates in the table are commit author dates, in the time zone recorded in each commit. 156 commits list Lauren as the author, and October was the busiest month with 72. Notable milestones:

Date	Milestone
22 May 2026	First commit `24bd6eb`: `poteto-mode`, 18 principles, `how`, `why`, `architect`, `arena`, `interrogate`, `reflect`
6 June 2026	Per-role model config through `/setup-pstack`
12 July 2026	`create-verification-skill` and `maintain-verification-skill`
14 July 2026	Commit `3fe2823` "parity sweep with the private skill tree"
1-2 August 2026	Autonomous-run playbooks, Shipping, Orchestrate, and the `watch-pr` and `orch` scripts
7 September 2026	Style pass: "Attack the Premise" added, 239 semicolons replaced and tokens remeasured
16 October 2026	Official Claude Code install, generated from the source tree
17-23 October 2026	Formal verification, `statechart` with TLA+

Two things stand out in this history. First, the author keeps cutting: many commits exist only to reduce tokens or drop instructions newer models "don't need". Second, some changes are synced from an internal skill tree, judging by commit messages such as 3fe2823. I don't know how far the public pack differs from the internal one today.

What the community says, and what to know before installing

pstack drew a lot of attention and many ports. Taylor Otwell wrote "pstack is the new solid" (post). Matt Pocock's notes from Lauren's talk had three points: lock agents down, invest in verification infrastructure, and keep a feature map for navigation (post). On 19 August 2026 Lauren said they had shipped 1,000 PRs the previous month and were on track to double that (post). Part one of the pstack guide cites 2,000 PRs a month, and part two cites 2,462 PRs in August. These are Lauren's own numbers, with no denominator such as PR size or revert rate, and I could not check them.

Hands-on feedback, meanwhile, centers on three points worth knowing before you install:

It burns tokens. Ray Fernando said he passed two billion tokens in one day using pstack for everything, then kept it for hard tasks only (post). Lauren advises against using /poteto-mode for everything (post), and the setup guide says: "pstack spends extra tokens on subagents and review panels. That's the price of the rigor."
Overkill for small work. One user calls it "overkill" for most day-to-day work (post); another installed only a subset (post).
Tied to Cursor. Skills call Cursor-only features directly: cloud agents, Automations, Bugbot, .mdc rules. The Claude Code version is a mapping layer, not a rewrite. Per docs/harness/claude-code.md, Opus roles still map to Opus, while non-Claude roles such as Grok drop the model field and run on the session model. So in Claude Code the default Opus plus Grok pair doesn't survive, and if your session also runs Opus, both reviewers end up in the same family. The same file maps readonly: true subagents to Explore, which keeps Bash, so not editing files becomes an instruction in the brief plus a git status check. environment: "cloud" workers become worktrees, which means they run on your own machine instead of a separate cloud machine.

One technical detail I could check: the repo's only CI workflow runs node --test pstack/skills/*/scripts/test/*.test.mjs. That glob matches only the statechart test folder. The Bun test suites for watch-pr, orch and check-plan are not run by this workflow. I don't know whether they run anywhere else.

Because the official pack started as Cursor-only, the community ported it elsewhere. Star counts as of 24 October 2026; the last column is each repo's own description:

Repo	Stars	For
michael-denyer/pstack-claude	3,347	Claude Code, Codex, Copilot, Pi, OpenCode and other harnesses
backnotprop/pstack	2,655	Claude, Codex, Pi
ericlitman/open-pstack	519	Claude Code and Codex, tracking upstream
chhoumann/t3-pstack	226	T3 Code, with review panels split across Claude, GPT and Grok
ScriptedAlchemy/pstack-codex	71	Codex

The first two port repos were created four to five days after the first commit. The official Claude Code path arrived on 16 October 2026. I have not checked the ports' contents, so I can't say which tracks upstream best.

What to take home without installing pstack

This is the part I find most valuable. It works with Claude Code, Codex or any other agent:

One short router plus many small playbooks. Keep one file that maps task types to playbooks, one file per playbook. Ask the agent to copy the steps into its todo list verbatim and write skip: <reason> for any step it skips.
Name your principles. Write short named rules with a "you skipped this when..." test. Ask the agent to say which principle changed which decision.
Fix the repo, not the prompt. If you correct the same mistake twice, turn it into architecture, types, or a lint whose error names the right way. Docs are the last resort.
The verdict that allows a merge comes from an agent that didn't write the code. The author still checks its own work, but the deciding verification goes to another agent, ideally another model family. Treat green CI as an input, not a verdict.
Give long runs a stopping condition, not a duration. This is the discipline of the hillclimb.md playbook and the /show-me-your-work skill: one change, one measurement to keep or revert, one row in a TSV decision log per iteration. Anything that "might help" without evidence comes out. The 07-overnight.md guide also says to leave a loop alone only once it has earned your trust, and notes that /loop is a built-in Cursor feature, not a pstack skill.
A project-local verification skill. Give it launch, doctor, drive, evidence, cleanup and helper sections, a small CLI for agents to call, and a feature map describing how to reach and check each feature. Count it done only after it has run end to end once, and maintain it like infrastructure.
Have the agent restate the problem before fixing it. Give the agent the raw material (a thread, a bug report) and ask it to restate the problem in its own words, instead of offering your hypothesis.
Answer design questions with prototypes, not debates on paper. Build a few throwaway variants, measure or screenshot them, then choose. Save adversarial review for sketches that already have types and function signatures.

FAQ

Does pstack work outside Cursor? Yes. The official repo supports Cursor and Claude Code. Other harnesses such as Codex, Pi or T3 Code use community ports. On the official Claude Code path, steps that need Cursor-only features (Automations, cloud agents, Bugbot) are skipped with a one-line Skipped in Claude Code note, and multi-family review narrows. Community ports handle this however each porter chose.

Does installing pstack cost tokens? Almost every skill loads only when called, so an installed but unused pstack costs very little. Using /poteto-mode costs noticeably more than a normal session, since it spawns subagents and review panels. Lauren advises using it only for hard tasks and picking cheaper models for the code roles through /setup-pstack.

Where should I start? Read skills/poteto-mode/SKILL.md and the bug-fix playbook. Those two files show most of the pack's thinking, and you can borrow the ideas without installing anything.

Use this piece in your agent

Get an API key

Copy the text below and paste it into Claude Code, Codex or whichever agent you use. The agent reads the piece and checks it against the repo you have open.

Paste into your agent

Read "Inside pstack: how Lauren Tan's skills turn a coding agent into an engineering process" on modernEngineer and apply it to this repo.
1. Call the content_get tool of the modernengineer MCP server with locale "en", slug "pstack-teardown". If MCP is not connected or access is refused, read the page https://modernengineer.dev/en/library/pstack-teardown instead.
2. Summarize the main steps of the piece and point out which apply to this repo.
3. Propose concrete changes and ask me before editing any file.

Connect MCP in Claude Code (once)

terminal

claude mcp add --transport http modernengineer \
  https://api.modernengineer.dev/mcp \
  --header "Authorization: Bearer <API key>"

How to connect Codex, Cursor and other clients

This piece is open to everyone: without MCP, the agent can still read it straight from the link.

Version: v1.0.0
Updated: 29/10/2026
Slug: pstack-teardown