Add pstack plugin

lauren tan's working style as a Cursor plugin. Bundles the poteto-mode
routing skill plus the workflow skills it routes through (how, why,
architect, arena, unslop, interrogate, automate-me, reflect, tdd) and
the full seventeen-skill set of first principles. Ships the poteto-agent
subagent that runs the same workflow end-to-end.

The why skill discovers available MCPs at run time and maps each to an
evidence category (source control, issue tracker, long-form docs,
real-time chat, infra observability, error tracking, analytics
warehouse). No third-party service integrations required.

cursor-team-kit's control-cli, control-ui, and deslop are referenced as
sibling-plugin dependencies for surfaces and commit cleanup; the kit
works standalone otherwise.

Marketplace entry registered at the root .cursor-plugin/marketplace.json.

Author: poteto

.cursor-plugin/marketplace.json

@@ -62,6 +62,11 @@
       "name": "orchestrate",
       "source": "orchestrate",
       "description": "Fan large tasks out across parallel Cursor cloud agents with planners, workers, verifiers, and structured handoffs."
+    },
+    {
+      "name": "pstack",
+      "source": "pstack",
+      "description": "if you want to go fast, go deep first. pstack helps you write less, but higher quality code. rigorous agent workflows you can parallelize with confidence."
     }
   ]
 }

pstack/.cursor-plugin/plugin.json

@@ -0,0 +1,30 @@
+{
+	"name": "pstack",
+	"displayName": "pstack",
+	"version": "0.1.0",
+	"description": "if you want to go fast, go deep first. pstack helps you write less, but higher quality code. rigorous agent workflows you can parallelize with confidence.",
+	"author": {
+		"name": "Lauren Tan"
+	},
+	"homepage": "https://github.com/cursor/plugins/tree/main/pstack",
+	"repository": "https://github.com/cursor/plugins",
+	"license": "MIT",
+	"keywords": [
+		"pstack",
+		"poteto-mode",
+		"workflow",
+		"principles",
+		"agent-style",
+		"subagents",
+		"unslop"
+	],
+	"category": "developer-tools",
+	"tags": [
+		"workflow",
+		"principles",
+		"review",
+		"planning"
+	],
+	"skills": "./skills/",
+	"agents": "./agents/"
+}

pstack/.gitignore

@@ -0,0 +1,3 @@
+node_modules/
+.DS_Store
+*.log

pstack/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Lauren Tan
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

pstack/README.md

@@ -0,0 +1,89 @@
+# pstack
+
+i'm [poteto](https://x.com/poteto). i'm not a president or ceo, but i've worked with millions of lines of code at Meta, Netflix, and Cursor. i'm also on the react core team where i help build and maintain react compiler.
+
+there's a growing sense that ai writes too much slop code. i agree. i don't want to ship like a team of twenty slop artists. throughput without quality is not a goal i aspire to. if you want to go fast, go deep first. 
+
+**pstack is my answer.** these are the same skills i use everyday to ship high quality code at Cursor. this turns cursor into a real engineering team. the goal is not to maximize loc, in fact it's the opposite. pstack helps you write less, but higher quality code.
+
+**pstack gives you fearless parallelism.** when you can go deep on one agent and trust it to write good, verifiable code, you can truly parallelize with confidence. start multiple agents up with `poteto-mode` and trust that they'll apply rigorous engineering principles to their work.
+
+**cursor gives you the best of all worlds.** every frontier model has its strengths and weaknesses. use any model with pstack. in fact, many of my skills use multi-model workflows.
+
+fork it. improve it. make it yours. PRs are welcome! 
+
+## install
+
+```bash
+/add-plugin pstack
+```
+
+## make it yours
+
+`poteto-mode` is my style. you may not want exactly that.
+
+type `/automate-me`. it mines your recent transcripts, drafts a `<your-name>-mode` skill from how you've actually worked, and routes through pstack underneath. you keep pstack as the base and end up with your own routing skill alongside `poteto-mode`.
+
+## usage
+
+use `/poteto-mode` at the start of a task. it reads your request, picks from a set of playbooks, and runs the other skills as the steps need them.
+
+### just use `/poteto-mode`
+
+this skill is the main shortcut. i use it whenever i need the agent to do real engineering work. it comes with six playbooks. investigation, bug fix, perf, feature, authoring a skill, and multi-phase plan. when invoked it:
+
+1. opens a todo list. the first item is reading `references/principles.md`.
+2. matches your task to a playbook and copies the steps in verbatim.
+3. routes to the other skills as the steps fire.
+4. writes unslopped replies.
+
+the full rules and playbooks live in `skills/poteto-mode/SKILL.md`.
+
+the rest are useful on their own when you know what you want:
+
+| skill | use it when |
+|---|---|
+| `/poteto-mode` | default entry point for any non-trivial task. |
+| `/how` | you want a walkthrough of how a subsystem works. |
+| `/why` | you want to know why something was built this way. discovers available MCPs at run time and queries each evidence category in parallel (source control, issue tracker, long-form docs, real-time chat, infra observability, error tracking, analytics warehouse). |
+| `/architect` | you're about to write code that crosses a function boundary and want the types and module shape settled first. |
+| `/arena` | you want N parallel attempts at the same thing, then to grab the best parts of each. |
+| `/interrogate` | you have a diff and want four different models to try to break it. |
+| `/automate-me` | you want your own `-mode` skill, drafted from how you've actually worked. |
+| `/reflect` | a long task landed and you want the recipe captured as a skill edit. |
+| `/tdd` | you're fixing a bug and there's a cheap local test path. write the failing test first, then the fix. |
+| `/unslop` | you're cleaning up writing. removes AI tells. |
+
+## the `poteto-agent` subagent
+
+pstack also ships a subagent that runs my style end to end. spawn it from a parent agent via `subagent_type: "poteto-agent"`. it reads `poteto-mode` and the principles in full before doing any work. substituting `generalPurpose` skips that read and drifts.
+
+`/poteto-mode` and `subagent_type: "poteto-agent"` route through the same wrapper.
+
+## principles
+
+seventeen short skills, one principle each. `poteto-mode` reads `references/principles.md` at task start. the standalone files are there so other skills can reference a principle by name.
+
+- core: laziness-protocol, foundational-thinking, redesign-from-first-principles, subtract-before-you-add, minimize-reader-load, outcome-oriented-execution, experience-first, exhaust-the-design-space.
+- architecture: boundary-discipline, make-operations-idempotent, migrate-callers-then-delete-legacy-apis, separate-before-serializing-shared-state.
+- verification: prove-it-works, fix-root-causes.
+- delegation: guard-the-context-window, never-block-on-the-human.
+- meta: encode-lessons-in-structure.
+
+## not shipped here
+
+a few things `poteto-mode` references but doesn't bundle:
+
+- `/deslop` and the `deslop` skill ship in the `cursor-team-kit` plugin.
+- `control-cli` (for CLIs and TUIs) and `control-ui` (for browser, Electron, web) ship in `cursor-team-kit` too.
+- `/babysit` and `/create-skill` are cursor built-ins.
+
+install `cursor-team-kit` alongside pstack if you want the full set.
+
+## why are there no planning skills?
+
+cursor already has a great plan mode which works great with pstack. but personally, i don't believe in planning. the best spec is code. if you do want to make a plan, `/poteto-mode` covers it, but it's not a default. 
+
+## license
+
+MIT

pstack/agents/poteto-agent.md

@@ -0,0 +1,11 @@
+---
+name: poteto-agent
+description: Routing target for `/poteto-mode` and any request for poteto's style. Resume an existing `poteto-agent` for the conversation rather than spawning a sibling. Reads the `poteto-mode` skill and its `references/principles.md` in full before any work. Substituting `generalPurpose` skips that read and drifts.
+---
+
+# Poteto subagent
+
+You are operating as poteto-mode's full agent style. Canonical instructions live in two files. Read both in full before doing any work.
+
+1. The `poteto-mode` skill's `SKILL.md`.
+2. The `poteto-mode` skill's `references/principles.md`.

pstack/skills/architect/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: architect
+description: "Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for /architect, 'architect this', 'design this', or non-trivial work where jumping to code would lock in the wrong shape."
+disable-model-invocation: true
+---
+
+# Architect
+
+Design before implementing. Sketch types, function signatures, class shapes, and module boundaries with `not implemented` bodies and pseudocode. Synthesize across multiple model perspectives, then fill in code against the chosen sketch. If implementation proves the sketch wrong, throw it out and redesign.
+
+## Start
+
+Open a todolist with one entry per phase before starting work. Autonomous mode without checkpoints needs the list to show phase position and keep phases from silently disappearing.
+
+1. Ground
+2. Sketch
+3. Agree
+4. Implement
+5. Scrap
+
+## Phase A: Ground the problem
+
+Build a real mental model of every system the new code touches. Run the **how** skill over the relevant subsystems. Critique mode if existing structure is the constraint or the design needs to push back on it.
+
+Naming a file isn't grounding. Produce the traced model `how` prescribes. If the design will redefine ownership or layering, also run the **why** skill on the existing shape so the rationale becomes a constraint, not a guess.
+
+Skip Phase A only when the work is genuinely greenfield with no surrounding system to integrate.
+
+## Phase B: Sketch
+
+Run the **arena** skill with the design-sketch task and the Phase A grounding artifacts as input. Pass `references/runner-prompt.md` as each runner's prompt. Each candidate produces a design package shaped per `references/rationale-template.md`: type sketch, function signatures, module map, and prose rationale.
+
+Use these slugs for the Phase B runners: `claude-opus-4-7-thinking-xhigh`, `gpt-5.3-codex-high-fast`, `gpt-5.5-high-fast`, and `composer-2.5-fast`.
+
+This is the **exhaust-the-design-space** principle skill made concrete. Whole-shape alternatives, not point fixes inside one shape.
+
+Arena returns one synthesized design package. The synthesis decision populates the rationale's "Synthesis decision" section.
+
+## Phase C: Agree (opt-in)
+
+Default: proceed directly to implementation with the synthesized design. No human checkpoint.
+
+Opt in to a checkpoint when the invoker explicitly asks: "/architect with checkpoint," "stop and show me before implementing," or similar. When opted in, surface the synthesized design and pause for sign-off before continuing.
+
+The synthesis can ship as its own commit either way. That's the "scaffold first" mode of the **foundational-thinking** principle skill; subsequent commits read as filling in bodies against a stable contract. Planned and scoped breakage during fill-in is fine, per the **outcome-oriented-execution** principle skill. For adversarial pressure on the design before implementing, run the **interrogate** skill on the synthesized sketch.
+
+If the human pushes back on the shape (in a checkpoint or after the fact), treat that as Phase A evidence. Re-ground and re-run Phase B before writing more code.
+
+## Phase D: Implement against the sketch
+
+Replace `not implemented` bodies with code, pseudocode with logic. The synthesized sketch is the contract.
+
+Deviations from the sketch are signal worth surfacing, not friction to absorb silently. If a function needs a parameter the sketch didn't anticipate, ask whether the sketch was wrong, the requirement was missed, or the implementation is overreaching. Surface it; don't bolt it on.
+
+## Phase E: Scrap when the architecture is wrong
+
+If implementation keeps producing friction the sketch can't absorb, throw the sketch out. Don't bolt fixes onto a wrong design, per the **redesign-from-first-principles** principle skill and the **fix-root-causes** principle skill.
+
+The signal is a *pattern*, not single instances. Tells:
+
+- The same shape of workaround appearing repeatedly across unrelated code.
+- Multiple unrelated edge cases that all need special-case branches.
+- Types that need escape hatches (`any`, casts, optional fields that are always set in practice) to compile.
+- The "we need a lock" reflex when the sketch said the state wasn't shared.
+- Callers having to know the abstraction's internal rules to use it.
+- Two or more independent Phase D deviations of the same shape across the implementation. Surfacing deviations is Phase D's job; a repeated pattern of them is Phase E's trigger.
+
+Use judgment. A few edge cases don't condemn an architecture. Some problems are legitimately complex, and complexity in the data is not the same as complexity in the design. The rewrite signal is repeated friction of the same shape, not single hard cases.
+
+When you do scrap:
+
+1. Re-run the **how** skill over what's been built. The implementation lessons enter the new design as inputs, not vibes.
+2. Redesign as if the new constraints had been day-one assumptions, per redesign-from-first-principles.
+3. Subtract before adding, per the **subtract-before-you-add** principle skill. The new sketch should be smaller than the old one before it grows.
+4. Return to Phase B and re-run arena.
+
+## Outputs
+
+One file with new types and signatures for small changes; the module map plus type definitions for larger work. The rationale ships alongside, shaped per `references/rationale-template.md`, including the synthesis decision.

pstack/skills/architect/references/rationale-template.md

@@ -0,0 +1,31 @@
+# Rationale template
+
+This is the prose that ships alongside the type sketch. One page. Sentence-case headings, no boilerplate. Replace the italic notes with the actual content.
+
+## Problem
+
+*One paragraph. What we're trying to do, and what about the existing system or constraints makes the shape non-obvious. If [Phase A](../SKILL.md#phase-a-ground-the-problem) surfaced constraints the design now has to honor (existing types we have to interop with, callers we can't break, invariants that crossed our boundary), name them here so the reader sees the same constraints you saw.*
+
+## Shape
+
+*The recommended architecture. Data structures first; then how data flows through the signatures. Name the load-bearing decisions: which invariants are encoded in types, where validation lives, what the system deliberately does not do. Cite the principle behind each decision (e.g., `per boundary-discipline`); don't restate it.*
+
+## Synthesis decision
+
+*Filled in by [arena](../../arena/SKILL.md). Records which candidate became the base and why, what was adapted from each of the others, and what was rejected and why.*
+
+## Tradeoffs accepted
+
+*One bullet per tradeoff the chosen shape makes. Form: "we accept X in exchange for Y." Name anything a future reader might mistake for an oversight, including things that look like premature optimization or premature simplification.*
+
+## Alternatives considered
+
+*Required. Name at least one concrete alternative shape, with one line on why it lost. Two or three when the design space had real contenders; one is fine when the constraints forced the answer, with the conclusion phrased as "this was the only viable shape because..." Avoid listing flavors of the same shape. Distinct from "Synthesis decision" above: this section is about design alternatives the chosen shape considered and rejected, not about other runner candidates.*
+
+## Open questions and risks
+
+*Things you noticed during the sketch that the human needs to weigh in on, and risks worth flagging before implementation starts. Phrase as questions, not assertions, so the human's answer is the resolution rather than a comment.*
+
+## Next implementation step
+
+*The first thing to build against the sketch. One sentence. The thing you'd start writing immediately after synthesis (or after Phase D sign-off, if a checkpoint was opted into).*

pstack/skills/architect/references/runner-prompt.md

@@ -0,0 +1,18 @@
+# Architect runner prompt
+
+The orchestrator passes this file through to every parallel candidate runner during Phase B. The orchestrator fills in the variable inputs around it: the task, the Phase A grounding artifacts, the isolated working directory, and the path to write outputs. The working directory is a git worktree when available, otherwise a per-runner subdirectory under the sketch dir; the property that matters is independence between candidates.
+
+You are producing one candidate design as part of architect's parallel exploration. Read the **architect** skill in full first; that's the workflow you're inside. Output a candidate design package: type sketch, function signatures, module map, and prose rationale shaped per [`rationale-template.md`](rationale-template.md).
+
+Apply the following discipline. The orchestrator compares candidates on these axes and uses them to pick a base.
+
+- Data structures first. Get the core types right and the code becomes obvious. Trace each dominant access pattern through the proposed structure; if the answer is "we'll add a map / index / cache later," the structure is wrong.
+- Shared state: if two actors might both write, ask "what happens?" If the answer isn't "nothing," default to per-actor state with a merge at the read boundary, per the **separate-before-serializing-shared-state** principle skill.
+- Make boundaries visible. `not implemented` errors for bodies, `// TODO` pseudocode for tricky logic, doc comments stating intent and invariants. A reader should trace data from input to output by reading types and signatures alone.
+- Encode invariants in types: hard-to-misuse types > runtime checks > prose comments, per the **encode-lessons-in-structure** principle skill.
+- Validate at boundaries, trust types inside, per the **boundary-discipline** principle skill. Business logic as pure functions; the shell stays thin.
+- Single source of truth per invariant. Derive instead of sync.
+- Idempotent state transitions where applicable, per the **make-operations-idempotent** principle skill. Ask what happens if the operation runs twice or crashes halfway.
+- Short call chains. If tracing the flow needs more than three files, flatten the hierarchy, per the **laziness-protocol** principle skill and the **minimize-reader-load** principle skill.
+
+You are one of four runners on different models. Produce the best design your model can make; don't hedge against the others. Differences between candidates are the signal used to pick a base and graft. Converging on a safe-looking middle defeats the exploration.