# What is poteto-mode in pstack?

> poteto-mode is the pstack router skill for Cursor. Describe a result and it picks a playbook, calls the other skills, delegates to models and verifies the work.

Author: [Flavio Copes](https://flaviocopes.com/about/) | Published: 2026-10-03 | Topics: [AI](https://flaviocopes.com/tags/ai/) | Canonical: https://flaviocopes.com/poteto-mode/

poteto-mode is the router skill of pstack, the Cursor plugin by Lauren Tan. You type `/poteto-mode` followed by the result you want. It picks one of 23 playbooks, copies that playbook's steps into the task list, calls the other pstack skills when a step needs them, hands the coding to subagents, and wants evidence before it tells you the work is done.

The name comes from Lauren's handle, [poteto](https://x.com/poteto). The plugin manifest lists her as the author, and the skill describes itself as "poteto's agent style". In the pstack README she writes that these are the skills she uses every day to ship code at Cursor.

My [deep dive into pstack](https://flaviocopes.com/pstack/) covers the whole plugin. Here we zoom in on the one command you'll type most.

## What happens when you run /poteto-mode?

Let's follow one request from start to finish:

```text
/poteto-mode the contact form sends two emails when you double-click Send. Reproduce it first, then fix it and verify.
```

1. It reads its principles. The skill file carries an index of 24 principle skills, like Laziness Protocol (the smallest change that solves the problem) and Prove It Works (check the real artifact). When a principle drives a decision, the agent opens that principle's full skill, and the final reply has to name the principle and the choice it changed.
2. It matches a playbook. A reported defect goes to Bug fix, new behavior to Feature, and a read-only question to Investigation. Large or cross-cutting work goes to the `figure-it-out` skill instead, even when Feature would fit, and so does any task no playbook fits. That skill designs a custom playbook for the task. A multi-day program with many stacked PRs goes to the Orchestrate playbook.
3. The playbook's steps go into the todo list word for word, before any task-specific item. If the agent skips a step, the step stays in the list with `skip: <reason>`, so you can see what it chose not to do.
4. Other skills run as the steps come up. Some triggers are fixed: a nontrivial change runs `/how` first, code that crosses a function boundary runs `/architect`, a contested design goes through `/interrogate`, and any prose goes through `unslop`.
5. The code goes to subagents. They run in the background, each with an explicit model for its role. The lead agent reviews the diff and writes its own summary instead of passing along what the subagent claimed.
6. Verification happens on the same surface where the problem showed up. For our double email, the Bug fix playbook wants the reproduction first, the cause confirmed with runtime evidence, and the same reproduction passing after the fix. "Inconclusive" is not a pass, and the reply pastes the failing and then the passing output.
7. The playbooks that change code end with a pull request. Their last step, the Opening a PR playbook, works from a [Git worktree](https://flaviocopes.com/git-worktrees/) off main, rebases into small ordered commits, uses a Conventional Commits title, and opens the PR ready for review, never as a draft. It uses the run's built-in PR tool when there is one, otherwise `gh`, or Cursor's Origin CLI when it's installed and can resolve the repository. Read-only playbooks like Investigation stop before that.

The reply has its own rules. It uses short sentences with no em dashes, and each claim either carries its evidence or says in the same sentence whether it was measured, inferred or guessed. `unslop` is one of the [anti-slop skills](https://flaviocopes.com/anti-slop/) I wrote about (here is [how to use the unslop skill](https://flaviocopes.com/unslop/)), and here it also cleans the agent's own replies.

poteto-mode doesn't stop to ask about reversible work, and external actions like updating a ticket or posting in team chat go ahead too. It always pauses before irreversible writes: a force-push to a shared branch, a deploy, deleting data, or a message to a customer.

The mode is also sticky. After the first `/poteto-mode`, plain follow-ups like `continue` or `do it` keep working inside the same playbook. Say `new task` to make it match a playbook again, and tell it when you want to leave the mode.

## Which playbooks can poteto-mode pick?

There are 23 of them as of October 2026:

| Playbook | Use it for |
| --- | --- |
| Investigation | A read-only question, answered with citations |
| Bug fix | Reproduce a defect, find the root cause, fix it |
| Perf issue | Trace a measured slowdown and beat a baseline |
| Hillclimb | Improve one metric over many measured attempts |
| Runtime forensics | Diagnose a live symptom like a leak, without fixing it |
| Trace forensics | Diagnose a captured profile or trace, without fixing it |
| Feature | New or changed behavior, built from a named data shape |
| Refactoring | Change the structure while the behavior stays pinned |
| Prototype | A throwaway sketch to settle a design or behavior question |
| Visual parity | A pixel-exact match between two UIs |
| Authoring a skill | Write or edit a SKILL.md |
| Eval | Test how a skill or prompt change affects agents |
| Babysit | Drive a PR or a stack to merge-ready |
| Shipping | Independently verify a green stack, then land the PRs that passed |
| Autonomous run | Drive one long task to a checkable finish |
| Orchestrate | A multi-day program with many stacked PRs |
| Autopilot-full | A queue of independent PRs, run until merged |
| Autopilot-stack | A queue built on autopilot, handed to you as one stack to review and land |
| Session pickup | Resume another agent's unfinished work |
| Pause safely | Stop cleanly so the work can resume later |
| Multi-phase plan | Write the plan for work that spans phases or stacked PRs, then stop |
| Worktree cleanup | Prune merged or abandoned worktrees and stale iOS simulators |
| Opening a PR | The last step of the playbooks that change code |

The skills it calls along the way are mostly part of pstack too:

- `how` traces how a subsystem works, without changing code.
- `why` looks for the reasons behind the code in Git history, PRs, and whatever sources your MCP servers reach.
- `architect` sketches types and signatures before any code gets written.
- `arena` runs several attempts at the same task and grafts the best parts into one.
- `swarm` fans a job out to parallel workers, as separate slices or as a race, and returns one report.
- `interrogate` has several models review a diff.
- `unslop` removes AI tells from prose.
- `technical-writing` shapes docs, PR descriptions and commit messages.
- `no-comments` strips comments before review, through the Comment Sicko subagent.
- `tdd` writes the failing test first when a bug has a cheap test path.
- `figure-it-out` designs a custom playbook for big or unmatched tasks.
- `show-me-your-work` logs every decision to a TSV file during long or unattended runs.

`/deslop`, which runs before each commit, and the `control-cli` and `control-ui` skills, which drive CLIs and TUIs, and browser or Electron UIs, ship in Cursor's separate `cursor-team-kit` plugin. Install it next to pstack for the complete workflow.

## What is poteto-agent?

pstack ships two subagents. Comment Sicko is the comment reviewer behind `no-comments`. The other one is `poteto-agent`, and it's the one poteto-mode uses.

It runs in the background. Its definition tells it to read poteto-mode's SKILL.md in full, principles index included, before doing any work, and to open a principle's full skill whenever it applies one. So a subagent writing code follows the same rules as the lead agent.

poteto-mode spawns `poteto-agent` for every subagent inside a playbook step. Skills that want different models for review, like `how`, `why`, `swarm` and `interrogate`, choose their own subagent types. You can also spawn it from any parent agent with `subagent_type: "poteto-agent"`. The README warns that a `generalPurpose` subagent in its place skips that first read and drifts from the style.

## How do I run poteto-mode in Cursor?

Install pstack from a Cursor chat:

```text
/add-plugin pstack
```

Then pick the models:

```text
/setup-pstack
```

Start a new chat so the model rule loads, and type `/poteto-mode` followed by your task.

Cursor never starts poteto-mode by itself, because the skill sets `disable-model-invocation: true`. You type the command the first time, and the mode keeps itself on from there.

## Does poteto-mode work in Claude Code or Codex?

The official pstack is a Cursor plugin. For other agents there's [pstack-claude](https://github.com/michael-denyer/pstack-claude), a community port by Michael Denyer. It tracks upstream, carries a few declared changes of its own, and packages the skills for Claude Code, Codex, Pi and other agents. Cursor doesn't maintain it.

In Claude Code, run:

```text
/plugin marketplace add michael-denyer/pstack-claude
/plugin install pstack@pstack-claude
```

In Codex, from the terminal:

```bash
codex plugin marketplace add michael-denyer/pstack-claude
codex plugin add pstack@pstack-claude
```

With the port, you start a task with a sentence like "Use poteto-mode to fix the search filter resetting when I change pages". In Claude Code the setup command becomes `/pstack:setup-pstack`.

Unlike the Cursor plugin, the port installs a routing hook, so in Claude Code and Codex poteto-mode can start by itself on bigger tasks, like a change across several files or a bug with an unknown cause. You can turn the hook off in setup-pstack. Codex asks you to trust it through `/hooks` before it runs.

Cursor is still the best fit, because it can mix Claude, GPT and Grok subagents on one task. The port gives each role its own model too, but in Claude Code they're all Claude models and in Codex they're all GPT models.

## Which models does poteto-mode use?

Out of the box, poteto-mode splits the work by role. Grok writes the code for Feature, Refactoring, Bug fix, Perf issue and Hillclimb, while Claude Opus 5.5 takes the hardest changes plus prose and judgment. Review panels mix Opus 5.5, GPT-5.6 Sol and Grok.

`/setup-pstack` changes any of that. It detects the models your account can use, asks for a reasoning budget (unlimited, large, medium or small), shows every role with its model, and writes the result to `~/.cursor/rules/pstack-models.mdc`, an always-applied rule that every pstack skill reads. A role with no line keeps its default.

That's how I set mine. Here are a few lines from my rule:

```text
feature, refactoring: cursor-grok-4.6-medium-fast
bug-fix: gpt-5.6-sol-high-fast
judgment and prose: claude-fable-5-thinking-xhigh
arena runners: claude-fable-5-thinking-xhigh, gpt-5.6-sol-high-fast, cursor-grok-4.6-medium-fast, claude-opus-5-thinking-high
```

Bug fixes go to Sol instead of Grok, and judgment and prose go to Fable. My arena line lists four models, and a panel role starts one subagent per entry, so my arenas run four candidates instead of three.

`auto` and `inherit-parent` aren't model names. Both run a role on the model of the parent chat, which is how you stay on Auto. If Cursor rejects a slug from the rule, skills like `/how`, `/arena` and `/interrogate` fall back to a default model and say so. The rule applies to new chats, so open one after every change.

## What should I ask poteto-mode to do?

Give it the result, plus a way to check it when that matters. Here are four prompts for a small web project.

A bug report lands in the Bug fix playbook:

```text
/poteto-mode the newsletter form says "Thanks for subscribing" even when the API returns a 500. Reproduce it in the browser, fix it, and show me both cases working.
```

A question lands in Investigation, and "don't change any code" keeps it there:

```text
/poteto-mode how does the build generate the search index? Don't change any code.
```

New behavior lands in Feature, and the finish condition tells it what to verify:

```text
/poteto-mode add a JSON feed at /feed.json with the 20 latest posts. Done means a test fetches it and finds 20 items, and /rss.xml stays byte-identical.
```

A measured slowdown lands in Perf issue, which starts from a trace and a baseline:

```text
/poteto-mode the /blog page takes 3 seconds to load in production. Trace it, find the cause, and show me the timing before and after.
```

Don't list skills in the prompt ("use /how, then /architect, then /arena"). The pstack guide calls that a pitfall, because the playbook already orders the steps and a hand-written sequence tends to drop some. Name a skill only to override one choice.

## When is poteto-mode a poor fit?

A one-line fix doesn't need it. A typo in a heading or a wrong config value takes one edit, while poteto-mode would still read its principles, copy a playbook and work toward a PR. The same goes for a question you can answer by opening one file.

The bigger cost is tokens. A Feature run can call `/how`, then `/architect`, which by default runs an arena of three candidates plus a separate judge, then a delegate that writes the code, and `/interrogate` with three more reviewers when the design is contested. With frontier models on every role, the bill grows fast. A smaller budget in `/setup-pstack`, or cheaper models on the code roles, keeps it under control.

It also assumes a team workflow with worktrees, pull requests and `gh`. If you push straight to main on a solo project, say so in the prompt. For small changes I prefer the shorter loop in [fstack](https://flaviocopes.com/fstack/), which keeps me close to each decision.

## poteto-mode vs calling /how or /architect directly

Every skill poteto-mode routes to also works as its own command.

`/how` on its own answers a question and stops. It doesn't touch the code, and it returns an overview, the key concepts, the runtime flow, where things live and the gotchas. `/architect` on its own grounds the problem with `/how`, sketches the design with an arena of models, and then implements it, unless you add `with checkpoint` to review the design first.

Neither one picks a playbook or opens a PR. poteto-mode does that part and calls `/how` and `/architect` at the step where they belong. It also stays on for the whole conversation.

I would call a single skill when I already know the one job I want: understanding some code before deciding anything, a design sketch, or a review of a finished diff with `/interrogate`. For "fix this" or "build this", `/poteto-mode` is the shorter prompt.

And if Lauren's style isn't yours, run `/automate-me`. It reads your recent Cursor transcripts and drafts your own `-mode` skill, which still routes through pstack underneath.