pstack-Workflows für Cursor und ihre Einführung im Team

Was pstack ist und woher es kommt

pstack ist ein Cursor-Plugin, veröffentlicht im Repository cursor/plugins auf GitHub unter der MIT-Lizenz. Lauren Tan (poteto) schreibt im README, dass dies die Skills sind, mit denen bei Cursor täglich Code ausgeliefert wird. Das Ziel ist, weniger und dafür besseren Code zu schreiben. Am 10. Oktober 2026 nannte das Manifest die Version 0.15.15.

Installiert wird es mit /add-plugin pstack im Cursor-Chat oder über die Ansicht Customize. Danach wählt /setup-pstack die Modelle, und /poteto-mode startet die Arbeit. Laut seinem Hilfe-Skill ändert die Installation allein nichts, solange niemand einen Skill aufruft.

• 27 Skills, darunter poteto-mode, setup-pstack, how, why, architect, arena, swarm und interrogate
• 23 Playbooks innerhalb von poteto-mode, je eines pro Aufgabentyp
• 24 Prinzip-Skills mit jeweils einer Regel
• Zwei Subagenten: poteto-agent und Comment Sicko, ein nur lesender Prüfer für Kommentare
• Das ruhende Automatisierungspaket benny für Fehlermeldungen aus Slack, das ausschließlich Draft-Pull-Requests öffnet

Das README nennt poteto-mode den persönlichen Stil von Lauren Tan und lädt dazu ein, das Plugin zu forken, und /automate-me entwirft einen eigenen Modus aus Ihrer Chat-Historie. Für ein Team besteht der größte Teil der Arbeit darin zu entscheiden, wie viel von diesem Stil zum eigenen passt.

Die pstack-Workflows: ein Modus und 23 Playbooks

Einstiegspunkt ist poteto-mode. Der Skill ordnet die Aufgabe einem von 23 Playbooks zu, legt eine To-do-Liste an, die mit den wörtlich übernommenen Schritten dieses Playbooks beginnt, und ruft weitere Skills auf, sobald ein Schritt sie braucht. Ausgelassene Schritte bleiben mit Begründung auf der Liste. Große oder übergreifende Vorhaben gehen an den Skill figure-it-out, der ein eigenes Playbook entwirft und ein Entscheidungsprotokoll führt.

Mit Enter gilt poteto-mode für eine Nachricht, mit Option+Enter oder Alt+Enter bleibt es als Custom Mode aktiv. Jedes Code-Playbook endet mit Opening a PR: ein Git-Worktree, kleine geordnete Commits, ein bereinigter Diff, ein Titel nach Conventional Commits und ein Pull Request, der sofort zum Review bereitsteht.

• Verstehen: Investigation, Runtime forensics und Trace forensics, die keinen Code ändern
• Code ändern: Bug fix, Feature, Refactoring, Perf issue, Hillclimb und Visual parity
• Entscheiden: Prototype und Multi-phase plan
• Merge und lange Läufe: Babysit, Shipping, Autopilot-full, Autopilot-stack, Orchestrate und Autonomous run
• Pflege: Authoring a skill, Eval, Session pickup, Pause safely und Worktree cleanup

Bug fix Schritt für Schritt

Bug fix zeigt das Muster, das die Code-Playbooks teilen. Der führende Agent plant und prüft, Subagenten untersuchen und setzen um.

1. 1

   Reproduzieren

   Den Fehler über einen Control-Skill dort reproduzieren, wo er auftritt, und einen Menschen nur mit konkreter Begründung fragen.

2. 2

   Ursache finden

   Hypothesen mit Laufzeitbelegen ausschließen, bis eine übrig bleibt, und bei unklarem Zustand Instrumentierung ergänzen.

3. 3

   Delegieren

   Überschreitet der Fix eine Funktionsgrenze, zuerst architect ausführen, dann die Umsetzung an einen Subagenten auf dem Bug-fix-Modell geben.

4. 4

   Verifizieren

   Die ursprüngliche Reproduktion auf derselben Oberfläche wiederholen. Ein unklares Ergebnis wird gemeldet und gilt nicht als bestanden.

5. 5

   Commits ordnen

   Die fehlschlagende Reproduktion oder den Test vor dem Fix in die Historie bringen.

6. 6

   Pull Request öffnen

   Opening a PR ausführen und die Ausgabe vor und nach dem Fix beifügen.

Feature und Refactoring

Feature führt how und dann architect aus, der Entwürfe parallel erkundet und ohne ausdrücklich gewünschten Checkpoint direkt in die Umsetzung übergeht. Sind mehrere Formen gültig, ist die Delegation über arena verpflichtend. Refactoring hält zuerst das Verhalten mit einem Charakterisierungstest, einem Snapshot oder einem Äquivalenz-Harness fest, lässt Typprüfung und Linting dafür ausdrücklich nicht gelten und nimmt eine Änderung zurück, die den Code nicht leichter lesbar macht.

Wo ein Mensch freigibt

Die meisten Code-Playbooks haben vor dem Pull Request keinen Freigabeschritt, also fließt das Urteil Ihres Teams im Review des Pull Requests ein. Hillclimb stimmt die Metrik mit Ihnen ab, Multi-phase plan wartet auf das Go des Operators, und Autopilot-stack übergibt einen geprüften Stack, den der Operator selbst mergt.

Babysit bringt einen Pull Request bis zur Merge-Bereitschaft und mergt nie. Shipping mergt nur auf ausdrückliche Bitte, nachdem ein Agent, der den Code nicht geschrieben hat, jeden Pull Request geprüft hat. Autopilot-full lässt Owner-Agenten nach sauberer Prüfung durch den Root-Agenten mergen, wenn volle Autonomie erteilt ist. Der Modus hält bei Force-Pushes auf geteilte Branches, Deployments, Datenlöschungen und Nachrichten an Kunden an, schreibt aber ohne Rückfrage in den Team-Chat und aktualisiert Tickets.

Die Rollenregel: welches Modell was übernimmt

pstack liefert keine Regeldatei mit. Die schreibt /setup-pstack: Der Skill ermittelt die Modelle, die ein Subagent in Ihrer Sitzung nutzen kann, fragt nach einem von vier Reasoning-Budgets zwischen medium und max, wobei xhigh den Voreinstellungen entspricht, bestätigt jede Rolle und legt eine immer angewendete Regel unter ~/.cursor/rules/pstack-models.mdc ab. Er schreibt kein Modell, das er nicht bestätigt hat, und die Regel gilt für neue Chats.

Am 10. Oktober 2026 schickten die Voreinstellungen Code-Delegationen, Explorer, Investigatoren und Swarm-Worker an grok-4.7-xhigh-fast und Urteil, Text, die schwierigsten Änderungen und Synthesen an claude-opus-5-5-xhigh. Jeder Eintrag in einem Panel startet einen Subagenten, und mit auto oder inherit-parent läuft eine Rolle auf dem Modell des Chats.

---
description: pstack per-role model choices (overrides skill defaults)
alwaysApply: true
---
# budget: large (xhigh)
feature, refactoring: grok-4.7-xhigh-fast
bug-fix: grok-4.7-xhigh-fast
judgment and prose: claude-opus-5-5-xhigh
hardest tasks: claude-opus-5-5-xhigh
interrogate reviewers: claude-opus-5-5-xhigh, grok-4.7-xhigh-fast
...

Jede Rolle ist ein Subagent mit eigenem Kontext. Die Cursor-Dokumentation sagt es deutlich: Fünf parallele Subagenten verbrauchen grob fünfmal so viele Tokens wie ein Agent, abgerechnet zum Listenpreis des jeweiligen Modells. Der pstack-Leitfaden nennt die Stellschrauben: ein kleineres Budget oder günstigere Modelle, auto für einzelne Rollen, kürzere Panels und poteto-mode nur dort, wo die Sorgfalt nötig ist.

Kürzere Panels haben ebenfalls einen Preis, denn pstack prüft über die Vielfalt der Modelle. Der Skill interrogate gibt einem Reviewer pro konfiguriertem Modell denselben Diff und wertet Befunde, die zwei Modelle unabhängig finden, als stärkstes Signal, und Orchestrate setzt jeden Verifier auf eine andere Modellfamilie als den zugehörigen Worker. Ein Panel mit einem Modell spart Tokens und verliert diese Prüfung.

Für ein Team sind zwei Details wichtig. Die Datei liegt im Home-Verzeichnis jeder einzelnen Person, und mehrere Skills lesen sie dort, sodass eine Plugin-Revision auf zwei Laptops unterschiedliche Modelle nutzen kann. Zudem änderten sich die Voreinstellungen zwischen dem 11. September und dem 5. Oktober 2026 dreimal, und die Standard-Panels schrumpften von vier Modellen auf zwei. Eine vor einer Änderung geschriebene Regel behält die alte Voreinstellung. Wer früh eingestiegen ist, behält also das alte Panel.

Parallele Agenten in Cursor: wie pstack Arbeit verteilt und prüft

Cursor führt Subagenten parallel aus, wenn der Agent mehrere Task-Aufrufe auf einmal sendet. Sie teilen sich den Checkout des Eltern-Agenten, es sei denn, jeder bekommt einen eigenen Git-Worktree oder eine eigene Cloud-Umgebung, und /in-cloud schickt die nächste Aufgabe an einen Cloud-Subagenten. Der pstack-Leitfaden besteht auf dieser Isolation, weil sich Agenten im selben Worktree gegenseitig überschreiben.

Der Skill swarm verteilt N Worker auf Ausschnitte oder ein vorab erklärtes Rennen, standardmäßig als Cloud-Agenten, und liefert einen einzigen Bericht. Der Skill arena gibt N Kandidaten denselben Auftrag, lässt einen nur lesenden Juror bewerten, wählt dann eine Basis und übernimmt die besten Teile der übrigen. Der Skill architect lässt arena über Entwurfsskizzen laufen, und die nur lesenden Reviewer von interrogate sortieren Befunde in act on, consider, noted und dismissed, ohne etwas anzuwenden.

Die schwereren Playbooks vervielfachen das. Shipping prüft jeden Pull Request mit einem eigenen Cloud-Agenten, Autopilot-full startet nach jedem Push, der den Patch ändert, erneut einen Swarm, und die Vorlage von Multi-phase plan verlangt zehn Live-Prüfspuren pro Pull Request. Orchestrate hält pro Sub-Koordinator rund zehn untergeordnete Agenten gleichzeitig in Arbeit.

Das sind die Voreinstellungen des Plugins. Bevor die schwereren Playbooks in Ihren Repositories laufen, legen Sie eigene Grenzen fest:

• Swarm-Worker und Live-Prüfspuren pro Pull Request
• Panelgrößen für interrogate, arena und architect
• Welche Playbooks laufen und welche mergen dürfen
• Reasoning-Budgets, Zeitrahmen und Wiederholungsgrenzen
• Ein schreibender Agent pro Worktree oder Branch
• Welche MCP-Server Cloud-Agenten erreichen und mit welchen Zugangsdaten

Was pstack von Cursor, anderen Plugins und MCP-Servern erwartet

pstack stützt sich auf Bausteine, die es nicht mitliefert. Einige nennt das README, den Rest zeigen Playbooks und Skripte.

• Cursor-Funktionen: Subagenten, Cloud-Subagenten, Custom Modes, /loop und der eingebaute Skill create-skill
• Das Plugin cursor-team-kit: /deslop vor Commits, control-cli und control-ui für Live-Prüfungen
• MCP-Server, die der Skill why sieben Belegkategorien zuordnet, wobei er fehlende Kategorien als Lücke meldet
• Die GitHub CLI oder die Origin CLI, Bun für die Watcher- und Orchestrierungsskripte und gt von Graphite für Orchestrate
• Ein Verifikations-Skill für Ihre Anwendung, den /create-verification-skill erzeugt und einmal prüft
• Ein Cursor-Plan mit den zugewiesenen Modellen und Teams oder Enterprise für einen Team-Marketplace

Zwei Punkte werfen Zugriffsfragen auf. Die Investigatoren von why laufen im Agentenmodus, weil der Nur-Lese-Modus den MCP-Zugriff entfernt, und der Skill hält lediglich fest, dass sie nichts schreiben sollen. Cloud-Subagenten beziehen ihre MCP-Server aus der Team-Konfiguration in Cursor, und Nur-Lese-Zugangsdaten auf diesen Servern sind daher die Kontrolle, die tatsächlich greift.

Forks brauchen eine weitere Prüfung. Die Autopilot-Playbooks lesen sich stündlich selbst aus dem Trunk nach, und das Plan-Playbook ruft ein Prüfskript auf, beides über Pfade aus dem Aufbau von cursor/plugins. Diese Pfade funktionieren in Ihrem Repository nur, wenn das Plugin an derselben Stelle liegt.

git show origin/main:pstack/skills/poteto-mode/playbooks/autopilot-full.md
git show origin/main:pstack/skills/poteto-mode/playbooks/autopilot-stack.md
node pstack/skills/poteto-mode/scripts/check-plan.mjs <plan.md>

pstack im Team einführen

Wir behandeln pstack wie jede Abhängigkeit, die verändert, wie Code in Ihren Hauptbranch gelangt. Das läuft auf fünf Schritte hinaus.

1. 1

   Eine Revision im eigenen Fork festlegen

   Forken Sie das Repository, wie es das README anregt, und benennen Sie einen Owner für lokale Änderungen. Team-Marketplaces in Cursor, verfügbar in den Plänen Teams und Enterprise, können Ihren Fork importieren, sich aktualisieren, wenn sich der verfolgte Branch bewegt, und das Plugin als Default Off, Default On oder Required kennzeichnen. Wer pstack von dort installiert, bekommt eine neue Revision erst, wenn Sie diesen Branch weiterschieben.

2. 2

   Die Playbooks mit Ihren Reviewern lesen

   Notieren Sie, wo jedes Playbook ohne Rückfrage handelt, und entscheiden Sie, was Sie weglassen. Autopilot-full mergt zum Beispiel auf das Urteil eines Agenten hin, und poteto-mode schreibt ohne Rückfrage in den Team-Chat und aktualisiert Tickets.

3. 3

   Eigene Befehle und Freigabepunkte einbauen

   Ersetzen Sie allgemeine Prüfungen durch Ihre Build-, Test- und CI-Befehle, erzeugen Sie einen Verifikations-Skill und ergänzen Sie Haltepunkte, wo Ihr Prozess einen Menschen verlangt. Passen Sie abweichende Konventionen an, etwa sofort reviewbereite Pull Requests und Titel nach Conventional Commits.

4. 4

   Modelle und Grenzen anhand eigener Ergebnisse wählen

   Lassen Sie eine abgegrenzte Auswahl bereits gemergter Änderungen unter zwei oder drei Kandidaten für Rollenregel und Panelgröße laufen. Vergleichen Sie Korrektheit, Review-Aufwand, Wiederholungen und Kosten pro akzeptierter Änderung, und geben Sie dann allen dieselbe Regeldatei.

5. 5

   Vor jedem Upgrade dieselben Aufgaben erneut ausführen

   Vergleichen Sie die neue Revision einschließlich der Voreinstellungen von setup-pstack mit der alten, und wiederholen Sie die Aufgaben, bevor Sie den verfolgten Branch weiterschieben. Wo sich Voreinstellungen geändert haben, löschen Sie veraltete Rollenzeilen oder führen /setup-pstack erneut aus.

Was pstack nicht erzwingt

Playbooks, Prinzipien und Rollenregel sind Text im Kontext des Modells. Die Cursor-Dokumentation sagt, dass angewendete Regeln am Anfang dieses Kontexts stehen und KI-Anweisungen nicht Ihre einzige Sicherheitskontrolle sein sollten. Das pstack-Prinzip zu geteiltem Zustand sieht es genauso: Anweisungen und Konventionen sind keine Steuerung der Nebenläufigkeit.

Die Grenzen liegen außerhalb des Plugins, in den Zugangsdaten des Agenten, in Branch Protection, erforderlichen Freigaben und verpflichtenden CI-Checks. Autopilot-full sagt, dass der Root-Agent keine Freigabe erteilt oder umgeht, die Ihre Git-Plattform erzwingt, und das hilft nur, wenn sie eine erzwingt. Babysit sagt von sich, nie zu mergen. Darf das Token des Agenten aber ohne Review mergen, steht nur dieser Satz im Weg.

Prüfen Sie also zuerst die Kontrollen und dann die Playbooks: enge Token-Rechte, verpflichtende Reviews und Status-Checks auf geschützten Branches und keine Deploy-Zugangsdaten in Agentenumgebungen. Ob pstack die Ergebnisse Ihres Teams verbessert, zeigt erst eine Messung an Ihren eigenen Aufgaben.

pstack im Vergleich mit anderen Workflow-Paketen

Superpowers von Jesse Vincent und Prime Radiant führt von Brainstorming und schriftlichem Plan zur Umsetzung durch Subagenten mit testgetriebener Entwicklung und Code-Review. Das Plugin compound engineering durchläuft Brainstorming, Plan, Umsetzung, Vereinfachung und Review und hält das Gelernte in docs/solutions fest. Spec Kit von GitHub führt von einer Projektverfassung über Spezifikation, Plan und Aufgaben zur Implementierung. Alle drei stehen unter der MIT-Lizenz, und die ersten beiden nennen Cursor unter den unterstützten Umgebungen.

pstack wählt nach Art der Aufgabe eines von 23 Playbooks und hat keinen Planungs-Skill. Im README schreibt Lauren Tan, nicht an Planung zu glauben, nennt Code die beste Spezifikation und merkt an, dass der Plan Mode von Cursor gut mit pstack zusammenarbeitet. Das Gewicht liegt auf Belegen aus der laufenden Anwendung und auf Review durch mehrere Modellfamilien, und pstack setzt die Subagenten, Custom Modes und /loop von Cursor voraus.

Leitfaden zu Spec-Driven Development

Wie wir Teams bei der Einführung von pstack unterstützen

Wir lesen die pstack-Revision, die Sie einsetzen wollen, listen auf, was sie voraussetzt, und gehen die Playbooks mit Ihren Reviewern durch. Wir binden Ihre Befehle und Freigabepunkte ein, lassen weg, was Ihre Kontrollen nicht abdecken, und legen Modellzuweisungen und Grenzen für parallele Arbeit anhand gemessener Ergebnisse und Kosten auf Ihren eigenen Aufgaben fest, die danach als Upgrade-Check dienen.

Schulungen und Workshops zu pstack finden als Team-Sessions in Ihren eigenen Repositories statt, remote oder vor Ort in Deutschland und Polen, auf Deutsch, Englisch oder Polnisch. Offene Kurse und Zertifikate bieten wir nicht an.

Cursor-Beratung: pstack einführenWorkflow-Änderungen am eigenen Code bewertenKosten von Multi-Agent-Workflows