Pstack Is Agent Overkill. Use It Anyway!

🧠 What Is pstack?

pstack is the personal skill stack of Lauren Tan — better known by her handle poteto. She's a self-described "ninja engineer" who has worked with millions of lines of code at Meta, Netflix, SpaceX, and Cursor; she's also on the React core team, where she helps build and maintain the React Compiler. In her own words, she's "not a president or CEO" — just an engineer who ships.

The stack got famous for a simple reason: it was used 10,000 times in one week by Cursor's own engineering team, and then she open-sourced all of it. Rob Shocks calls it "a senior engineer's brain extracted into one stack." Even if you never run pstack, reading its skills and principles gives you a breakdown of how a serious agent practitioner works at scale.

Structurally, pstack breaks into three layers: the principles (engineering rules), the playbooks (operating procedures that tell the agent what to do next), and the individual skills and slash commands that do the work. It's designed to run on an established codebase — not for greenfield spec-and-planning flows.

🔀 The /poteto-mode Router & Its 23 Playbooks

The heart of pstack is /poteto-mode — a router that reads your request and decides which of the 20-plus skills (and 23 playbooks) to use first. You invoke it at the start of any non-trivial task, and it matches your ask to a playbook, opens a todo list with the playbook's steps copied in verbatim, and routes to the other skills as each step fires. It's also a sticky mode: once entered, it stays on across turns, applying itself when a playbook matches and staying out of the way otherwise.

The 23 playbooks cover concrete situations — investigation, bug fix, perf, hillclimb (sustained single-metric improvement), runtime forensics, trace forensics, feature, refactoring, prototype, visual parity, eval, babysit (drive a PR to merge-ready), shipping, autonomous run, orchestrate, autopilot-full, autopilot-stack, session pickup, pause safely, multi-phase plan, worktree cleanup, and opening a pr.

You can run pstack anywhere: Cursor natively via /add-plugin pstack, and — through an unofficial community port by michael-denyer/pstack-claude — in Claude Code, Codex, OpenCode, Gemini, and Prime Agent.

⚔️ Arena, Swarm & Fearless Parallelism

/arena is the "fight it out" skill: pit three or four different agents (or models) against the same problem, then take the best parts of each and wrap them into a final commit. In the video's demo, a design idea was distributed between Claude, GPT, Grok, and Opus 5 — "there goes the token budget." Each sub-agent learns something while working the problem, and based on what they learned, arena decides to either graft a part into the result or reject it. Cursor actually had arena baked in six months ago and later removed it.

/swarm is the sibling: parallel workers again, but each gets a different slice of the problem, and everything is pulled back into one aggregated report. Together they deliver what the README calls "fearless parallelism" — working across feature branches and worktrees without overlaps, aggregating all the work into one coherent result.

🔍 Why, Recall & Interrogate: Context and Critique

/why is the skill Rob flags as "definitely stealing." Instead of just reading the project's code, it discovers all the MCPs and CLIs available at runtime and queries each evidence category in parallel — source control, the issue tracker, long-form docs (decision records / ADRs), real-time chat (a Slack thread about why a feature was built), infra observability, error tracking (Sentry logs), and the analytics warehouse (PostHog). The result is a full big-picture answer to "why was this done this way?"

/recall is for picking up where you left off — after a week away, it scans your chat history and the shared record, and uses /why to check your MCPs (Notion, Linear, PostHog) to rebuild your recent context as a tight current-state brief. /interrogate sits on the validation side: hand it a diff and several different models try to break it, including a strict code-quality lens, then all report back with their opinions.

✅ Verification-First: create & maintain verification skills

The skill Rob calls out as "absolutely love" is /create-verification-skill. On his Molten Base build, the app had a large surface area where it could appear to work while being fundamentally broken or returning wrong data. The skill generated its own scripted way to prove out app behavior — a project-local verification skill that drives the app the way a user does, in any language, framework, or platform. It delved into multiple projects and setups, scanning continuously to make sure everything was updated.

/maintain-verification-skill is the counterpart: as the app develops, the verifier you set up tends to diverge from reality, so this skill goes back and makes sure the verification scripts stay current. When you're dealing with non-deterministic agents, this kind of cross-check is "so valuable." The deeper point flows through the whole stack: a compiling, green test suite is not the same as actually proving the artifact works — you need deeper verification, whether that's computer-use or end-to-end testing.

The same "build a lever" instinct extends to /tdd — write unit tests first and make them pass before proceeding — and /blast-radius, which answers "what else could this small change break?" with a safety fact proven by running code, not asserted.

✂️ unslop & bro: Cleaning Up the Output

/unslop is an "absolute gift" if you use agents for writing. Its job is to cut the AI tells from any text — killing the annoying phrases like "pivotal moment," "crucial," "delve," and "enduring," and (the controversial one) getting rid of em-dashes entirely. Rob notes he actually likes em-dashes and used them long before AI — but they've become such a tell that he's resigned to seeing them go. The skill's own description is blunt: "Cut AI tells from any writing. Must always apply."

/bro is the gift for clarity, particularly when your brain has been burning hard on ten different agents all morning. It restates the last message in plain human language, with no jargon. Two other writing-adjacent skills round out the set: /technical-writing for framing unslopped replies for the consumer and the maintainer, and /no-comments for when comments should be removed rather than preserved.

📜 The Methodology: show-me-your-work

The /show-me-your-work skill keeps a reviewable decision trail — a TSV log with one row per decision (what, why, evidence, result) — for long-running or unattended work. Rob ran it on the very first invocation of his one Molten Base prompt, and the trail is instructive: it reads like a good engineer thinking out loud.

The flow went probe → frame → scaffold → arena → design-changes-forced-by-reality → verification → audit. It started with a probe — a quick throwaway test to see whether the thing was even possible before committing to building a whole app. Then it framed the requirements and constraints ("operate on Mac first, then other systems"). Only after scaffolding did it enter the arena stage with four parallel agents.

Then came verification and testing, finishing with an audit — and here's why verification matters: the agent had hallucinated some details, caught three false claims, and corrected them. The decision trail is what makes that catch visible and reviewable.

🧭 21+ Engineering Principles

The video highlights the principles that matter most, and the live repo organizes them as named principle-* skills (over 20 of them). A few worth internalizing:

Laziness protocol. When refactoring, look to delete code where possible and make things simpler rather than adding more — aim for the smallest change that gets the job done, because that leads to far more maintainable code. Related: subtract-before-you-add.

Redesign from first principles. As a project grows, the agent might be tempted to bolt on the next feature. Instead, imagine you were adding this feature from day one — how would you structure the code, scaffolding, database, and types to make it a native feature? This may mean removing structures and code to reach the happy place. Lauren's goal isn't more code; it's maximum impact with the least amount of code.

Minimize reader load. Everyone's sick of huge agent-written PRs with disjointed code across several abstractions and modules. Keep things simple with the minimum number of abstractions.

Exhaust the design space. This is where arena shines — run multiple models and agents on the same problem, take the best of all, and graft the best parts into the final commit. Rob teaches a related "design mode" in his course: scaffold a couple of interface variations with no backend, then pick the best before moving forward.

Build the lever. If you're doing something by hand multiple times, build a tool for it — a CLI or a script that repeats the same verification (as seen with the verification skills). Two more principles thread through everything: prove-it-works (green tests ≠ working artifact), guard-the-context-window, and never-block-on-the-human — offload slices of the task to sub-agents with their own context windows, which report back to the central thread.

⚖️ Pstack vs No Stack: The Verdict

Rob ran the comparison himself. Using Fable 5.1 with no plan mode and no skills attached, the project took about 30 minutes. Using pstack, it took 1 hour — twice as long. But the difference between the two projects is substantial: the pstack version is a much more hardened application.

The honest takeaway: pstack is overkill for small design changes or front-end UI tweaks — you probably don't need it there. But for critical features where tokens aren't the constraint, the verification-first discipline is exactly what separates rigorous engineering from slop. The whole point of the video is that you don't have to adopt it wholesale — even just reading the skills and principles will make you a better agent practitioner.

✅ Key Takeaways

1. pstack is a senior engineer's brain in a stack. Lauren Tan (poteto) used it 10,000× in a week inside Cursor, then open-sourced it — 23 playbooks, 20+ workflow skills, and 20+ engineering principles.
2. /poteto-mode is the router. It reads your request, matches it to a playbook, and routes to the other skills as steps fire — a sticky mode that stays on for the whole task.
3. No planning skill, by design. "The best spec is the code." pstack runs on established codebases, not greenfield spec-and-plan flows.
4. Fearless parallelism. /arena pits 3–4 agents against the same problem and grafts the best parts; /swarm slices a problem across parallel workers and aggregates one report.
5. /why queries your MCPs, not just the code. Source control, issue tracker, Slack, Sentry, PostHog, and ADRs — pulled in parallel for the full "why" picture.
6. Verification is the through-line. /create-verification-skill and /maintain-verification-skill prove behavior with scripted checks, because green tests ≠ a working artifact.
7. /unslop and /bro clean the output. Cut the AI tells (including em-dashes) and restate jargon in plain language.
8. show-me-your-work leaves a decision trail. A TSV log per decision caught three hallucinated claims and corrected them.
9. The principles favor less code. Laziness protocol, redesign-from-first-principles, minimize-reader-load, exhaust-the-design-space, build-the-lever — maximum impact, minimum code.
10. It's overkill — until it isn't. pstack roughly doubled build time (30 min → 1 hr) but produced a substantially harder app. Skip it for UI tweaks; use it when quality is the constraint.

🔗 Resources & Links

• 📦 pstack (official, Cursor) — the plugin and its skills, playbooks, and principles
• 🐦 Lauren's announcement thread and her pstack guide
• 🛠️ michael-denyer/pstack-claude — community port for Claude Code, Codex, OpenCode, Gemini, Prime Agent
• 🏪 Cursor marketplace listing
• 🏗️ Molten Base — Rob's own skill manager, built in one afternoon

Skill names, playbook names, and principle names were verified against the live pstack repository (cursor/plugins). The auto-generated caption track mangles several ("potato mode" → poteto-mode, "brawl" → bro, "onslaught" → unslop, "Cloud Code" → Claude Code); the repo names are authoritative.

🕒 Timestamp Index