GSD: fazy z inżynierią kontekstu dla samodzielnych twórców

GSD Core, dawniej Get Shit Done, to otwartoźródłowy framework, który prowadzi Claude Code, Codex lub Cursora przez pętlę discuss, plan, execute, verify i ship dla każdej fazy roadmapy. Rozpoznanie, planowanie i kodowanie działają w subagentach ze świeżym kontekstem, a stan żyje w .planning/. Jako wtyczka Claude Code dodaje około 10 700 tokenów ładowanych w każdej sesji.

Budujesz w pojedynkę projekt po godzinach. Pierwszy wieczór z agentem idzie dobrze; trzeciego dnia sesja przeszła już dwie kompakcje, agent zapomniał, dlaczego padło na SQLite, a „gotowy” endpoint okazuje się zaślepką. Nie masz recenzenta i nie chcesz czytać 4000 linii wygenerowanego kodu, żeby ustalić, co działa.

Ta strona przeprowadza przez GSD jeden prawdziwy projekt, pokazuje, które pliki i bramki dowodzą, że dana faza działa, i mówi, ile framework kosztuje.

Wersje na tej stronie

Sprawdzone 2026-09-26 na @opengsd/gsd-core 1.14.0 (npm, opublikowane 2026-09-14) i 1.15.0 (opublikowane 2026-09-26), Claude Code 2.1.283 i codex-cli 0.157.1. Popularność: 9,9 tys. gwiazdek na GitHubie dla open-gsd/gsd-core; zarchiwizowany oryginał, gsd-build/get-shit-done, ma 64,5 tys. Oba odczyty z 2026-09-26. Gwiazdki mierzą uwagę, nie użycie.

Co dostajesz, przepuszczając jeden projekt przez GSD

• Działającą instalację dla Claude Code, Codex lub Cursora i pisownię poleceń w każdym z nich.
• Jeden monitor dostępności przeprowadzony od jednostronicowego briefu do otwartego pull requesta, z plikiem, który zapisuje każdy krok, więc sprawdzasz 40-liniowy plan, a nie 400-liniowy diff.
• Trzy prompty do skopiowania, warstwy weryfikacji uruchamiane przez GSD i job CI, dzięki któremu pull request sam się broni.
• Rachunek za tokeny i pięć ustawień, które go zmieniają.

Jak działa pętla faz w GSD?

GSD zakłada, że długa sesja degraduje się w miarę zapełniania kontekstu (context rot), więc główna sesja tylko orkiestruje. Każde ciężkie zadanie trafia do subagenta, który startuje z czystym kontekstem, zapisuje wynik do pliku w .planning/ i kończy pracę. Następny subagent czyta plik, a nie rozmowę. Mechanikę opisuje strona o tym, jak okna kontekstu się zapełniają i degradują.

Każda faza roadmapy przechodzi te same pięć kroków:

Krok	Polecenie (Claude Code)	Co się uruchamia	Plik, który powstaje	Twoja rola
Discuss	/gsd-discuss-phase 1	Adaptacyjne pytania o to, jak zbudować fazę	01-CONTEXT.md, 01-DISCUSSION-LOG.md	Odpowiadasz. Każda odpowiedź trafia do plannera
Plan	/gsd-plan-phase 1	Opcjonalny agent rozpoznania, potem planner, potem pętla plan-checkera	01-RESEARCH.md, 01-01-PLAN.md…, 01-VALIDATION.md	Czytasz plany, nie kod
Execute	/gsd-execute-phase 1	Subagenty wykonawcze w równoległych falach, jeden na plan, każdy commituje swoją pracę; na końcu weryfikator	01-01-SUMMARY.md…, 01-VERIFICATION.md	Nic, chyba że checkpoint o coś zapyta
Verify	/gsd-verify-work 1	Przejście przez widoczne dla użytkownika rezultaty, po jednym checkpoincie	01-UAT.md, plany poprawek, jeśli coś zawiedzie	Sprawdzasz każde zachowanie; wpisujesz pass albo opisujesz, co jest nie tak
Ship	/gsd-ship 1	Bramki wstępne, push, gh pr create z opisem zbudowanym z artefaktów	Pull request	Scalasz, gdy CI jest zielone

W Codex wpisz $gsd-discuss-phase 1 itd.; z pluginem: /gsd-core:discuss-phase 1.

Po pierwszej fazie projektu z następnej sekcji .planning/ wygląda tak:

• Folder.planning/

  • PROJECT.md co budujesz i dlaczego
  • REQUIREMENTS.md jeden identyfikator na funkcję, np. CHK-01
  • ROADMAP.md fazy, każda z celem i kryteriami sukcesu
  • STATE.md gdzie jesteś; przetrwa /clear i zamknięty laptop
  • config.json tryb, profil modeli, bramki
  • Folderresearch/

    • …
  • Folderphases/

    • Folder01-check-runner/

      • 01-CONTEXT.md twoje decyzje z discuss
      • 01-RESEARCH.md
      • 01-01-PLAN.md zadanie z poleceniem weryfikującym i warunkiem ukończenia
      • 01-02-PLAN.md
      • 01-01-SUMMARY.md co wykonawca zbudował i zacommitował
      • 01-02-SUMMARY.md
      • 01-VERIFICATION.md pokrycie wymagań według weryfikatora
      • 01-UAT.md wyniki twojego przejścia
      • 01-SECURITY.md zapisany przez /gsd-secure-phase

Cała wartość jest w tych plikach: są małe, domyślnie trafiają do repozytorium (planning.commit_docs: true) i każdy odpowiada na pytanie, na które inaczej trzeba by odpowiadać, czytając kod.

Zainstaluj GSD Core dla Claude Code, Codex lub Cursora

Paczka npm to @opengsd/gsd-core. Wersje 1.14.0 i 1.15.0 deklarują w polu engines Node.js 24 lub nowszy i npm 10 lub nowszy. Krok ship wymaga też zalogowanego GitHub CLI (gh).

1. Uruchom instalator w katalogu projektu (terminal). Bez flag zapyta o środowisko i zakres:

   npx @opengsd/gsd-core@latest

   Albo podaj je od razu:

   Claude Code

   npx @opengsd/gsd-core@latest --claude --local    # tylko ten projekt, w ./.claude/
   npx @opengsd/gsd-core@latest --claude --global   # każdy projekt, w ~/.claude/

   Zrestartuj Claude Code. Polecenia pojawią się jako /gsd-new-project, /gsd-plan-phase itd. Instalator zmienia też twój settings.json:

   • Hooki: sprawdzanie aktualizacji, strażnicy PreToolUse (prompt injection, odczyt plików z sekretami, destrukcyjne zapisy i inne) oraz monitor kontekstu.
   • Reguły zezwoleń dla Bash(npx gsd-core *) oraz dla Read i Edit na .planning/*.
   • Usunięte reguły deny: kasuje dokładnie reguły Read(.env), Read(.env.*) i Read(.secrets), także te dodane ręcznie, bo zastępuje je hook blokujący odczyt sekretów. Dodaj je z powrotem, jeśli polegają na nich inne narzędzia.

   Alternatywą jest natywna wtyczka:

   /plugin marketplace add open-gsd/gsd-core
   /plugin install gsd-core@gsd-core

   Polecenia wtyczki mają przestrzeń nazw /gsd-core:plan-phase, a sama wtyczka nadal potrzebuje binarki gsd-tools z paczki npm w PATH. Wybierz jedną drogę, nie obie.

   Codex

   npx @opengsd/gsd-core@latest --codex --global

   W testowej instalacji 1.15.0 72 skille trafiły do ~/.agents/skills/gsd-*/ (nie do ~/.codex/skills/, jak wciąż podaje przewodnik instalacji GSD), a 64 role agentów do ~/.codex/agents/; instalator ustawił hooks = true w sekcji [features]. Zrestartuj Codex i wpisuj $gsd-new-project, $gsd-plan-phase 1 itd. Przewodnik instalacji GSD podaje Codex CLI 0.130.0 jako minimum. W Codex GSD rejestruje tylko hook sprawdzający aktualizacje, więc ostrzeżenia o zapełnieniu kontekstu się nie pojawiają. Codex (0.157.1) uruchamia hook dopiero po zaufaniu mu, więc zatwierdź hook GSD, gdy Codex o to zapyta.

   Cursor

   npx @opengsd/gsd-core@latest --cursor --global

   Instalator zapisuje skille w ~/.cursor/skills/gsd-*/, a obok nich agentów. Zrestartuj Cursora i wpisz / w czacie agenta; wybierz pozycję gsd-help, jaką pokaże menu. Obsługi skilli po stronie Cursora nie sprawdzono ponownie dla tej strony, bo cursor.com był niedostępny 2026-09-26.

2. Sprawdź, czy polecenia są widoczne. W agencie uruchom pomoc (/gsd-help w Claude Code, $gsd-help w Codex, pozycja gsd-help z menu / w Cursorze). Jeśli jej brakuje, zajrzyj do tabeli naprawczej na końcu strony.

3. Zanim uruchomisz pierwsze execute, ustal politykę uprawnień. Reguły zezwoleń GSD obejmują jego własne pliki, ale subagenty wykonawcze wywołują też git add, git commit i twoje testy. Na kanale latest Claude Code (v2.1.283) sesje interaktywne startują w trybie auto na obsługiwanych modelach, o ile ustawienia go nie wyłączają. W trybie Manual dodaj reguły, np. Bash(git add *) i Bash(git commit *), do .claude/settings.local.json zamiast flagi --dangerously-skip-permissions, którą proponuje przewodnik użytkownika GSD. Zobacz uprawnienia i sandboxing dla agentów.

Pułapki GSD ze starych tutoriali (sprawdzone na 1.14.0 i 1.15.0)

• npx get-shit-done-cc instaluje paczkę, którą npm oznacza jako „Package no longer supported” (ostatnia wersja 1.42.3). Oryginalne repozytorium zarchiwizowano 2026-06-26. Paczki npm get-shit-done i gsd nie mają z nim związku. Używaj @opengsd/gsd-core.
• „GSD 2” też się przeniosło: samodzielny agent to @opengsd/gsd-pi (1.20.1), a nie przestarzałe gsd-pi.
• Pisownia poleceń zależy od drogi instalacji: /gsd-plan-phase (instalator npm, Claude Code), /gsd-core:plan-phase (wtyczka), $gsd-plan-phase (Codex). Komunikaty samych workflow GSD wciąż wypisują starszą formę /gsd:plan-phase. Wpisuj to, co pokazuje twoje menu /.
• GSD Core to fork społeczności, ogłoszony po braku kontaktu z pierwotnym opiekunem od 2026-04-01. Przypnij wersję (@opengsd/gsd-core@1.15.0) i czytaj informacje o wydaniu przed aktualizacją.
• --config-dir nie zamyka instalacji dla Codex w jednym katalogu: skille i tak trafiają do ~/.agents/skills/, a domyślne ustawienia środowiska do ~/.gsd/. Zamiast tego testuj GSD na osobnym koncie użytkownika albo w kontenerze.

Przeprowadź jeden projekt przez GSD, faza po fazie

Projekt to pingboard, samodzielnie hostowany monitor dostępności: API na Fastify w TypeScripcie, które według harmonogramu sprawdza adresy URL, zapisuje wyniki w SQLite i wysyła e-mail, gdy sprawdzenie zawiedzie dwa razy z rzędu. Trzy fazy: uruchamianie sprawdzeń i zapis, API HTTP, alerty. Ta sekcja prowadzi fazę 1 aż do pull requesta.

1. Napisz brief, który GSD przetworzy. /gsd-new-project --auto @file.md wyciąga projekt z dokumentu zamiast przeprowadzać z tobą wywiad. Niech agent przygotuje szkic, a potem popraw go sam: dziedziczy go każdy późniejszy subagent.

   Prompt do skopiowania: brief, z którego GSD zrobi roadmapę

   Write docs/prd.md for a project called pingboard. Keep it under 80 lines.
   
   Product: a self-hosted uptime monitor for one developer. Fastify 5 API in
   TypeScript, SQLite through better-sqlite3, Vitest for tests, Node 24.
   
   Sections, in this order:
   1. Problem: two sentences.
   2. Users: one persona.
   3. Requirements: numbered, each one observable from outside the process
      (an HTTP response, a row in the database, an email sent). Give each an ID
      with a CHK-, API- or ALR- prefix.
   4. Out of scope: at least five items (auth, multi-user, dashboards, SMS,
      distributed checks).
   5. Constraints: no external services except SMTP; every check result is
      persisted; a failing check alerts only after two consecutive failures.
   6. Suggested phases: check runner and storage, HTTP API, alerting.
   
   Do not write code. Do not invent requirements I did not ask for; list open
   questions at the end instead.

2. Utwórz projekt (prompt w agencie):

   /gsd-new-project --auto @docs/prd.md

   Po kilku pytaniach konfiguracyjnych --auto bez zatrzymywania się przeprowadza rozpoznanie, spisuje wymagania i układa roadmapę. Ponieważ nic nie czeka na twoją akceptację, otwórz ROADMAP.md, zanim pójdziesz dalej: każda faza potrzebuje celu i kryteriów sukcesu, które da się zaobserwować. Kryterium w rodzaju „harmonogram jest odporny” nie sprawdzi nikt; „sprawdzenie, które po 5 s przekroczy limit czasu, zapisuje się ze statusem timeout” sprawdzi weryfikator i ty.

3. Wyczyść sesję i omów fazę 1:

   /clear
   /gsd-discuss-phase 1

   GSD pyta o decyzje implementacyjne: rozdzielczość interwałów, co liczy się jako awaria, jak zapisywać czasy odpowiedzi. Odpowiadaj konkretnie; --assumptions pokazuje, co agent założyłby zamiast tego, co szybko ujawnia pytania, które mają znaczenie. Odpowiedzi trafiają do 01-CONTEXT.md.

4. Zaplanuj fazę 1 z testem, który najpierw nie przechodzi, dla każdego zachowania:

   /gsd-plan-phase 1 --tdd

   Planner zamienia 01-CONTEXT.md na małe plany, a plan-checker wraca z nim do pracy, dopóki każdy plan nie trafia w cel. --tdd sprawia, że każde zadanie dodające zachowanie startuje od czerwonego testu; --skip-research przy znanym stosie oszczędza agenta rozpoznania.

5. Przejrzyj plany, zanim cokolwiek się uruchomi. Każdy PLAN.md zawiera zadania z plikami, których dotykają, krokami, poleceniem <verify> i warunkiem ukończenia. To najtańsze miejsce na wyłapanie złej decyzji.

   Prompt do skopiowania: przegląd planu GSD przed wykonaniem

   Read .planning/ROADMAP.md, .planning/phases/01-check-runner/01-CONTEXT.md
   and every 01-*-PLAN.md in that folder. Do not change any file.
   
   Report, as a table with one row per task:
   - the requirement ID it serves (flag any task that serves none)
   - its <verify> command, and whether that command can fail if the task
     is done wrong (flag any verify that only checks a file exists or that
     the build passes)
   - any decision in 01-CONTEXT.md the task contradicts
   
   Then list every requirement mapped to phase 1 that no task covers.
   End with GO or NO-GO and one sentence of reasoning.

   Przy NO-GO popraw 01-CONTEXT.md albo uruchom ponownie /gsd-plan-phase 1, nazywając lukę w prompcie. Nie edytuj planów ręcznie w nadziei, że wykonawca się zgodzi.

6. Wykonaj:

   /clear
   /gsd-execute-phase 1

   Niezależne plany idą w równoległych falach (domyślnie do 3 wykonawców), każdy ze świeżym kontekstem, każde zadanie w osobnym commicie. Potem weryfikator sprawdza kod względem wymagań fazy i zapisuje 01-VERIFICATION.md. Checkpoint zatrzymuje przebieg tylko przy ludzkiej decyzji, np. o nieodwracalnej zmianie schematu.

7. Przejdź przez rezultaty:

   /gsd-verify-work 1

   GSD zamienia każdy SUMMARY.md w sprawdzenia widoczne dla użytkownika, po jednym: „Dodanie https://example.com z interwałem 30 s zapisuje wiersz z wynikiem w ciągu 35 s”. Wpisz pass albo opisz, co jest nie tak. Przy porażce pisze plany poprawek dla /gsd-execute-phase 1 --gaps-only.

8. Zamknij bramkę bezpieczeństwa i wypuść fazę (ship):

   /gsd-secure-phase 1
   /gsd-ship 1

   Ship sprawdza swoje bramki (weryfikacja passed, zero otwartych zagrożeń, czyste drzewo; patrz następna sekcja), potem wypycha gałąź i otwiera pull request zbudowany z artefaktów fazy.

Kroki od 3 do 8 powtórz dla faz 2 i 3; /gsd-progress powie ci, gdzie jesteś. W istniejącym kodzie zacznij od /gsd-onboard. Przy jednorazowej zmianie /gsd-quick "fix the timeout parsing" zachowuje atomowe commity i stan, ale pomija opcjonalnych agentów.

Skąd wiesz, że faza GSD naprawdę działa?

GSD automatyzuje roadmapę, planowanie, wykonanie, pokrycie wymagań i pull request. Po twojej stronie zostaje osąd: obserwowalne kryteria, lektura planów, UAT i scalenie. GSD ustawia pięć kontroli i żadna nie wymaga czytania diffa:

1. Plan-checker. Każdy plan jest sprawdzany względem celu fazy przed wykonaniem; nie wyłączaj go flagą --skip-verify.
2. Polecenia weryfikujące w zadaniach. Polecenie <verify> każdego zadania uruchamia się po tym, jak wykonawca napisze kod. Z --tdd pierwszy przebieg jest celowo czerwony.
3. Weryfikator. 01-VERIFICATION.md przypisuje każdemu wymaganiu fazy dowód. Weryfikator zapisuje odcisk plików objętych werdyktem, więc późniejsza edycja któregoś z nich zmienia wynik na stale.
4. UAT. /gsd-verify-work to jedyna kontrola, która potrzebuje ciebie: sprawdzasz zachowanie, a GSD zapisuje wynik w 01-UAT.md.
5. Bramki ship. W 1.14.0 i 1.15.0 weryfikacja musi mieć status passed (nie stale), a przy domyślnym workflow.security_enforcement: true plik SECURITY.md fazy musi mieć threats_open: 0. Drzewo robocze musi być czyste.

Wszystkie pięć działa w agencie, który napisał kod. Dodaj kontrolę spoza niego: CI na pull requeście, z czystego checkoutu, bez sekretów i z dostępem tylko do odczytu:

.github/workflows/pr-gate.yml

name: pr-gate
on: pull_request
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - uses: actions/setup-node@v7
        with:
          node-version: 24
      - run: npm ci
      - run: npx tsc --noEmit
      - run: npx vitest run

Więcej niezależności daje /gsd-code-review 1 --depth=deep, które przed UAT przegląda pliki zmienione w fazie, a przegląd pull requesta przez agenta dokłada spojrzenie drugiego modelu. Akceptacja zostaje przy tobie. W zespole opis pull requesta napisany przez GSD to gotowa paczka dowodów dla recenzenta.

Prompt do skopiowania: sprawdź dowody przed wypuszczeniem fazy

Phase 1 of this project is about to ship. Do not change any file.

1. Read .planning/REQUIREMENTS.md and list every requirement mapped to
   phase 1 in ROADMAP.md.
2. For each one, find the test that proves it (file and test name). Run
   `npx vitest run` and report whether that test passed.
3. Compare with .planning/phases/01-check-runner/01-VERIFICATION.md and
   01-UAT.md. Flag any requirement that VERIFICATION.md marks as covered
   but has no automated test, and any UAT item recorded as pass that
   contradicts a failing test.
4. Report requirements with no evidence at all.

Answer with a table, then SHIP or HOLD.

Ile GSD kosztuje w tokenach?

GSD wydaje kontekst w trzech miejscach i każde wymaga innej poprawki.

Koszt stały. Na Claude Code 2.1.283 claude plugin details gsd-core@gsd-core szacuje około 10 700 tokenów w każdej sesji: 144 skille, 64 agentów i 7 hooków, zmierzone na wtyczce 1.14.0. Superpowers wychodzi około 838, a Everything Claude Code około 41 515. Duża część to duplikaty: wtyczka dostarcza i plan-phase, i gsd-plan-phase, a instalator npm zapisuje jedną formę każdego polecenia (72 skille). Zmierz własną instalację:

claude plugin details gsd-core@gsd-core   # terminal, tylko droga przez wtyczkę

Przy instalacji przez npm uruchom /gsd-surface status (włączone skille z podsumowaniem tokenów) albo porównaj /context w świeżej sesji przed instalacją i po niej. codex-cli 0.157.1 nie ma odpowiednika details (codex plugin oferuje tylko add, list, marketplace i remove), więc tam porównaj wskaźnik kontekstu w świeżej sesji.

Żeby skrócić listę bez utraty pętli, wyłącz klastry skilli, których nie używasz, np. /gsd-surface disable ui albo /gsd-surface disable ai_eval; polecenie przestawia skille na miejscu, bez ponownej instalacji. Flaga instalatora --minimal tnie mocniej (jej tekst pomocy szacuje około 700 tokenów zamiast około 12 000), tyle że w 1.14.0 i 1.15.0 ani profil core, ani standard nie zawiera ship ani secure-phase, więc znika razem z nimi krok 8 z tego przewodnika.

Koszt wywołania. Treść skilla jest mała (około 1,8 tys. tokenów dla gsd-plan-phase), ale skill dołącza przez @ plik workflow do twojej głównej sesji: w 1.15.0 około 96 KB dla workflows/plan-phase.md i 91 KB dla execute-phase.md. Stąd /clear między krokami.

Koszt na fazę. Każdy krok uruchamia subagenty (rozpoznanie, planner, plan-checker, jeden wykonawca na plan, weryfikator, agenci debugujący), a każdy startuje od definicji agenta o rozmiarze około 47 KB w 1.15.0 plus plików z .planning/, które czyta; polecenia plan i execute deklarują w Claude Code effort: max. Domyślny profil balanced daje plannerowi opus, a większości agentów sonnet, co Claude Code rozwiązuje na modele z przeglądu modeli; pozostałe poziomy opisuje plik GSD gsd-core/references/model-profiles.md. W Codex pliki .toml agentów z 1.15.0 nie przypinają modelu, więc działają na modelu twojej sesji, chyba że ustawisz w GSD model_overrides.

Ustawienia, które zmieniają rachunek, w kolejności, w jakiej warto je próbować:

Dźwignia	Polecenie	Z czego rezygnujesz
Wyłącz nieużywane klastry skilli	/gsd-surface disable ui	Polecenia, których w tym projekcie i tak byś nie użył
Pomiń rozpoznanie przy znanym stosie	/gsd-plan-phase 1 --skip-research albo workflow.research: false	Rozpoznanie bibliotek i wzorców przed planowaniem
Tańszy profil modeli	/gsd-config --profile budget	Jakość plannera i checkera w trudnych fazach
Grubsze plany	/gsd-plan-phase 1 --granularity coarse	Mniej, ale większych planów; większe ryzyko zaślepek
/gsd-quick do drobnych poprawek	/gsd-quick "…"	Pełną pętlę discuss, plan i verify

Rzeczywisty wydatek zmierz poleceniem /usage po fazie (mają je i Claude Code, i Codex), a w skali kamienia milowego śledź go per faza według podejścia ze strony o śledzeniu kosztów agentów.

Czy pozwolić /gsd-autonomous przejść pozostałe fazy?

/gsd-autonomous uruchamia discuss, plan i execute dla wszystkich pozostałych faz bez zatrzymywania się, a --from, --to i --only ograniczają zakres. Uruchamia weryfikatora, ale gdy faza wymaga weryfikacji przez człowieka, zapisuje w STATE.md status verification_deferred_human i idzie dalej. Nocny przebieg kończy się więc kodem, który przeszedł automatyczne kontrole, oraz listą sesji /gsd-verify-work, które nadal jesteś winien.

Uruchamiaj go tylko wtedy, gdy kryteria sukcesu są obserwowalne, twoje testy zawodzą przy złym zachowaniu (zobacz siłę wyroczni), a agent działa w jednorazowym środowisku bez produkcyjnych poświadczeń. Flaga --no-reversibility-gates w plan-phase usuwa ludzki checkpoint przed nieodwracalnymi decyzjami; nie łącz jej z przebiegiem bez nadzoru na niczym, co trzyma prawdziwe dane. Do przebiegów z jednym celem bez ceremonii GSD lżejsze jest wbudowane polecenie /goal, a strona o godzinach autonomii porównuje GSD z pętlami Ralph.

Kiedy GSD to zły wybór?

Twoja sytuacja	Lepszy wybór	Dlaczego
Funkcja na jeden wieczór w istniejącym repozytorium	Superpowers albo zwykły tryb planowania	Roadmapa i pliki faz GSD kosztują więcej niż sama funkcja
Zespół, który recenzuje specyfikacje, a nie plany	Spec Kit	Jego artefakty to specyfikacje funkcji do przeglądu przez zespół; artefakty GSD to plany jednej osoby
Zmiany w istniejącym kodzie, po których ma zostać żywa specyfikacja	OpenSpec	OpenSpec scala każdą zmianę z aktualną specyfikacją; GSD archiwizuje fazy
Jeden dobrze zdefiniowany cel z mocną wyrocznią testową	/goal	Jedno polecenie, bez frameworka i bez listy za 10 700 tokenów
Organizacja, która wymaga oceny dostawcy	Poczekaj albo przypnij wersję i zrób audyt	GSD Core to fork społeczności po incydencie z zarządzaniem projektem
Wielofazowy projekt od zera budowany przez jedną osobę	GSD	Trwały stan, świeże konteksty i bramki weryfikacji to dokładnie to, do czego powstał

Porównanie frameworków zestawia GSD z pozostałymi pod względem ceremonii, artefaktów i kosztu kontekstu.

Co się psuje w GSD i jak z tego wyjść?

Objaw	Przyczyna	Naprawa
Po instalacji brakuje poleceń /gsd-*	Agent nie został zrestartowany albo zainstalowana jest wtyczka, a wpisujesz pisownię z npm	Zrestartuj; sprawdź w menu /, czy widzisz /gsd-, /gsd-core: czy $gsd-
Polecenia wtyczki startują, ale zawodzi ich logika	gsd-tools nie ma w PATH albo hooki nie widzą node	Doinstaluj też paczkę npm i sprawdź, czy node --version działa w powłoce agenta
Wykonawca zatrzymuje się na „Permission denied” w Bash	Tryb Manual bez reguł zezwoleń dla gita i test runnera	Dodaj reguły dla git add, git commit i polecenia testowego do .claude/settings.local.json
Wykonanie zostawia zaślepki albo niedokończone pliki	Plany za duże dla jednego wykonawcy	Zaplanuj ponownie z --granularity fine; GSD zaleca dwa lub trzy zadania na plan
Główna sesja zwalnia i zapomina	Zapełniła się sama sesja orkiestrująca	/gsd-health --context (ostrzega od 60% i proponuje /gsd-thread) albo /clear, potem /gsd-resume-work
„FATAL: worktree base mismatch — HEAD is …, expected …”	Twoja gałąź wyprzedza domyślną, a worktree wykonawców powstają z origin/HEAD	GSD sam przechodzi na wykonanie sekwencyjne; przewodnik GSD o worktree base mismatch pokazuje, jak przywrócić równoległość
Agenci Codex padają na nieznanym modelu	Pliki .toml agentów ze starszej instalacji przypinają alias Anthropic, np. sonnet	Zainstaluj ponownie z --codex --global, co zapisuje pliki bez przypiętego modelu; gsd-tools validate agents wskaże pozostałe przypięcia
/gsd-ship blokuje z PHASE_VERIFICATION_INCOMPLETE	Weryfikacja jest nieaktualna, nieudana albo odłożona	/gsd-verify-work 1, potem ship jeszcze raz
/gsd-ship blokuje z SECURITY_SHIP_GATE_NO_REVIEW	Faza nie ma SECURITY.md	/gsd-secure-phase 1, zamknij otwarte zagrożenia, ship jeszcze raz

Subagent może zgłosić porażkę, choć jego commity trafiły do repozytorium. Zanim cokolwiek uruchomisz ponownie, sprawdź git log --oneline -10: to commity są źródłem prawdy.

Dokąd dalej z GSD

Frameworki pracy z agentami: porównanie GSD obok Superpowers, Spec Kit, OpenSpec i reszty, z kosztami kontekstu.

Godziny autonomii GSD Core, pętle Ralph, /goal i oh-my-claudecode w długich przebiegach bez nadzoru.

Wykonywalne kryteria akceptacji Pisz kryteria sukcesu, które weryfikator i twoje testy naprawdę sprawdzą.

Siła wyroczni Upewnij się, że testy uruchamiane przez wykonawców GSD potrafią zawieść przy złym zachowaniu.

Czytanie dowodów zamiast kodu Dlaczego sprawdzasz plany, pliki weryfikacji i UAT zamiast czytać każdą linię.

Everything Claude Code Jak zmierzyć i przyciąć koszt kontekstu frameworka.