gstack: stos skilli opartych na rolach dla Claude Code

gstack to zestaw skilli Claude Code autorstwa Garry’ego Tana na licencji MIT, który dzieli pracę nad funkcją na role wywoływane jako komendy: /office-hours i /plan-ceo-review dla produktu, /plan-eng-review dla engineering managera, /review dla staff engineera, /qa dla QA i /ship dla release’u. Te same skille instalują się też w Codeksie i Cursorze. Dokumenty planistyczne gstack domyślnie trzyma poza repozytorium.

Otwierasz Claude Code z jednozdaniowym ticketem „Dodaj eksport faktur do CSV” i po 10 minutach masz działający przycisk. Potem zaczynają się pytania. Jakiego zakresu dat używa eksport? Co się stanie przy 80 000 wierszy? Czy ktoś sprawdził strefę czasową issued_at? Nikt nie zapytał, bo pusty prompt nie odgrywa żadnych ról: nie ma w nim product ownera, tech leada ani QA.

Ta strona jest dla programisty, który chce, żeby te role były odgrywane za każdym razem, bez zatrudniania ludzi i bez czytania każdej wygenerowanej linii. Przeprowadza jedną funkcję przez gstack od pomysłu do pull requesta, pokazuje plik, który zostawia po sobie każda rola, i zaznacza, gdzie nadal musisz wkroczyć sam.

Wersje na tej stronie

gstack jest na licencji MIT, a utrzymuje go Garry Tan. Sprawdzone 2026-09-26 na gstack 1.91.2.0 (plik VERSION; wpis w CHANGELOG z datą 2026-09-25): README, docs/skills.md, skrypt setup oraz pliki skilli office-hours, plan-eng-review, review, qa i ship z gałęzi main. Fakty o Claude Code dotyczą wersji 2.1.283 (kanał latest), o Codeksie — codex-cli 0.157.1. Popularność: 134,2 tys. gwiazdek i 20,0 tys. forków na garrytan/gstack, odczytane z GitHub API 2026-09-26 na potrzeby dossier badawczego o frameworkach. Gwiazdki mierzą uwagę, nie użycie, a gstack nie publikuje liczby instalacji.

Co daje przeprowadzenie jednej funkcji przez gstack

• Działającą instalację dla Claude Code, Codeksa lub Cursora i jedną flagę setupu, która usuwa kolizję nazw komend.
• Jedną funkcję — eksport CSV w aplikacji do fakturowania — doprowadzoną od pomysłu do otwartego pull requesta w siedmiu komendach.
• Tabelę, która przypisuje każdą rolę gstack do ogniwa łańcucha artefaktów, łącznie z dwoma ogniwami, których gstack w ogóle nie wytwarza.
• Cztery prompty do skopiowania: zawężone otwarcie /office-hours, przegląd inżynierski z twardymi ograniczeniami, przeniesienie prywatnych notatek gstack do plików zatwierdzonych w repozytorium i sprawdzenie dowodów przed wysyłką.
• Bramki, które dowodzą jakości wyniku bez czytania diffa, oraz pułapki, których nie znają starsze tutoriale.

Jakie role daje gstack?

gstack przedstawia swoje skille jako specjalistów, którzy działają w kolejności sprintu: Think, Plan, Build, Review, Test, Ship, Reflect. Każdy skill czyta to, co zapisał poprzedni. README wymienia ponad 30 komend; typową funkcję niesie tych dziewięć:

Rola	Komenda	Co robi	Co zostawia
Partner produktowy	/office-hours	Zadaje dociekliwe, niewygodne pytania o problem, podważa twoje założenia i proponuje dwa lub trzy podejścia z szacunkiem pracy	Design doc w ~/.gstack/projects/<repo>/
Founder lub CEO	/plan-ceo-review	Przegląda zakres w jednym z czterech trybów: rozszerzenie, rozszerzenie selektywne, utrzymanie zakresu lub redukcja	Decyzje o zakresie w ~/.gstack/projects/
Engineering manager	/plan-eng-review	Ustala architekturę, przepływ danych, tryby awarii i macierz testów, z diagramami	Przejrzany plan i plan testów w ~/.gstack/projects/
Potok przeglądów	/autoplan	Uruchamia po kolei przeglądy CEO, designu, developer experience i inżynierski, a pyta cię tylko o kwestie gustu	Te same pliki, przy mniejszej liczbie pytań
Staff engineer	/review	Szuka błędów, które przechodzą CI: zapytań N+1, wyścigów, granic zaufania, brakujących gałęzi enumów. Oczywiste naprawia, o resztę pyta	Poprawki na miejscu (oznaczone w raporcie jako [AUTO-FIXED]) i zapis przeglądu
Lider QA	/qa	Czyta diff, otwiera dotknięte strony w prawdziwej przeglądarce, naprawia to, co się psuje, i pisze test regresyjny do każdej poprawki	Raport w .gstack/qa-reports/ i nowe testy
Release engineer	/ship	Synchronizuje gałąź główną, uruchamia testy, audytuje pokrycie, aktualizuje dokumentację, pushuje i otwiera PR	Pull request z podsumowaniem pokrycia
Debugger	/investigate	Debugowanie od przyczyny źródłowej, które zatrzymuje się po trzech nieudanych poprawkach	Ustalenia w sesji
Engineering manager	/retro	Cotygodniowa retrospektywa z historii commitów, z trendem udziału testów	Snapshot JSON w .context/retros/

Domyślnie tylko jedna z tych ról jest twardą bramką: przegląd inżynierski. Review Readiness Dashboard w gstack oznacza go jako Required; przeglądy CEO i designu mają charakter informacyjny.

Zainstaluj gstack dla Claude Code, Codeksa lub Cursora

gstack wymaga Gita i Buna w wersji 1.0 lub nowszej, a na Windowsie także Node.js. To repozytorium Git ze skryptem setup, a nie marketplace wtyczek, więc /plugin marketplace add garrytan/gstack niczego nie instaluje.

1. Sklonuj repozytorium i uruchom setup dla swojego agenta (terminal):

   Claude Code

   git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
   cd ~/.claude/skills/gstack && ./setup --prefix

   --prefix instaluje każdy skill jako /gstack-<nazwa> (/gstack-review, /gstack-qa). Domyślnie nazwy są krótkie (/review, /qa), a w Claude Code 2.1.283 /review jest już aliasem wbudowanej komendy /code-review. Z prefiksem zawsze wiesz, którego recenzenta wywołałeś. Wrócisz do krótkich nazw przez ./setup --no-prefix. Dla czytelności dalsza część strony używa krótkich nazw; jeśli instalowałeś z prefiksem, dopisz gstack-.

   Zrestartuj Claude Code. Skille są na poziomie użytkownika, więc pojawią się w każdym projekcie.

   Codex

   git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/gstack
   cd ~/gstack && ./setup --host codex

   Setup generuje skille w formacie Codeksa do ${CODEX_HOME:-~/.codex}/skills/gstack-*/. Zrestartuj Codeksa, a potem wywołaj skill przez $, na przykład $gstack-office-hours, albo wybierz go z /skills. Skill drugiej opinii /codex nie istnieje w Codeksie; jego odpowiednikiem jest gstack-claude-code, który wymaga zainstalowanego i zalogowanego Claude Code. Jeśli Codex wypisze „Skipped loading skill(s) due to invalid SKILL.md”, wygenerowane opisy są nieaktualne: uruchom cd ~/gstack && git pull && ./setup --host codex.

   Cursor

   git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/gstack
   cd ~/gstack && ./setup --host cursor

   Setup zapisuje skille do ~/.cursor/skills/gstack-*/. Sposobu, w jaki Cursor je wyświetla i uruchamia, nie sprawdziliśmy ponownie na potrzeby tej strony, bo cursor.com był niedostępny 2026-09-26. Jeśli skilla nie ma w menu, poproś agenta o niego z nazwy („use the gstack-qa skill”).

2. Zdecyduj o hookach przed pierwszą sesją. Setup zapisuje hooki w ~/.claude/settings.json: domyślnie włączony hook Stop, który zamyka wpisy osi czasu sesji, hooki AskUserQuestion tylko wtedy, gdy się na nie zgodzisz, i sprawdzanie aktualizacji w SessionStart w trybie zespołowym. Hooki działają poza promptem uprawnień. Żeby pominąć hook osi czasu, uruchom ponownie ./setup --no-timeline-stop-hook; listę zarejestrowanych hooków pokaże ~/.claude/skills/gstack/bin/gstack-settings-hook list-sources. Przy pierwszym użyciu gstack pyta też o telemetrię, która pozostaje wyłączona, dopóki się nie zgodzisz.

3. Zmierz, co gstack dokłada do każdej sesji. Opisy skilli ładują się przy starcie, a treść skilla dopiero przy wywołaniu. gstack ma estymator działający offline (terminal):

   ~/.claude/skills/gstack/bin/gstack-context-bill ~/.claude/skills

   Wypisuje koszt stale obecny i koszt pojedynczego wywołania każdego skilla. Porównaj /context w świeżej sesji przed instalacją i po niej. W wersji 1.91.2.0 pliki skilli office-hours, review i ship mają po 70–85 KB, więc jedno wywołanie to duży prompt. Dla skali: uruchomiony 2026-09-26 na drzewie źródeł wersji 1.91.2.0 estymator pokazał 63 skille z około 25,7 KB frontmattera, czyli mniej więcej 6,6 tys. tokenów stale obecnych w kontekście (szacunek offline; --exact wymaga klucza API Anthropic). Wynik twojej instalacji zależy od tego, które hosty i skille podpiął setup. claude plugin details tu nie zadziała, bo gstack instaluje się jako skille, a nie jako plugin.

Ogólne zasady działania katalogów i zakresów skilli opisuje strona o instalowaniu i zarządzaniu skillami.

Przeprowadź jedną funkcję przez gstack, rola po roli

Projekt to aplikacja do fakturowania na Next.js App Router z Postgresem przez Prismę, testami jednostkowymi w Vitest i testami przeglądarkowymi w Playwright. Ticket: dział finansów chce eksportu faktur z wybranego zakresu dat do CSV. Pracuj na gałęzi funkcji; /qa i /review porównują zmiany z gałęzią główną.

1. Think: /office-hours. Zacznij od problemu, nie od przycisku. /office-hours ma dwa tryby. Tryb startupowy, przeznaczony dla założycieli i intraprenerów (osób budujących produkt wewnątrz firmy), zadaje sześć dociekliwych pytań o popyt, status quo i najwęższy klin wejścia. Tryb buildera, przeznaczony dla projektów pobocznych i hackathonów, generuje pomysły zamiast przesłuchiwać. Przy funkcji, o którą poprosili płacący klienci, poproś o tryb startupowy: to jego pytania sprawdzają, czy „eksport CSV” jest prawdziwą potrzebą. Skill podważa twoje ujęcie problemu, wypisuje założenia do przyjęcia lub odrzucenia i kończy się dokumentem projektowym (design doc), który czytają kolejne skille.

   Prompt do skopiowania: office hours dla prawdziwej funkcji

   /office-hours
   Feature for our existing invoicing app (Next.js App Router, Prisma, Postgres).
   Finance exports invoices to reconcile them in their accounting tool every
   month. Today they copy rows by hand from the invoices table. They asked for
   "a CSV export". Constraints: accounts can have 80,000+ invoices a year,
   amounts are stored in minor units with a currency column, issued_at is UTC,
   and finance works in Europe/Warsaw. Use startup mode: I am the
   intrapreneur here. Challenge whether CSV is the real need before proposing
   approaches, and keep anything beyond invoice export out of scope.

   Zaakceptuj design doc dopiero wtedy, gdy wskazuje użytkowników, rezultat i to, co jest poza zakresem. Tu jesteś product ownerem: to jedyny krok, którego gstack nie może zatwierdzić za ciebie.

2. Plan: /plan-eng-review. Przełącz Claude Code w tryb planowania (Shift+Tab albo /plan), pozwól mu naszkicować plan, a potem uruchom przegląd inżynierski. W trybie planowania skill sam bierze na warsztat aktywny plan i informuje o tym jednym zdaniem. Wymusza decyzje, które pusty prompt pomija: strumieniowanie czy buforowanie, granica stref czasowych, co robi częściowa awaria. Zapisuje plan testów, który później podejmie /qa. Użyj zamiast tego /autoplan, gdy chcesz mieć przeglądy CEO, designu i inżynierski w jednym przebiegu, a na wierzch tylko decyzje, które są kwestią gustu.

   Prompt do skopiowania: przegląd inżynierski z twardymi ograniczeniami

   /plan-eng-review
   Review the active plan for the invoice CSV export. Hold these as fixed:
   stream rows with a Prisma cursor instead of loading them into memory, cap an
   export at 12 months, convert date-range boundaries from Europe/Warsaw to UTC
   before querying, and format amounts from minor units per currency. I want a
   sequence diagram of the request, the failure modes (timeout mid-stream,
   client disconnect, empty range), and a test matrix that names the Vitest
   and Playwright test for each acceptance criterion.

3. Build: wyjdź z trybu planowania i zatwierdź plan. Claude Code go implementuje. gstack nie dodaje tu własnej roli; kontraktem jest plan.

4. Review: /review (albo /gstack-review). Mechaniczne poprawki nakłada od razu i każdą wypisuje w raporcie jako linię [AUTO-FIXED], a o wszystko niejednoznaczne, jak wyścig czy granica zaufania, pyta. Przy eksporcie CSV warte zgłoszenia są formula injection w komórkach zaczynających się od =, +, - lub @ oraz brakujący indeks na (account_id, issued_at). Jeśli przegląd nie wspomni o żadnym z nich, zapytaj o oba z nazwy. Po drugą opinię innego modelu sięgnij przez /codex, który wysyła ten sam diff do Codex CLI, jeśli masz go zainstalowanego i zalogowanego.

5. Test: /qa http://localhost:3000/invoices. Na gałęzi funkcji /qa działa w oparciu o diff: czyta zmiany, otwiera dotknięte strony w przeglądarce (w przeglądarce Aside, jeśli jest zainstalowana i otwarta na macOS 15+, w innym wypadku w Chromium zbudowanym przez setup), sprawdza je w działaniu, naprawia to, co się psuje, i do każdej poprawki pisze test regresyjny. /qa-only daje sam raport, bez zmian w kodzie.

6. Ship: /ship. Synchronizuje gałąź główną, uruchamia testy, buduje mapę pokrycia diffa, dopisuje testy tam, gdzie są luki, aktualizuje dokumentację przez /document-release, pushuje i otwiera PR z linią w rodzaju Tests: 42 → 47 (+5 new). Przed otwarciem PR sprawdza Review Readiness Dashboard. Jeśli brakuje przeglądu inżynierskiego, pyta, ale cię nie blokuje.

7. Reflect: /retro na koniec tygodnia. Czyta historię commitów i sygnalizuje udział testów poniżej 20%. Traktuj te liczby jako punkt wyjścia do rozmowy, a nie jako miarę wydajności.

Wdrożenie zostaje w twoim potoku. gstack ma też /land-and-deploy (merge, czekanie na CI i deploy, sprawdzenie zdrowia produkcji) i /canary (monitoring po wdrożeniu). Jeśli twój zespół wdraża wyłącznie przez CI, pomiń je i pozwól, żeby merge PR uruchomił potok.

Gdzie każda rola gstack trafia w łańcuchu artefaktów?

Łańcuch artefaktów wymaga na każdym etapie pliku zatwierdzonego w repozytorium (w commicie) zaakceptowanego przez konkretną osobę. gstack wytwarza większość treści, ale planistyczną połowę trzyma w ~/.gstack/projects/ na twoim komputerze, a nie w repozytorium. Członkowie zespołu, recenzenci i CI nigdy jej nie zobaczą, jeśli jej nie przeniesiesz.

Etap łańcucha	Artefakt	Rola gstack, która go wytwarza	Gdzie gstack go zapisuje	Co dokładasz ty
Plan	intent.md	/office-hours, /plan-ceo-review	Design doc w ~/.gstack/projects/	Commitujesz go; product owner go akceptuje
Design	spec.md	/plan-eng-review (kryteria akceptacji, macierz testów)	Plan testów w ~/.gstack/projects/	Commitujesz go; każde kryterium zamieniasz w nazwany test
Build	plan.md i diff	Plan Claude Code przejrzany przez /plan-eng-review	Plik planu, potem commity	Commitujesz zatwierdzony plan obok zmiany
Test	Dowody z testów	/qa oraz audyt pokrycia w /ship	.gstack/qa-reports/, nowe pliki testów	CI musi uruchamiać nowe testy; raport dołączasz do PR
Review	Ustalenia z przeglądu	/review, /codex	Poprawki na miejscu (oznaczone w raporcie jako [AUTO-FIXED]) i zapis przeglądu	Code owner czyta ustalenia, a nie cały diff
Maintain	Zapis incydentu, kolejna intencja	/investigate, /retro, /canary	Wynik sesji, .context/retros/	Zapis incydentu piszesz sam

Dwa ogniwa, których gstack w ogóle nie wytwarza, to intencja i specyfikacja zapisane w repozytorium oraz zapis incydentu; całą resztę wystarczy przenieść do repozytorium.

Prompt do skopiowania: przenieś notatki gstack do artefaktów w repozytorium

Find the most recent design doc and test plan that gstack wrote for this repo
under ~/.gstack/projects/ (the files matching *-design-*.md and
*-test-plan-*.md for the current branch). Copy them into
docs/features/invoice-export/ as intent.md and spec.md. In spec.md, rewrite
each acceptance criterion so it names the exact test file and test name that
proves it, and mark any criterion that has no test yet as MISSING. Do not
change the substance of either document. Show me the diff before committing.

Jak udowodnić wynik gstack bez czytania każdej linii?

gstack obiecuje, że role wyłapią to, co inaczej wyłapałbyś czytając kod. Zrób z każdej takiej obietnicy coś sprawdzalnego:

• Kryteria akceptacji jako testy. Po przeniesieniu planu testów każde kryterium wskazuje test. /ship dopisuje testy tam, gdzie brakuje pokrycia, a /qa dodaje test regresyjny do każdego naprawionego błędu. Uruchamia je CI, nie agent. Zobacz kryteria akceptacji, które da się sprawdzić testem.

• Bramka, która zatrzymuje turę. Opcjonalny gstack-verify-gate to hook Stop, który nie pozwala Claude Code zakończyć tury, dopóki twoja komenda weryfikacyjna nie przejdzie. Zadeklaruj komendę w CLAUDE.md, zaufaj jej raz na repozytorium, a potem zarejestruj hook (terminal, w katalogu głównym repozytorium):

  echo '<!-- gstack:verify: npm test -->' >> CLAUDE.md
  ~/.claude/skills/gstack/bin/gstack-verify-gate --trust
  ~/.claude/skills/gstack/bin/gstack-settings-hook add-event --event Stop \
    --command ~/.claude/skills/gstack/bin/gstack-verify-gate --source verify-gate

  Zmiana zadeklarowanej komendy unieważnia zaufanie, dopóki ponownie nie uruchomisz --trust. Po trzech zablokowanych próbach hook pozwala zakończyć turę z ostrzeżeniem, więc nie zapętla się w nieskończoność.

• Liczą się tylko świeże przeglądy. gstack ocenia każdy przegląd diffa jako CURRENT, STALE lub UNVERIFIED względem odcisku drzewa roboczego. Przegląd kodu, który potem się zmienił, się nie liczy, a /ship czyta tę samą ocenę.

• Dowody z testów związane z kodem, na którym powstały. gstack-evidence run --label unit -- npx vitest run opakowuje komendę testową, przepuszcza jej kod wyjścia i zapisuje, na jakim odcisku drzewa roboczego się wykonała. Podkomenda check ocenia każdą etykietę jako FRESH, STALE lub MISSING, a /ship powołuje się na świeże dowody zamiast ponownie uruchamiać testy. Zielony przebieg na wczorajszym kodzie się nie liczy.

• Dwa modele, jeden diff. /review działa na Claudzie, a /codex na Codeksie, więc mogą przeoczyć różne rzeczy. Najpierw czytaj ustalenia zgłoszone przez oba.

• Nazwany podpis. Ty akceptujesz design doc i przejrzany plan. Code owner merguje przy zielonym CI i rozwiązanych ustaleniach z przeglądu. Strona o pakiecie dowodów opisuje, co taki PR powinien zawierać.

Prompt do skopiowania: sprawdzenie dowodów przed wysyłką

Before /ship: list every acceptance criterion in
docs/features/invoice-export/spec.md with the test that proves it and the
result of its last run in this branch. Then show the /review findings that are
still open and the path of the latest /qa report. If any criterion has no
passing test or any finding is open, stop and tell me which, instead of
shipping.

Co się psuje przy wdrażaniu gstack?

Pułapki gstack (sprawdzone na 1.91.2.0 i Claude Code 2.1.283)

• /review znaczy dwie rzeczy. W Claude Code /review to alias wbudowanego /code-review, a instalacja gstack z krótkimi nazwami zajmuje tę samą nazwę. Instaluj przez ./setup --prefix i wpisuj /gstack-review.
• To nie jest wtyczka. /plugin marketplace add garrytan/gstack nic nie daje. Instaluj przez git clone i ./setup.
• Plan jest poza ewidencją. Dokumenty projektowe (design doc), plany CEO i plany testów leżą w ~/.gstack/projects/. Skopiuj je do repozytorium, bo inaczej następna osoba ma tylko diff.
• Hooki uruchamiają kod bez pytania. Setup domyślnie rejestruje hook Stop; hooki AskUserQuestion dodaje tylko wtedy, gdy je zaakceptujesz, a hook SessionStart — w trybie zespołowym. Ręczne usunięcie katalogu zostawia je w ustawieniach i sypią błędami przy każdym zdarzeniu. Usuwaj gstack przez ~/.claude/skills/gstack/bin/gstack-uninstall, a sekcje ## gstack i ## Skill routing usuń sam z CLAUDE.md każdego projektu: skrypt deinstalacji tego pliku nie rusza.
• /freeze to nie sandbox. Blokuje narzędzia Edit i Write poza jednym katalogiem; sed w Bashu nadal sięga wszędzie. Do prawdziwej izolacji użyj uprawnień i sandboksa.
• /ship może dodać CI. W repozytorium bez frameworka testowego instaluje go, pisze testy i tworzy workflow GitHub Actions. Przed mergem przejrzyj blok permissions: tego workflow.
• /cso potrafi po cichu odpuścić. Bez dodatkowego natywnego toolchainu zgłasza not assessed zamiast błędu.

Objaw	Przyczyna	Wyjście z sytuacji
Skille nie pojawiają się w Claude Code	Setup się nie zakończył albo sesja powstała przed nim	cd ~/.claude/skills/gstack && ./setup, potem restart. Jeśli nadal ich nie ma, sprawdź, czy istnieją linki ~/.claude/skills/gstack-* lub ~/.claude/skills/<nazwa> (ls ~/.claude/skills), i uruchom ./setup ponownie. Jeśli linki są, a Claude nadal twierdzi, że nie widzi skilli, dodaj do CLAUDE.md projektu sekcję ## gstack z README: wymienia ona skille, żeby Claude do nich kierował, ale ich nie rejestruje
Setup kończy się komunikatem „Not registered (a skill you own already uses the name)”	Masz własny skill qa/ albo ship/	Zmień nazwę swojego albo przejdź na ./setup --prefix, żeby nazwy przestały kolidować
/qa lub /browse nie działa na Linuksie albo Windowsie	Dołączony Chromium się nie zainstalował albo nie może wystartować	cd ~/.claude/skills/gstack && bun install && bun run build. Na Ubuntu 24.04+ z zablokowanymi przestrzeniami nazw użytkownika ustaw GSTACK_CHROMIUM_NO_SANDBOX=1
Sesja kolegi po obiedzie zachowuje się inaczej	Tryb zespołowy aktualizuje gstack przy starcie sesji, najwyżej raz na godzinę	Przy wspólnym repozytorium ustalcie, kto i kiedy robi aktualizację, najpierw czytajcie CHANGELOG i uruchamiajcie /gstack-upgrade świadomie
/office-hours zamienia małą funkcję w pitch produktu	Zbyt ogólne otwarcie zostawia mu swobodę szukania większego produktu, a tryb buildera wręcz szuka wersji „wow”	Wskaż użytkowników, ograniczenia i to, co jest poza zakresem, jak w prompcie powyżej; potem uruchom /plan-ceo-review w trybie utrzymania zakresu lub redukcji

Tryb zespołowy uruchamia kod z upstreamu w każdej sesji

./setup --team razem z gstack-team-init required czyni gstack obowiązkowym dla każdego, kto otworzy repozytorium, a każda sesja sprawdza aktualizacje. To wygodne, ale to też decyzja o łańcuchu dostaw: każdy commit z upstreamu trafia do hooków każdego programisty. Zanim to włączysz, przeczytaj stronę o bezpieczeństwie skilli i postaw na przeglądane aktualizacje w ustalonym rytmie zamiast cichych.

Kiedy gstack to właściwy framework?

Wybierz gstack, gdy chcesz wyrazistych ról z rozbudowanym QA w przeglądarce i automatyzacją release’u, a pracujesz głównie w Claude Code. Superpowers lepiej pasuje, gdy chcesz mniejszej, opartej na testach dyscypliny, która uruchamia się sama, a GSD — gdy twoim problemem jest utrata kontekstu w długim, wielofazowym projekcie. Dwa pakiety ról naraz dają dwie komendy /review i dwie opinie o procesie, więc wybierz jeden. Porównanie frameworków zestawia je obok siebie.

Dokąd dalej z gstack

Łańcuch artefaktów Pliki w repozytorium, które powinna zasilać każda rola gstack, i kto akceptuje każdy z nich.

Pakiety dyscypliny w porównaniu gstack obok skilli Pococka, addyosmani/agent-skills, Ponytaila i Everything Claude Code.

Skille do code review Wbudowane /code-review, wtyczki do przeglądów i jak uniknąć kolizji komend.

Pakiet dowodów Co powinien zawierać pull request, żeby recenzent mógł mu zaufać bez czytania każdej linii.