GSD, kurz für „Get Shit Done“, gehört zu den bekanntesten Frameworks für Softwareentwicklung mit Claude Code. Inzwischen gibt es zwei Versionen, die sich grundlegend unterscheiden: Version 1 lebt als Sammlung von Anweisungen in Claude Code, Version 2 ist eine eigenständige Anwendung im Terminal.
In diesem Artikel erkläre ich dir, warum solche Frameworks überhaupt sinnvoll sind, wie GSD funktioniert und wie sich beide Versionen in meinem Praxistest geschlagen haben. Am Ende bekommst du eine klare Empfehlung, wann du welche Version nimmst und wann du gar kein Framework brauchst.
Warum Vibe Coding bei echten Projekten an Grenzen stößt
Wenn du schon mit Claude Code, Lovable oder ähnlichen Tools gearbeitet hast, kennst du das: Du schreibst „Bau mir ein Projektmanagement-Tool“ und bekommst in wenigen Minuten ein vorzeigbares Ergebnis. Dieses Vorgehen nennt man Vibe Coding. Es ist schnell, gibt dir aber keinen professionellen Rahmen, wie ihn echte Softwareprojekte brauchen.
Das Hauptproblem ist fehlendes Kontextmanagement. Früher oder später vergisst dein Coding Agent Dinge. Er setzt Anforderungen anders um, als du sie dir vorgestellt hast, überschreibt bestehende Funktionen oder ignoriert Entscheidungen, die ihr gemeinsam getroffen habt.
Context Rot: Warum Coding Agents vergessen
Dein Coding Agent arbeitet in jeder Session mit einem Kontextfenster, seinem Arbeitsgedächtnis. Stell es dir wie ein leeres Glas vor. Jede Nachricht, jede Antwort und jede bearbeitete Datei füllt es weiter. Kurz bevor es überläuft, verdichtet der Agent den Verlauf zu einer Zusammenfassung. Was das Modell dabei für unwichtig hält, ist danach weg.
Genau dabei gehen oft kleine Entscheidungen und Details verloren. Je größer Projekt und Codebase werden, desto stärker sinkt die Leistung. Dieses Phänomen heißt Context Rot. Größere Kontextfenster, wie die eine Million Token bei aktuellen Claude-Modellen, mildern das Problem, lösen es aber nicht.
Deshalb gibt es Context Engineering, also die Art, wie du den Kontext deines Agents gezielt verwaltest. Die wichtigste Regel: Speichere Wissen nie im Gedächtnis des Agents, sondern immer in Dateien. Claude Code bietet dafür die CLAUDE.md, Rules, Skills und Subagents. Dazu kommen projektbezogene Dokumente wie ein PRD (Product Requirements Document) mit Vision, Zielgruppe und Anforderungen sowie Feature-Spezifikationen mit User Stories, Akzeptanzkriterien und Testergebnissen.
Eine solche Struktur kannst du dir selbst aufbauen. So habe ich das auch gemacht. Oder du nutzt ein fertiges Framework wie GSD, das dir Prinzipien, Methoden und Workflows mitliefert.
Was ist GSD? Context Engineering als Framework
GSD ist im Kern ein Context-Engineering-System. Es zerlegt dein Projekt in kleine, atomare Aufgaben, und jede Aufgabe bekommt einen eigenen, frischen Kontext. Die Grundregel lautet: Jeder Task muss in ein Kontextfenster passen.
Drei weitere Eigenschaften machen GSD aus:
- Spec Driven: Bevor entwickelt wird, werden alle Anforderungen spezifiziert. Nur wenn der Agent genau weiß, was er bauen soll, stimmt am Ende die Qualität.
- Stack-agnostisch: Egal ob Web-App, Mobile App oder Desktop-Anwendung, GSD ist an keine Technologie gebunden.
- Fertiger Werkzeugkasten: GSD bringt vorkonfigurierte Slash Commands, Agents, Planungsdateien und einen eigenen Entwicklungsworkflow mit.
Die vier Phasen: Research, Plan, Execute, Verify
Research: GSD startet mehrere Agents parallel, die das Projekt aus verschiedenen Blickwinkeln betrachten. Einer recherchiert den Tech Stack, einer Best Practices, einer mögliche Fallstricke. Jeder arbeitet in einem eigenen Kontextfenster. Die Ergebnisse landen in einer Research-Datei, die Grundlage für alle späteren Entscheidungen ist.
Plan: Hier schreibt ein Agent den Plan, und ein zweiter hinterfragt ihn aktiv, um Schwachstellen zu finden. Erst wenn beide zufrieden sind, wird der Plan finalisiert. Die Aufgaben werden in sogenannte Waves gruppiert. Alles, was voneinander unabhängig ist, kann später parallel laufen.
Execute: Jetzt entsteht Code. Jede Aufgabe bekommt einen eigenen Subagenten mit frischem Kontext und genau dem Teil des Plans, den er braucht. Nach jeder Aufgabe erstellt GSD automatisch einen Git-Commit.
Verify: GSD prüft, ob das Ergebnis den Anforderungen entspricht. Tests laufen, der Output wird gegen den Plan geprüft, und du bekommst eine Zusammenfassung, was gebaut wurde und wie du es selbst testen kannst.
Dieser Zyklus wiederholt sich Phase für Phase, bis das Projekt steht.
GSD v1: Ein Prompt-Framework direkt in Claude Code
Version 1 ist ein reines Prompt-Framework. Was du installierst, ist eine Projektstruktur aus Markdown-Dateien: Agents, Commands, Templates und etwas Konfiguration. Die „Magie“ ist im Grunde eine sehr gute Arbeitsanleitung für Claude Code.
Das ist kein Nachteil, sondern ein Vorteil. GSD v1 ist keine Blackbox. Du siehst genau, welche Anweisungen Claude bekommt, und kannst das Framework an deine Bedürfnisse anpassen.
Installation und erster Durchlauf
Die Installation läuft über einen Befehl im Terminal (Stand meines Tests im März 2026):
npx get-shit-done-cc@latest
Du wählst den Coding Agent, in meinem Fall Claude Code, und ob du global für alle Projekte oder nur für das aktuelle Projekt installierst. Danach stehen dir die GSD-Befehle direkt in Claude Code zur Verfügung. Ich arbeite dabei in VS Code mit der Claude-Code-Erweiterung.
Ein neues Projekt startest du mit:
/gsd:new-project
GSD stellt dir dann Fragen. Für einen schnellen Test habe ich ein einfaches Projektmanagement-Tool mit Kanban-Board beschrieben, nur mit lokaler Speicherung und ohne Backend. Es folgten Rückfragen zu Frontend-Technologie, Spalten, Drag and Drop und Styling.
Danach konfigurierst du den Arbeitsmodus:
- Modus: interaktiv oder „YOLO“, also alles automatisch freigeben, ohne Rückfragen.
- Granularität: wenige breite Phasen oder viele kleine.
- Ausführung: parallel oder sequentiell.
- Planungsdokumente in Git committen: sinnvoll, damit du jederzeit zu einem alten Stand zurückkannst.
- Research vor jeder Phase, Plan-Check und Verifikation nach jeder Phase: kostet Token und Zeit, erhöht aber die Qualität.
- Modelle für die Planning Agents: etwa ein ausgewogenes Profil oder eines, das auf Qualität bzw. Budget optimiert.
Anschließend legt GSD die Basisdokumente an: PROJECT.md mit deinen Antworten, REQUIREMENTS.md mit den Anforderungen, eine ROADMAP.md mit den Phasen und eine STATE.md für den aktuellen Stand.
Der Workflow in Befehlen
Nach der Initialisierung schlägt GSD dir den nächsten Schritt vor. Die Phasen rufst du jeweils über einen eigenen Befehl auf:
| Befehl | Was passiert |
|---|---|
/gsd:new-project | Fragen, Research, Requirements, Roadmap |
/gsd:discuss-phase | Anforderungen und Entscheidungen vor der Planung klären |
/gsd:plan-phase | Recherche, Plan und Prüfung des Plans |
/gsd:execute-phase | Umsetzung in Waves mit parallelen Subagenten |
/gsd:verify-work | Prüfung gegen Anforderungen und Ziele |
Zwischendurch fragt dich GSD v1 immer wieder nach Reviews und Entscheidungen. Du bleibst als Mensch in der Schleife („Human in the Loop“).
Der Praxistest: Ein Incident-Management-Tool mit beiden Versionen
Für den eigentlichen Vergleich habe ich beide Versionen dasselbe Projekt bauen lassen: einen Incident Hub für ein fiktives SaaS-Unternehmen. Wenn Probleme auftreten, werden Tickets erstellt und landen in diesem System.
Beide Versionen bekamen dasselbe PRD mit Hintergrund, Problem, Zielgruppe, betroffenen Systemen und funktionalen Anforderungen. Ich habe nichts weiter ergänzt, sondern nur die Rückfragen beantwortet. Die waren bei beiden Frameworks zu etwa 80 Prozent identisch. Der Vergleich ist also fair.
Ergebnis GSD v1
GSD v1 hat einen .planning-Ordner mit PROJECT.md, REQUIREMENTS.md, ROADMAP.md und STATE.md angelegt. Pro Phase gibt es eigene Dokumente: Kontext, Pläne, Zusammenfassungen, Research, Validierung und ein Decision Log, in dem jede Architekturentscheidung festgehalten wird. Insgesamt waren es 19 Planungsdokumente.
Die App selbst: ein Dashboard mit Kennzahlen, eine Incident-Übersicht mit Detailansicht und die Möglichkeit, neue Incidents anzulegen. Optisch reißt das niemanden vom Hocker, aber es funktioniert.
Davon solltest du dich nicht abschrecken lassen. Ich habe keine Design-Vorgaben gemacht, und die Oberfläche lässt sich mit ein paar Styling-Prompts oder einer Komponentenbibliothek leicht verbessern. Was zählt, liegt dahinter: Projektstruktur, Anwendungslogik, Datenmodell und Planungsdokumente. Da hat v1 solide abgeliefert.
Ergebnis GSD v2
GSD v2 hat 30 Planungsdokumente erstellt, also deutlich mehr. Statt in Phasen plant v2 in Milestones und Slices. Jeder Slice hat eigene Dokumente für Research, Plan, Zusammenfassung, eine Nachbewertung (Assessment) und User Acceptance Tests. Darunter liegen einzelne Tasks, jeweils mit eigenem Plan inklusive Zeitschätzung und eigener Zusammenfassung.
Die App ist optisch deutlich ansprechender als die von v1. Die Incident-Detailansicht zeigt sogar eine komplette Timeline, und man kann Kommentare hinzufügen.
Die Unterschiede im Detail
| GSD v1 | GSD v2 | |
|---|---|---|
| Planungsdokumente | 19 | 30 |
| Planungseinheit | Phasen | Milestones, Slices, Tasks |
| Optik der App | funktional, schlicht | deutlich ansprechender |
| Testansatz | pragmatisch, erst die UI | testgetrieben, ca. 20 Tests allein für Statusübergänge vor der UI |
| Dependencies zum Start | 12 Libraries | 3 (Next.js, React, React DOM) |
| Nachbewertung je Einheit | nein | ja, Assessment nach jedem Slice |
| Kosten im Test | im Claude-Code-Abo enthalten | etwas über 20 US-Dollar über die API |
Testgetriebene Entwicklung: v2 verfolgt einen stärkeren TDD-Ansatz. Allein für die Statusübergänge der Incidents hat es rund 20 Tests geschrieben, bevor überhaupt die Oberfläche entstand. Ziel ist, Edge Cases von Anfang an abzudecken. v1 ist pragmatischer und baut zuerst die UI.
Dependencies: v1 hat sich zum Start mit 12 Libraries eingedeckt. v2 installiert nur das Nötigste und holt alles Weitere erst, wenn ein Slice es braucht. Das ist schlanker, kann aber die Feature-Entwicklung verlangsamen, wenn ständig nachinstalliert werden muss.
Map Codebase: GSD für bestehende Software
Eine Funktion von GSD v1 hat mich besonders beeindruckt: die Analyse bestehender Codebases, sogenannter Brownfield-Projekte. Das wird oft übersehen. In der Realität sitzen die meisten Unternehmen auf Bestandssoftware, die kaum noch jemand versteht. Der ursprüngliche Entwickler ist in Rente oder woanders, eine Dokumentation gibt es nicht, und alle hoffen, dass nichts kaputtgeht.
So eine Software zu analysieren dauert normalerweise Wochen. GSD v1 bringt dafür einen eigenen Befehl mit. Die offizielle Empfehlung: Wenn du GSD in ein bestehendes Projekt installierst, führst du zuerst diesen Befehl aus.
/gsd:map-codebase
GSD startet dann vier parallele Mapper-Agenten mit jeweils frischem Kontext. Sie analysieren den Stack, die Architektur, die Coding-Konventionen und bekannte Probleme („Concerns“). Heraus kommen sieben Dokumente im Ordner .planning/codebase:
STACK.mdARCHITECTURE.mdSTRUCTURE.mdCONVENTIONS.mdTESTING.mdINTEGRATIONS.mdCONCERNS.md
Diese Dokumente lädt GSD automatisch in die Planphase. Jede neue Phase weiß also, was in der Codebase existiert und wie es gebaut ist.
Der Test mit einem Legacy-Fußballmanager
Für meinen Test habe ich einen alten Fußballmanager genommen. Der Code ist um 2003 entstanden, wurde danach nur wenig weiterentwickelt und basiert auf einem entsprechend alten Stack. Das Projekt ist umfangreich, also ein guter Härtetest.
Das Ergebnis war ausführlich. Die Architekturdatei beschreibt Layer, Datenfluss, zentrale Abstraktionen und Einstiegspunkte. Die Concerns-Datei listet technische Schulden, bekannte Bugs und Sicherheitsaspekte. Die Stack-Datei zeigt primär PHP, dazu JavaScript mit jQuery, eine MySQL-Datenbank, Laufzeitumgebung, Abhängigkeiten und Konfiguration. Selbst Namenskonventionen und Coding Style wurden erfasst.
Auf dieser Basis könntest du mit Claude Code einen Migrationsplan schreiben: In welche Module teilt man das System auf, und wie migriert man es Stück für Stück auf einen modernen Stack? Allein für diesen Anwendungsfall lohnt es sich, GSD v1 einmal an einem echten Bestandsprojekt auszuprobieren.
Und in GSD v2?
Einen eigenen Map-Codebase-Befehl gibt es in v2 nicht. Die Analyse ist anders gelöst: v2 arbeitet mit drei spezialisierten Subagenten, Scout, Researcher und Worker. Der Scout analysiert vor jedem Slice automatisch die Codebase und übergibt das Ergebnis als komprimierten Kontext an den Worker.
Der Unterschied: Bei v1 hast du sieben dauerhafte Dokumente, die du lesen, prüfen und mit deinem Team besprechen kannst. Bei v2 passiert die Analyse im Hintergrund, bei jedem Schritt, aber weniger transparent. Für Legacy-Projekte, bei denen du die Analyse explizit als Gesprächsgrundlage oder für einen Migrationsplan brauchst, ist v1 deshalb klar die bessere Wahl.
GSD v2: Eine eigenständige CLI statt Prompt-Framework
GSD v2 ist eine eigenständige TypeScript-Anwendung, gebaut auf dem Pi SDK, einem Baukasten für eigene Coding Agents. Sie läuft nicht mehr in Claude Code, sondern als eigenes Programm im Terminal.
Der Grund für den Wechsel: In v1 bittet das Framework das Sprachmodell per Prompt, sich an eine Struktur zu halten. Das funktioniert meistens, bei mir sogar sehr gut, aber eben nicht garantiert. Niemand kann sicherstellen, dass Claude alle Anweisungen in den Dateien wirklich liest und anwendet.
In v2 passiert das programmatisch. Die Anwendung entscheidet selbst, welcher Kontext wann geladen wird, kann Kontextfenster leeren und bindet genau die richtigen Dateien zur richtigen Zeit ein, ohne dass das Modell diese Entscheidung treffen muss.
Neue Funktionen in v2
- Crash Recovery: Stürzt eine Session ab, erkennt v2 anhand von Logdateien, wo es aufgehört hat, und macht nahtlos weiter.
- Kosten-Tracking: Du siehst bei jedem Prompt, was ein Task kostet, aufgeschlüsselt nach Phase und Modell.
- Stuck Detection: Dreht sich das Modell im Kreis, erkennt v2 das automatisch.
- Git-Worktree-Isolation: Jeder Milestone läuft in einem eigenen Worktree, also einer separaten Arbeitskopie des Repos, und wird am Ende sauber zusammengeführt.
- Boundary Map: Definiert, was jeder Slice an andere liefert und was er von ihnen braucht. Mehr dazu weiter unten.
Dazu kommen zwei Modi. Im Step Mode pausiert der Agent zwischen den Einheiten, und du bestätigst jeden Schritt. Im Auto Mode gibst du einmal den Auftrag, gehst weg und findest bei deiner Rückkehr fertigen Code mit sauberer Git-History.
Installation und Bedienung
Installiert wird v2 global über npm (Stand meines Tests):
npm install -g gsd-pi
Gestartet wird es im Terminal mit gsd. Den autonomen Modus startest du mit:
/gsd auto
Weil v2 ein eigenes Programm ist, kannst du es nicht über die Claude-Code-Erweiterung in VS Code bedienen, sondern arbeitest direkt im Terminal. Der Ablauf ähnelt v1: GSD fragt nach deiner Vision, stellt Rückfragen zum Stack und zu den Funktionen, fasst zusammen, was es verstanden hat, und legt dann Anforderungen, Tasks und Roadmap an. Der Auto Mode führt dich weitgehend durch den Prozess, du kannst aber jederzeit eingreifen und zum Beispiel eine Discuss-Phase starten.
Der Haken: API statt Abo
Weil v2 nicht in Claude Code läuft, braucht es eine eigene Verbindung zu einem Modellanbieter. v2 bietet zwar eine OAuth-Anmeldung für Claude, Gemini und Co. an, die ich aber nicht empfehle: Anthropic und Google untersagen in ihren Nutzungsbedingungen inzwischen, Abos für Drittanwendungen zu nutzen. Realistisch gehst du also über die API und zahlst nach Verbrauch.
In meinem Test bin ich dabei immer wieder an die Rate Limits der Claude API gestoßen. Diese Limits hängen von deinem Usage Tier ab, und das wiederum davon, wie viel Guthaben du bisher aufgeladen hast. Ich war mit rund 50 Euro Aufladung in Tier 2. Der Prozess ist so tokenintensiv, dass ich regelmäßig eine Minute warten musste, bis wieder Kapazität frei war.
Und die Kosten: Mein Incident Hub war nur ein Frontend mit Dashboard, Übersicht und Anlage neuer Incidents, gespeichert im Browser, ohne Backend. Das hat mich über die API bereits etwas über 20 US-Dollar gekostet. Opus gehört zu den teuersten Modellen: Laut Anthropic-Preisliste kosten bei Opus 4.6 eine Million Input-Token 5 US-Dollar und eine Million Output-Token 25 US-Dollar. Bei größeren Projekten laufen die Kosten schnell auf.
Zum Vergleich: Ich nutze den Claude-Code-Max-Plan für rund 100 US-Dollar im Monat. Damit kann ich v1 im Rahmen meiner Limits so viel nutzen, wie ich will, und habe einen klaren Kostenrahmen. Wer Geld sparen will, kann v2 auch mit Open-Source- oder lokalen Modellen betreiben. Im direkten Vergleich Opus im Abo gegen Opus über die API ist das Abo aber klar im Vorteil.
Was GSD v2 besonders gut macht
Granulare Planung mit Assessments
Die Planungsstruktur von v2 hat mich beeindruckt. Jeder Task hat einen eigenen Plan mit Zeitschätzung, und jeder Slice wird nach Abschluss bewertet. Ergibt die Bewertung, dass sich etwas geändert hat, wird die Roadmap angepasst.
Die Kehrseite: Bei 30 Dokumenten für ein kleines Projekt musst du aufpassen, den Überblick zu behalten. Schau dir die Dokumente in Ruhe an, dann bekommst du ein Gefühl dafür, ob du diesen Detailgrad brauchst.
Boundary Map: Übergabe-Checklisten zwischen Slices
Stell dir vor, dein Projekt hat fünf Slices. Slice 1 baut das Datenmodell, Slice 2 die Oberfläche, Slice 3 die KI-Integration. Slice 2 muss wissen, welche Datentypen und Funktionen Slice 1 bereitstellt, sonst baut er etwas, das nicht zusammenpasst.
Die Boundary Map legt genau das fest: Was liefert jeder Slice, und was braucht er von den anderen? Im Grunde sind das Übergabe-Checklisten zwischen Bauabschnitten. Sie verhindern, dass Slices aneinander vorbeientwickeln.
Vor- und Nachteile im Überblick
| GSD v1 | GSD v2 | |
|---|---|---|
| Vorteile | transparent, alle Anweisungen lesbar und anpassbar | Kontext wird programmatisch gesteuert, nicht per Prompt |
| läuft im Claude-Code-Abo, klare Kosten | Crash Recovery, Stuck Detection, Kosten-Tracking | |
| Map Codebase mit sieben dauerhaften Analysedokumenten | granulare Planung mit Boundary Map und Assessments | |
| schneller Einstieg, aktiv weiterentwickelt | stärkerer TDD-Ansatz, schlanker Start | |
| du behältst bei jedem Schritt die Kontrolle | Auto Mode für maximale Autonomie | |
| Nachteile | keine Garantie, dass Claude alle Anweisungen befolgt | API-Kosten, im Test schon über 20 US-Dollar für ein kleines Frontend |
| schlichtere Optik im Test | Rate Limits der API bremsen | |
| weniger granulare Planung | Codebase-Analyse läuft unsichtbar im Hintergrund | |
| sehr viele Dokumente, Gefahr, den Überblick zu verlieren |
GSD v1 oder v2: Wann nimmst du was?
Nimm GSD v1, wenn
- du ohnehin mit Claude Code arbeitest und ein Abo hast,
- du bei jedem Schritt die Kontrolle behalten willst,
- du schnell starten möchtest,
- du bestehende Codebases analysieren willst, etwa als Grundlage für eine Migration.
Zum Zeitpunkt meines Tests wurde v1 noch aktiv weiterentwickelt. Wie lange das so bleibt, kann ich nicht sagen. Selbst wenn nicht: Die Prinzipien kannst du jederzeit in dein eigenes Setup übertragen.
Nimm GSD v2, wenn
- du maximale Autonomie willst,
- du CI/CD-Pipelines anbinden möchtest,
- du im Team arbeitest,
- dir granulare Planung mit Boundary Maps und Nachbewertungen wichtig ist,
- du die API-Kosten bewusst einplanst.
Nimm gar kein Framework, wenn dein Projekt sehr klein ist. Dann ist es oft sinnvoller, direkt mit Claude Code loszulegen.
Es gibt derzeit nicht das eine perfekte Framework. Die Wahl hängt vom Projekt ab: Ist es neu oder bestehend? Wie groß ist es? Wie viele Leute arbeiten daran? Und wo liegen deine eigenen Kenntnisse? Am besten probierst du beide aus und entwickelst etwas Kleines damit. Dann merkst du schnell, ob dir Ergebnisse und Workflow zusagen.
Einordnung: Struktur schlägt Tool
Kurz zusammengefasst: GSD v1 ist ein Prompt-Framework für einen kontrollierten, spezifikationsgetriebenen Workflow direkt in Claude Code. GSD v2 ist eine eigenständige CLI für maximale Autonomie und Teamarbeit. Beide lösen dasselbe Problem: Sie geben dem Modell zur richtigen Zeit strukturierten Kontext und wirken so Context Rot entgegen.
Meine ehrliche Einschätzung: Für die meisten, die mit Claude Code arbeiten, ist v1 der pragmatischere Einstieg, weil es transparent ist und im Abo läuft. v2 ist technisch interessanter und plant gründlicher, kostet über die API aber spürbar Geld. Wichtiger als die Wahl des Frameworks ist das Prinzip dahinter: Anforderungen spezifizieren, Wissen in Dateien ablegen, Aufgaben klein schneiden und jedes Ergebnis prüfen. Wenn du ein Projekt bauen willst, das wächst und das du am Ende vielleicht verkaufst, brauchst du genau diesen strukturierten Entwicklungsprozess, egal ob mit GSD oder deinem eigenen System. Falls du gerade erst startest, zeige ich dir in meiner Anleitung, wie du mit Claude Code deine erste Web-App entwickelst.
