Workflowy pstack w Cursor i ich wdrożenie w zespole

Czym jest pstack i skąd pochodzi

pstack to plugin do Cursor opublikowany w repozytorium cursor/plugins na GitHubie na licencji MIT. Lauren Tan (poteto) pisze w README, że to te same skille, których na co dzień używa się w Cursor do wysyłania kodu, a celem jest pisanie mniej kodu, za to lepszego. 10 października 2026 manifest podawał wersję 0.15.15.

Instalujesz go poleceniem /add-plugin pstack w czacie Cursor albo z widoku Customize. Potem /setup-pstack wybiera modele, a /poteto-mode rozpoczyna pracę. Według skilla pomocy sama instalacja niczego nie zmienia, dopóki ktoś nie wywoła skilla.

• 27 skilli, w tym poteto-mode, setup-pstack, how, why, architect, arena, swarm i interrogate
• 23 playbooki wewnątrz poteto-mode, po jednym na rodzaj zadania
• 24 skille z zasadami, każdy z jedną regułą
• Dwóch subagentów: poteto-agent i Comment Sicko, recenzent komentarzy działający tylko w trybie odczytu
• Uśpiony pakiet automatyzacji benny dla zgłoszeń ze Slacka, który otwiera wyłącznie szkice pull requestów

README nazywa poteto-mode osobistym stylem Lauren Tan i zachęca do forkowania pluginu, a /automate-me przygotowuje własny tryb na podstawie twojej historii czatów. Dla zespołu większość pracy polega na ustaleniu, ile z tego stylu pasuje do twojego.

Workflowy pstack: jeden tryb i 23 playbooki

Punktem wejścia jest poteto-mode. Skill dopasowuje zadanie do jednego z 23 playbooków, otwiera listę zadań zaczynającą się od dosłownie skopiowanych kroków tego playbooka i wywołuje inne skille, gdy kroki ich potrzebują. Pominięte kroki zostają na liście z uzasadnieniem. Duże lub przekrojowe zmiany trafiają do skilla figure-it-out, który projektuje własny playbook i prowadzi dziennik decyzji.

Enter włącza poteto-mode dla jednej wiadomości, a Option+Enter lub Alt+Enter pozostawia go włączonym jako Custom Mode. Każdy playbook kodowy kończy się krokiem Opening a PR: git worktree, małe uporządkowane commity, oczyszczony diff, tytuł w formacie Conventional Commits i pull request od razu gotowy do review.

• Zrozumienie: Investigation, Runtime forensics i Trace forensics, które nie zmieniają kodu
• Zmiany w kodzie: Bug fix, Feature, Refactoring, Perf issue, Hillclimb i Visual parity
• Decyzje: Prototype i Multi-phase plan
• Merge i długie przebiegi: Babysit, Shipping, Autopilot-full, Autopilot-stack, Orchestrate i Autonomous run
• Utrzymanie: Authoring a skill, Eval, Session pickup, Pause safely i Worktree cleanup

Bug fix krok po kroku

Bug fix pokazuje schemat wspólny dla playbooków kodowych. Główny agent planuje i sprawdza, a subagenci badają problem i implementują poprawkę.

1. 1

   Odtwórz błąd

   Odtwórz defekt przez skill sterujący tam, gdzie występuje, i pytaj człowieka tylko z konkretnym powodem.

2. 2

   Znajdź przyczynę

   Odrzucaj hipotezy dowodami z działającego programu, aż zostanie jedna, i dodaj instrumentację, gdy stan jest niejasny.

3. 3

   Deleguj

   Jeśli poprawka przekracza granicę funkcji, najpierw uruchom architect, potem przekaż implementację subagentowi na modelu bug-fix.

4. 4

   Zweryfikuj

   Powtórz pierwotną reprodukcję na tej samej powierzchni. Wynik niejednoznaczny zostaje zgłoszony i nie liczy się jako zaliczony.

5. 5

   Uporządkuj commity

   Niezaliczająca reprodukcja lub test trafia do historii przed poprawką.

6. 6

   Otwórz pull request

   Uruchom Opening a PR i dołącz wynik sprzed poprawki i po niej.

Feature i refactoring

Feature uruchamia how, a potem architect, który równolegle bada warianty projektu i bez wyraźnej prośby o punkt kontrolny przechodzi od razu do implementacji. Gdy poprawnych kształtów jest kilka, delegacja przez arena jest obowiązkowa. Refactoring najpierw przypina zachowanie testem charakteryzującym, snapshotem albo harnessem równoważności, wprost nie uznaje do tego sprawdzania typów i lintu i cofa zmianę, która nie ułatwia czytania kodu.

Gdzie zatwierdza człowiek

Większość playbooków kodowych nie ma kroku akceptacji przed pull requestem, więc ocena twojego zespołu wchodzi przy review pull requesta. Hillclimb uzgadnia z tobą metrykę, Multi-phase plan czeka na zgodę operatora, a Autopilot-stack przekazuje sprawdzony stack, który operator sam merguje.

Babysit doprowadza pull request do gotowości do merge i nigdy go nie merguje. Shipping robi merge tylko na wyraźną prośbę, po tym jak agent, który nie pisał kodu, sprawdzi każdy pull request. Autopilot-full pozwala agentom-właścicielom zmergować po czystej weryfikacji agenta nadrzędnego, jeśli przyznano pełną autonomię. Tryb zatrzymuje się przy force-pushu na współdzielone branche, wdrożeniach, usuwaniu danych i wiadomościach do klientów, ale pisze na czacie zespołu i aktualizuje tickety bez pytania.

Reguła ról: który model co robi

pstack nie dostarcza pliku reguły. Pisze go /setup-pstack: skill wykrywa modele, których subagent może użyć w twojej sesji, pyta o jeden z czterech budżetów rozumowania od medium do max, przy czym xhigh odpowiada ustawieniom domyślnym, potwierdza każdą rolę i zapisuje zawsze stosowaną regułę w ~/.cursor/rules/pstack-models.mdc. Nie zapisuje modelu, którego nie potwierdził, a reguła działa w nowych czatach.

10 października 2026 ustawienia domyślne kierowały delegacje kodu, eksploratorów, badaczy i workerów swarm do grok-4.7-xhigh-fast, a ocenę, tekst, najtrudniejsze zmiany i syntezę do claude-opus-5-5-xhigh. Każdy wpis w panelu uruchamia jednego subagenta, a auto lub inherit-parent uruchamia rolę na modelu czatu.

---
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
...

Każda rola to subagent z własnym kontekstem. Dokumentacja Cursor mówi wprost: pięciu subagentów równolegle zużywa mniej więcej pięć razy więcej tokenów niż jeden agent, rozliczanych po cenie katalogowej danego modelu. Przewodnik pstack wymienia dźwignie: mniejszy budżet lub tańsze modele, auto dla części ról, krótsze panele i poteto-mode tylko tam, gdzie potrzebna jest ta dyscyplina.

Krótsze panele też kosztują, bo pstack sprawdza pracę dzięki różnorodności modeli. Skill interrogate daje jednemu recenzentowi na każdy skonfigurowany model ten sam diff i traktuje uwagi zgłoszone niezależnie przez dwa modele jako najmocniejszy sygnał, a Orchestrate uruchamia każdego weryfikatora na innej rodzinie modeli niż jego workera. Panel z jednym modelem oszczędza tokeny i traci tę kontrolę.

Dla zespołu ważne są dwa szczegóły. Plik leży w katalogu domowym każdej osoby, a kilka skilli czyta go właśnie stamtąd, więc jedna rewizja pluginu może używać różnych modeli na dwóch laptopach. Ustawienia domyślne zmieniły się też trzy razy między 11 września a 5 października 2026, a domyślne panele skurczyły się z czterech modeli do dwóch. Reguła zapisana przed zmianą zachowuje stare ustawienie, więc osoby, które zaczęły wcześniej, zostają przy starym panelu.

Równolegli agenci w Cursor: jak pstack rozdziela i sprawdza pracę

Cursor uruchamia subagentów równolegle, gdy agent wysyła naraz kilka wywołań Task. Dzielą oni checkout agenta nadrzędnego, chyba że każdy dostanie własny git worktree albo własne środowisko w chmurze, a /in-cloud wysyła kolejne zadanie do subagenta w chmurze. Przewodnik pstack nalega na tę izolację, bo agenci w jednym worktree nadpisują sobie nawzajem pracę.

Skill swarm rozdziela N workerów na wycinki albo zadeklarowany wyścig, domyślnie jako agentów w chmurze, i zwraca jeden raport. Skill arena daje N kandydatom to samo zadanie, sędzia w trybie odczytu ich ocenia, a potem wybierana jest baza i dołączane najlepsze elementy pozostałych. Skill architect uruchamia arena na szkicach projektu, a recenzenci interrogate w trybie odczytu dzielą uwagi na act on, consider, noted i dismissed, niczego nie wprowadzając.

Cięższe playbooki to mnożą. Shipping sprawdza każdy pull request osobnym agentem w chmurze, Autopilot-full uruchamia swarm ponownie po każdym pushu zmieniającym patch, a szablon Multi-phase plan wymaga dziesięciu ścieżek weryfikacji na żywo na pull request. Orchestrate utrzymuje około dziesięciu równolegle działających agentów podrzędnych na podkoordynatora.

To ustawienia domyślne pluginu. Zanim cięższe playbooki ruszą w twoich repozytoriach, ustal własne limity:

• Liczbę workerów swarm i ścieżek na żywo na pull request
• Wielkość paneli dla interrogate, arena i architect
• Które playbooki mogą działać, a które robić merge
• Budżety rozumowania, limity czasu i ponowień
• Jednego piszącego agenta na worktree lub branch
• Do których serwerów MCP mają dostęp agenci w chmurze i z jakimi danymi uwierzytelniającymi

Czego pstack oczekuje od Cursor, innych pluginów i serwerów MCP

pstack opiera się na elementach, których sam nie dostarcza. Część wymienia README, resztę widać w playbookach i skryptach.

• Funkcje Cursor: subagenci, subagenci w chmurze, Custom Modes, /loop i wbudowany skill create-skill
• Plugin cursor-team-kit: /deslop przed commitami, control-cli i control-ui do sprawdzania na żywo
• Serwery MCP, które skill why przypisuje do siedmiu kategorii dowodów, zgłaszając brakujące kategorie jako luki
• GitHub CLI lub Origin CLI, Bun dla skryptów watchera i orkiestracji oraz gt od Graphite dla Orchestrate
• Skill weryfikacyjny dla twojej aplikacji, który /create-verification-skill generuje i raz sprawdza
• Plan Cursor z przypisanymi modelami oraz Teams lub Enterprise dla zespołowego marketplace'u

Dwa punkty rodzą pytania o dostęp. Badacze why działają w trybie agenta, bo tryb tylko do odczytu odbiera dostęp do MCP, a skill jedynie zaznacza, że nie powinni niczego zapisywać. Subagenci w chmurze biorą serwery MCP z konfiguracji zespołu w Cursor, więc dane uwierzytelniające tylko do odczytu na tych serwerach są kontrolą, która naprawdę działa.

Forki wymagają jeszcze jednego sprawdzenia. Playbooki autopilot co godzinę czytają same siebie z trunka, a playbook planu uruchamia skrypt sprawdzający, w obu przypadkach przez ścieżki z układu cursor/plugins. W twoim repozytorium te ścieżki zadziałają tylko wtedy, gdy plugin leży w tym samym miejscu.

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>

Wdrożenie pstack w zespole

Traktujemy pstack jak każdą zależność, która zmienia drogę kodu do głównego brancha. Sprowadza się to do pięciu kroków.

1. 1

   Przypnij rewizję we własnym forku

   Zrób fork repozytorium, do czego zachęca README, i wyznacz właściciela lokalnych zmian. Zespołowe marketplace'y w Cursor, dostępne w planach Teams i Enterprise, mogą zaimportować twój fork, aktualizować się po przesunięciu śledzonego brancha i oznaczyć plugin jako Default Off, Default On lub Required. Kto instaluje pstack stamtąd, dostaje nową rewizję dopiero wtedy, gdy przesuniesz ten branch.

2. 2

   Przeczytaj playbooki z recenzentami

   Zanotuj, gdzie każdy playbook działa bez pytania, i zdecyduj, co pomijasz. Autopilot-full robi na przykład merge na podstawie werdyktu agenta, a poteto-mode pisze na czacie zespołu i aktualizuje tickety bez pytania.

3. 3

   Wbuduj własne polecenia i punkty akceptacji

   Zastąp ogólne sprawdzenia swoimi poleceniami build, test i CI, wygeneruj skill weryfikacyjny i dodaj zatrzymania tam, gdzie twój proces wymaga człowieka. Dostosuj konwencje, które różnią się od twoich, na przykład pull requesty od razu gotowe do review i tytuły według Conventional Commits.

4. 4

   Wybierz modele i limity na podstawie własnych wyników

   Uruchom określony zestaw zmian, które twój zespół już zmergował, przy dwóch lub trzech kandydackich regułach ról i wielkościach paneli. Porównaj poprawność, nakład na review, ponowienia i koszt na zaakceptowaną zmianę, a potem daj wszystkim ten sam plik reguły.

5. 5

   Przed każdą aktualizacją uruchom te same zadania

   Porównaj nową rewizję ze starą, łącznie z ustawieniami domyślnymi setup-pstack, i powtórz zestaw zadań, zanim przesuniesz śledzony branch. Tam, gdzie zmieniły się ustawienia domyślne, usuń nieaktualne linie ról albo uruchom /setup-pstack jeszcze raz.

Czego pstack nie wymusza

Playbooki, zasady i reguła ról to tekst w kontekście modelu. Dokumentacja Cursor mówi, że zastosowane reguły trafiają na początek tego kontekstu i że instrukcje dla AI nie powinny być twoją jedyną kontrolą bezpieczeństwa. Zasada pstack o współdzielonym stanie mówi to samo: instrukcje i konwencje nie są kontrolą współbieżności.

Granice leżą poza pluginem: w danych uwierzytelniających agenta, ochronie branchy, wymaganych akceptacjach i obowiązkowych testach w CI. Autopilot-full mówi, że agent nadrzędny nigdy nie udziela ani nie omija akceptacji wymuszanej przez twoją platformę Git, co pomaga tylko wtedy, gdy platforma jakąś wymusza. Babysit mówi, że nigdy nie robi merge, a jeśli token agenta może zmergować bez review, na drodze stoi tylko to jedno zdanie.

Dlatego najpierw sprawdź kontrole, a dopiero potem playbooki: wąskie uprawnienia tokenów, wymagane review i testy statusu na chronionych branchach i brak danych do wdrożeń w środowiskach agentów. Czy pstack poprawia wyniki twojego zespołu, pokaże dopiero pomiar na twoich własnych zadaniach.

pstack na tle innych pakietów workflow

Superpowers od Jesse'ego Vincenta i Prime Radiant prowadzi od burzy mózgów i spisanego planu do realizacji przez subagentów z TDD i code review. Plugin compound engineering przechodzi przez burzę mózgów, plan, pracę, upraszczanie i review, a wnioski zapisuje w docs/solutions. Spec Kit od GitHuba prowadzi od konstytucji projektu przez specyfikację, plan i zadania do implementacji. Wszystkie trzy są na licencji MIT, a dwa pierwsze wymieniają Cursor wśród obsługiwanych środowisk.

pstack wybiera jeden z 23 playbooków według rodzaju zadania i nie ma skilla do planowania. W README Lauren Tan pisze, że nie wierzy w planowanie, że najlepszą specyfikacją jest kod i że tryb planowania w Cursor dobrze współpracuje z pstack. Nacisk leży na dowodach z działającej aplikacji i na review przez kilka rodzin modeli, a sam pstack zależy od subagentów, Custom Modes i /loop w Cursor.

Przewodnik po spec-driven development

Jak pomagamy zespołom wdrożyć pstack

Czytamy rewizję pstack, której chcesz używać, spisujemy, czego wymaga, i przechodzimy przez playbooki z twoimi recenzentami. Wpinamy twoje polecenia i punkty akceptacji, pomijamy to, czego twoje zabezpieczenia nie obsługują, a przypisania modeli i limity pracy równoległej ustalamy na podstawie zmierzonych wyników i kosztów na twoich własnych zadaniach, które potem służą jako kontrola przed aktualizacją.

Szkolenia i warsztaty z pstack prowadzimy jako sesje zespołowe na twoich własnych repozytoriach, zdalnie lub na miejscu w Niemczech i w Polsce, po angielsku, niemiecku lub polsku. Nie prowadzimy otwartych kursów i nie wydajemy certyfikatów.

Doradztwo Cursor: wdrożenie pstackOcena zmian w workflow na twoim kodzieKoszty workflowów wieloagentowych