Read @poteto’s pstack, noting a few points.

1. pstack isn’t 56 standalone skills — it’s a methodology and workflow. Start with the verification skill and feature map, so the agent can run and operate the app on its own. Then use /poteto-mode to follow fixed flows by task type. Parallelism and auto-merging come last. If the first step isn’t done right, spinning up more agents only makes things more expensive, not more trustworthy. The way she splits it in her talk: verification handles “is it correct,” pstack handles “is it good.”

2. The approach to building verification is worth spending time on. First turn the app into a CLI: commands should compose, destructive operations should have --dry-run, output should be JSON, and errors should tell the agent what to do next. Then build the feature map — for each feature, spell out where the user enters, how it’s used, how the CLI drives it, and what the gotchas are. She calls this “materialized memory.” I plan to find a demo product to try it on, following her Atlas example.

3. The tech stack affects productivity — I feel this one deeply. So what makes a stack agent-friendly? My current answer: light, fast, debuggable, controllable. Electron and the web have CDP; iOS has the simulator. The harder a runtime is to debug and control, the harder it is for an agent to work with. She says it’s worth building your own debugging tooling for this, even switching stacks.

4. A few context-filling skills are worth a look too. /teach calls /how to trace runtime behavior, and /why to dig through git, PR comments, Linear, Slack, and Sentry for why something was written that way originally. /recall pulls context from past sessions. And /in-your-own-words makes the agent restate the problem in its own words first, so misunderstandings surface early.

5. She’s against adversarial review of abstract plans. Her reasoning: agents hallucinate risks and add guards for edge cases that will never happen. Her approach is to build two or three switchable prototypes first and measure them with the verification skill’s screenshots. Then have several model families each produce a type-signature-level design, critique each other, pick one, and implement. I’ve been using adversarial review all along — it does surface plenty of edge cases, but a lot of them are redundant. Next time I’ll try swapping some of the review out for prototypes and see how much gets missed.

6. 55 of the 56 skills disable model invocation, so Claude Code’s Skill tool rejects them outright. The mirror build created a mapping table that tells the agent to go read the corresponding SKILL.md and follow it. It works, but it adds a step every time one skill calls another, and eats more context. Still, this is a much better approach than products that just dump a pile of model-invocable skills on you.

7. The outer loop she describes in her talk isn’t part of pstack. Grok Bot is wired into Slack, Datogad, and Sentry, subscribing to Slack threads and Sentry alerts, and automatically dispatching cloud agents to reproduce bugs and open PRs. She ships 2,500 PRs a month, mostly on the strength of this layer plus verification — pstack is only a small slice. You have to build this layer yourself.

8. The four-tier order for turning repeated corrections into structure is also worth a look: eliminate it with architecture or data structures > have lint or tests catch it in CI > skill or rule > human review. She labels tier four “ngmi.” Her Dune framework is an example of tier one. Keep only one way to do each thing; when you spot a bad pattern, write a lint rule to stop the bleeding first, then have the agent clean up, keeping the codebase in a state where “even if an agent copies it verbatim, it’s right.” I plan to pick one error an agent keeps making and try /correct on it.

Detailed research at https://research.sorrycc.dev/@sorrycc/pstack .

pstack

Source: https://research.sorrycc.dev/@sorrycc/pstack

Analysis of the pstack Repository and Lauren’s Tweets

By Chen Cheng (https://research.sorrycc.dev/@sorrycc) · Published October 22, 2026

This report also has an interactive version.

Analysis date: October 22, 2026. The analysis reviewed backnotprop/pstack (https://github.com/backnotprop/pstack) (commit e44668c (https://github.com/backnotprop/pstack/commit/e44668c2aad92eacf4e84df47984121fefb11b82)), compared it against the upstream cursor/plugins/pstack (https://github.com/cursor/plugins/tree/main/pstack), read 19 relevant tweets one by one with bird, and read Lauren’s two long-form posts, “The Complete Guide to pstack” Pt. 1 and Pt. 2, as well as her own and other users’ tweets about pstack over the past two weeks. Also reviewed her 38-minute talk video posted on X on September 21 (https://x.com/poteto/status/2102050467505430555), originally prepared for Cursor Compile London; the transcript was auto-generated by Whisper, so proper nouns may be inaccurate. Tweet dates are recorded in UTC. All productivity and quality figures are the author’s self-reported numbers.

Conclusions First

The core of pstack is not 56 skills but an ordering: first make the agent able to run and operate your app on its own (verification skill + feature map), then use /poteto-mode to have it follow fixed flows by task type, and only then talk about parallelism and auto-merging. Without that first step, multi-agent flows downstream only get more expensive, not more trustworthy. Lauren lays it out in this same order in Pt. 1 herself. Her talk in September splits it even more clearly: verification handles “is it correct,” pstack handles “is it good” (performance, code quality), and you need both. The talk was titled “2,500 PRs,” but pstack only got a short segment — she said herself she wouldn’t go deep into the plugin today, attributing her productivity mainly to verification, agent-oriented architecture, and the outer loop that dispatches work automatically.

For Claude Code users, there are two things to note. First, the Grok model in the default config gets mapped to “inherit parent model” in Claude Code, so flows like /arena, /architect, and /interrogate that rely on “different model families reviewing each other” degrade into same-family self-review. Second, /poteto-mode itself is about 3,600 English words, and every poteto-agent subagent is required to read it in full — the more subagents, the linearly increasing fixed context cost. Worth using, but best used selectively.

Source Chain: Who Maintains What

Lauren Tan (@poteto)
  └─ cursor/plugins/pstack        original, a Cursor plugin, 0.15.30
       └─ backnotprop/pstack      Michael Ramos's mirror, 0.15.28
            · upstream branch: verbatim upstream
            · main branch: upstream + generalized rewrite
            · install: npx skills add backnotprop/pstack

Lauren used to be on the React team, then moved to Cursor to work on performance for the Agents Window. Cursor has since merged into SpaceX AI, where she works on Grok Bot. That’s why the default config mixes Claude and Grok: Grok is her company’s own model, so this combination first reflects her working environment and isn’t necessarily right for other hosts.

The value of the mirror is that hosts like Claude Code, Codex, and Pi can install it directly. The cost is an extra layer of sync delay, and the rewriting itself may drift from the original intent. MIRROR.md documents the sync method: on conflicts, “keep Cursor’s new meaning, then apply generalized wording.” Lauren said in a tweet that installing via Grok Bot or Cursor updates automatically, while the mirror waits for the maintainer to sync manually (https://x.com/poteto/status/2110047891201114165).

Updates come fast. 0.15.9 was released October 4, and by October 22 upstream was at 0.15.30 — roughly two dozen patch versions in 18 days. That’s good for trying things out, but a warning for anyone baking it into team workflows: the skill text changes at any time, and evaluation results will change with it.

Repository Structure

The repo contains 56 skills (24 of them principle-*), 23 playbooks under poteto-mode, two agent definitions (poteto-agent, comment-sicko), a set of Benny automations that only work in Cursor, 10 chapters of guides under docs/guide/, under the MIT license.

Approximate scale of each part:

poteto-mode routes by task type to different playbooks. A few hard rules worth noting: before asking the user “which option do you prefer,” first judge whether running something would answer that question — if so, go to the Prototype playbook and try it rather than asking a human; state the data structure before any code; changes crossing function boundaries go through /architect first; pass through deslop before committing and /no-comments before review; in replies, name which principle changed which decision, and only name principles actually read in this session. That last one is a very practical anti-bullshit design.

Methods From the Two Long-Form Posts

Lauren’s two long posts lay out the concrete methods and what pstack aims to solve.

Pt. 1: Verification is the prerequisite for everything (August 31). She treats the verification skill as “critical infrastructure,” even suggesting putting it on call. Three concrete points.

First, make operating the app a small CLI instead of having the agent write throwaway scripts to click buttons every time. This corresponds to the principle Build the Lever. She lists what this CLI should look like: composable, --dry-run on commands with destructive side effects, functionality exposed progressively via subcommands, error messages that tell the agent what to do, detailed --help, JSON output.

Second, the feature map. For each feature, spell out “where the user enters, how it’s used, how to drive it with the CLI, what the gotchas are.” She calls it “materialized memory”: code is a projection of the team’s decisions, the feature map is its compressed form, kept in a skill everyone shares. She published an example using a fictional app called Atlas (https://github.com/poteto/verification-skill-example).

Third, the tech stack affects agent productivity. Electron and the web have CDP, iOS has the simulator; the harder a runtime is to debug and control, the harder it is for an agent. She even says it’s worth building your own debugging tools or switching stacks for this. That’s a bold call, but the logic holds together.

Pt. 2: Plan with code (September 9). The theme is “supervising people smarter than you.”

• Align on intent first. Have the agent “restate the problem in its own words” (later built as /in-your-own-words) — it catches misunderstandings early and keeps your own assumptions from steering the agent astray.
• Fill in context. /teach calls /how (trace how it runs) and /why (find the motivation in git, PR comments, Linear, Notion, Slack, Sentry, etc.), and /recall pulls context from past sessions.
• Plan with prototypes, not long documents. She explicitly opposes adversarial review of abstract plans, on the grounds that agents hallucinate risks and design guards for edge cases that will never happen. The alternative: the Prototype playbook builds two or three swappable variants, measures them with the verification skill’s screenshots, then /architect has multiple model families each produce a type-signature-level design, cross-critiques them, and only then implements — if the design is wrong, tear it up.
• If you truly need a planning document, use the multi-phase-plan playbook, where every item’s definition of done is “verified by actually running it,” then use check-plan.mjs to check formatting. Plans for large projects get committed to the repo temporarily and deleted once done.

These two posts explain the README’s claim of “no planning skill”: it’s not that planning doesn’t happen — it’s that planning is replaced with something runnable.

What Actually Happens in Claude Code

docs/harness/claude-code.md is the mapping table added by the mirror. After reading it, several impacts stand out.

Multi-model review degrades. The default role config uses grok-4.7-xhigh-fast for code tasks, claude-opus-5-5-xhigh for judgment and writing, and puts one Claude and one Grok on each of the arena, architect, and interrogate review panels. The mapping table specifies that non-Claude models in Claude Code “omit model and inherit the session model,” with the default Grok written as inherit-parent. The result is both seats on a review panel running the same family. poteto-mode itself says “a second opinion is the same prompt with a different model; agreement is a strong signal” — that premise is weakened in a pure Claude environment. To recover diversity, you’d have subagents invoke external CLIs (Codex, Gemini, etc.), which pstack itself doesn’t provide.

Cloud agents become worktrees. The mapping table swaps environment: "cloud" for isolation: "worktree". Yet in Pt. 1 Lauren specifically advised against worktrees for parallelism, saying they eat disk and machine resources and you hit a wall at around ten locally. What she markets — “one machine per agent, recorded screenshots, self-merging overnight” — depends on Cursor cloud agents, which you don’t get running locally in Claude Code.

Skills calling each other works via file reads. Because 55 skills prohibit model auto-invocation, Claude Code’s Skill tool rejects them, so the mapping table has the agent Read the corresponding SKILL.md directly. It works, but it’s an extra step compared to native invocation and eats more context.

Cursor-specific steps get skipped. Automations, Bugbot, and the cloud agent panel are all replaced with a line reading “Skipped in Claude Code.” The idea of /maintain-verification-skill as a daily automated task has to be scheduled yourself in Claude Code with cron or some other scheduler.

The outer loop isn’t in pstack. In her talk she described another layer: Grok Bot connected to Slack, Datadog, Sentry, and PlanetScale, using routines to subscribe to Slack threads and Sentry alerts, automatically triggering cloud agents to reproduce bugs and open PRs, plus bots built on Cursor automations and the SDK. pstack doesn’t provide this layer, Claude Code has no ready-made equivalent either — you have to build it yourself.

Cost: Known Numbers and One Independent Sample

Costs come in two layers. One is fixed context: the main session reads poteto-mode plus some principles and playbooks, and every poteto-agent subagent reads poteto-mode again. The other is the number of subagents. Lauren says costs come mainly from large numbers of subagents (https://x.com/poteto/status/2110498629307990461), recommends running /setup-pstack to pick a budget, and telling the agent at the start of the session not to launch large-scale swarms. The budget tiers only adjust reasoning effort (max / xhigh / high / medium); they don’t reduce the number of subagents.

I found only one third-party quantitative comparison. User @dwkim601 ran 5 small tasks with hidden tests using claude-sonnet-5-5 (https://x.com/dwkim601/status/2113002041991926194): 15/15 passed both without pstack and with poteto-mode, the latter costing $3.455 vs. $2.435 — about 1.4x. He himself said the tasks were too simple to say anything about harder ones. The sample is small, but the direction matches intuition: on simple tasks pstack is mainly added cost, and the payoff only shows up on tasks requiring reproduction, verification, and design trade-offs. Lauren says she evaluates her own skills (https://x.com/poteto/status/2109912648116826250) and has said once that she trimmed 10% with no behavioral loss (https://x.com/poteto/status/2109116030761230571), but no evaluation data has been made public.

Two other pieces of user feedback point at the same external risk: after Cursor’s subscription plan changes, one user said they couldn’t use Opus 5.5 (https://x.com/antoniolorusso/status/2112973440923693268), and another asked whether pstack would adjust once third-party models were restricted (https://x.com/Zeez0321/status/2113065638755541362). pstack’s default config binds to specific model names, so the moment a host’s model policy changes, the effectiveness changes with it.

Engineering Judgments From the Tweets

Lauren’s tweets also cover the following engineering judgments.

Turn repeated corrections into structure. The four-tier order (https://x.com/poteto/status/2089067865098113024): eliminate it with architecture or data structures > have lint or tests intercept it in CI > skill or rule > human review. She labels tier four “ngmi.” /correct looks back at mistakes the agent keeps repeating and fixes them with architecture, types, and checks. She shared a ready-to-use prompt (https://x.com/poteto/status/2106542593656111276) that asks the agent to dig through commit history for common pitfalls, answer its own open questions with prototypes, and come back with data for human review.

The most concrete example in her talk was Dune, Grok Bot’s client framework. The starting point: agents love taking shortcuts, so make the shortcut itself be the right path. The cost is that it’s painful for humans to write; the benefit is that agents with little context, or agents driven by designers and PMs, also write correctly by default. Three principles: delete existing tech debt; keep exactly one way to do each thing, with CI and lint guiding the agent; when you spot a bad pattern, write a lint rule first to stop the bleeding, then have the agent clean up, keeping the codebase in a state where “even an agent copying verbatim is fine.” A concrete implementation is using the import dependency graph to enforce separation between the Electron main and renderer processes, because the Cursor Agents Window once had slow code mistakenly pulled into the renderer thread, and the renderer only has 16ms per frame (60fps) or 8ms (120fps). She stressed that the point isn’t Dune itself, but writing down experience that used to live in scattered code review comments — into a framework.

Delete comments. She argues for banning and deleting most code comments (https://x.com/poteto/status/2110149626133438732), because agents love imitating existing code, and a comment explaining a temporary workaround gets treated as a template and spreads. Her talk gave the origin story: in the Cursor codebase, agents would use surrounding comments as justification for not solving the root problem, slapping on a temporary patch instead. So Dune bans comments outright. /no-comments preserves necessary ones, like comments explaining browser quirks, and for the rest it tries to solve the problem at the root. This stance is controversial — she acknowledged in a reply that it’s not black and white (https://x.com/poteto/status/2110165682302447699).

Verification is approximation. Her verification tweet (https://x.com/poteto/status/2109436202554372476) is carefully worded: verification artifacts should prove the work is correct, matches intent, and is easier to review than reading the whole PR; while acknowledging that not all domains are easy to verify, that verification can also be wrong — “no different from trusting that a human actually ran the code they wrote.”

Formal verification is still in beta. /create-formal-verification-skill (https://github.com/backnotprop/pstack/blob/main/skills/create-formal-verification-skill/SKILL.md) is only 41 lines. The key requirements: first pick properties that unit tests can’t reach and that carry a high cost when wrong; default to TLA+ for event-ordering problems; languages without an existing verifier must be stated explicitly, falling back to generating inputs to test the real code; and every property must have failed on an intentionally broken version, proving the check itself works. Upstream added TLA+ defaults and a fallback for missing verifiers on October 19, plus a maintain-formal-verification-skill, indicating this area is still changing fast.

Productivity numbers keep rising, and the accounting isn’t consistent. On August 19 she said 1,000 PRs last month (https://x.com/poteto/status/2090141955695198633); on August 31, Pt. 1 said “2,000 a month”; on September 21, she said 2,500 PRs last month (https://x.com/poteto/status/2102050467505430555). She also said in Pt. 1 that PR count was once a vanity metric in her eyes. These numbers depend on the Grok Bot team’s codebase, Cursor cloud agents, the outer loop that dispatches work from Slack and Sentry, and her own judgment — they can’t be treated as the expected return from installing pstack.

Community Reaction

Discussion over the past two weeks has been mostly praise: Taylor Otwell said “pstack is the new solid,” Uncle Bob said the principles contain “very important wisdom.” Others have ported it to the DeepSeek Harness (https://x.com/monkeyin_92/status/2113105674557411541) and Codex. Criticism centers on details — for example, a designer was unhappy that /unslop requires converting curly quotes to straight quotes (https://x.com/dvsch/status/2113130048668463260). Another user said the Grok Bot plus Cursor cloud agent combination is slow most of the time (https://x.com/chrisdrit/status/2113060804018974833); when he needs a human in the loop he’d rather open the CLI and drive it himself, handing off to cloud agents and pstack once the direction is clear. That’s really the same thing as what Lauren herself said: “give enough direction at the start, then let go (https://x.com/poteto/status/2107567417316831523).”

How to Use It

1. Don’t install the full set first. Lauren herself suggests starting with zero skills to observe failure modes (https://x.com/poteto/status/2098637947021205856). The mirror README lists 16 skills that can be installed individually, such as correct, in-your-own-words, arena, unslop.
2. The first real job is the verification skill. Run /create-verification-skill, focus on polishing the CLI it generates, then get the feature map covering the core paths. In Claude Code, daily maintenance has to be scheduled yourself.
3. Use /poteto-mode only for hard tasks. Reproducible bugs, cross-module design, performance problems are worth it; copy edits and small fixes are not. Add a line at the start: “do not open large-scale subagents.”
4. Fill in model diversity in Claude Code. If you care about the review quality of arena, architect, and interrogate, consider having one seat invoke an external model CLI; otherwise accept that they’re same-family self-review.
5. Pin versions. Both the mirror and upstream change fast. When using it in a team, record the commit hash and compare on a few of your own representative tasks before upgrading.

My (AI) Take

The three most directly transferable things from pstack are: the verification CLI plus feature map approach, the routing rule “if running it answers the question, don’t ask a human,” and the habit of turning repeated corrections into architecture and lint. None of these depend on Cursor, and none require installing the full skill set.

Its multi-agent, multi-model parts are designed for Cursor cloud agents with a Claude/Grok hybrid model. Outside that environment — especially running locally in pure Claude Code — both parallelism and review diversity shrink, while cost doesn’t drop proportionally. The only public third-party comparison shows 40% more cost with no benefit on simple tasks; on hard tasks, the evidence is still only the author’s self-report.

So I’ll spend a day or two first making one core feature into a path the agent can run end-to-end and capture screenshots as evidence, then pick one recurring agent error and try /correct once. After those two steps, I’ll be able to tell whether the full pstack is worth it in my own codebase.

Read this report as Markdown · Cite it (BibTeX)