Get Shit Done: phasenweises Context Engineering für Coding-Agenten

Alles Wissenswerte über gsd-build/get-shit-done: das historische Repository eines spezifikationsgetriebenen Entwicklungs-Workflows, der seine aktive Entwicklung heute an open-gsd/gsd-core weiterleitet.

Was Get Shit Done ist

Get Shit Done (GSD) war ein schlankes System aus Metaprompts, Context Engineering und spezifikationsgetriebener Entwicklung für Coding-Agenten. Das historische README beschreibt es als Vorschlag für Claude Code; das Repository enthält keinen aktiven Code mehr: Seit Mai 2026 zeigt es einen Hinweis auf die Verlagerung zu open-gsd/gsd-core, das nun Code, Issues, Releases und Beiträge bündelt.

Die Fortsetzung, GSD Core, soll die Qualitätsverschlechterung begrenzen, die sich aufbaut, wenn eine Agenten-Konversation sein Kontextfenster füllt. Dazu bewahrt es Projektartefakte wie STATE.md und CONTEXT.md und verlagert intensive Recherche, Planung und Ausführung auf Subagenten mit frischem Kontext. Das aktuelle README erklärt Kompatibilität mit Claude Code, OpenCode, Antigravity CLI, Kimi CLI, Kilo, Codex, Copilot, Cursor und Windsurf, unter anderem.

Durchscheinendes Kontextfenster, unterteilt in isolierte Kammern mit Agenten, die Aufgaben verarbeiten, daneben die Dateien STATE.md und CONTEXT.md, die neongrün leuchten.

Der Ursprung: ein populäres Repository, das umgezogen ist

Die GitHub-API datiert die Erstellung von gsd-build/get-shit-done auf den 14. Dezember 2025. Die Beschreibung schreibt das System TÂCHES zu, aber die gefundenen Quellen identifizieren keine konkrete Person hinter diesem Namen überprüfbar; daher wird keine individuelle Autorenschaft zugeordnet. Die größten Beitragenden laut API sind trek-e (1.435 Beiträge), glittercowboy (945) und Tibsfox (127).

Die jüngere Geschichte ist klarer als der ursprüngliche Start: Das README des historischen Repositorys teilt mit, dass GSD als GSD Core unter open-gsd/gsd-core fortgeführt wurde. Die API datiert dieses neue Repository auf den 22. Mai 2026. Es wurde weder eine Launch-Ankündigung mit Entstehungsgeschichte noch ein Team-Beitrag gefunden, der den organisatorischen Grund für den Umzug erklärt; über den Migrationshinweis hinaus bleibt dieser Teil unbestätigt.

Der Übergang erzeugt auch eine praktische Spannung: Das historisch populäre Repository ist weiterhin dasjenige, das in Suchergebnissen und Community-Links erscheint, während die aktuellen Anweisungen ausdrücklich sagen, dass es nicht für Issues, Releases oder Beiträge verwendet werden soll. Mit anderen Worten: Die Zahlen des historischen Repositorys allein beschreiben nicht die aktuelle Pflege.

Cyberpunk-Migrationsszene: ein verwitterter Server-Turm mit der Aufschrift gsd-build/get-shit-done, verbunden durch eine Neon-Datenbrücke mit einem leuchtenden neuen Kern mit der Aufschrift open-gsd/gsd-core, mit den schwebenden Datumsangaben 14. Dez. 2025 und 22. Mai 2026.

Philosophie und Prinzipien

Der Ansatz stützt sich auf fünf wiederholbare Schritte pro Phase:

Besprechen: Implementierungsentscheidungen vor der Planung festlegen.
Planen: recherchieren, zerlegen und prüfen, ob der Plan in einen frischen Kontext passt.
Ausführen: Pläne in parallelen Wellen mit Executors mit sauberem Kontext abarbeiten.
Verifizieren: das Gebaute prüfen, Fehler diagnostizieren und beheben, bevor es als fertig erklärt wird.
Liefern: den Pull Request erstellen, die Phase archivieren und den Zyklus wiederholen.

Fünfteilige holografische Infografik, die die Phasen Besprechen, Planen, Ausführen, Verifizieren und Liefern darstellt, verbunden durch eine Neon-Linie im Kreislauf.

Es ist eine Philosophie der Kontextkontrolle und des persistenten Zustands, kein Versprechen, dass jeder Agent korrekten Code produziert. Das aktuelle README argumentiert, dass das operative Problem der Informationsverlust zwischen Sitzungen und das Fehlen von Verifikation ist; die Artefakte und die Verifikationsphase sind die explizite Antwort darauf.

Wie es funktioniert

Die aktuelle Installation erfolgt mit:

npx @opengsd/gsd-core@latest

Der Installer fragt nach der Umgebung und nach globaler oder lokaler Installation; die Dokumentation rät davon ab, Dateien aus agents/ oder commands/ direkt zu kopieren, da die Installation das Paket an jede Umgebung anpasst.

Futuristisches Terminal, das den Befehl npx @opengsd/gsd-core@latest in Neongrün zeigt, mit Icons kompatibler Umgebungen wie Claude Code, Cursor und Windsurf, verbunden durch Lichtfäden.

Um ein Projekt zu starten, werden unter anderem diese Befehle verwendet:

/gsd-new-project   # neues Projekt
/gsd-onboard       # bestehende Codebasis

Das Ergebnis des Zyklus ist nicht nur eine Konversation: GSD bewahrt Entscheidungen und Zustand in Dateien, teilt die Arbeit in Phasen auf und kann Pläne parallel ausführen. Die Dokumentation von GSD Core behauptet, dass jeder Executor einen sauberen Kontext von bis zu 200.000 Tokens erhält; das ist ein vom Projekt angegebenes Merkmal, keine unabhängige Messung.

Die zuletzt abgerufene stabile Version von GSD Core, v1.9.1 (31. Juli 2026), fügt einen Eingabetyp für externe Reviewer hinzu und behebt unter anderem Isolationsprobleme bei Arbeitsverzeichnissen (Worktrees), eine saubere Installation für Codex und die Auflösung des Projekt-Roots. Die jüngste historische Version von gsd-build/get-shit-done war der Release-Kandidat v1.43.0-rc2 vom 17. Mai 2026.

Offizieller und halboffizieller Status

Es wurde kein Beleg gefunden, dass gsd-build/get-shit-done in einen offiziellen Marktplatz von Anthropic, OpenAI, GitHub, Cursor oder einem anderen Anbieter aufgenommen wurde. Auch keine Empfehlungserklärung eines Herstellers wurde gefunden. Daher ist es nicht angemessen, es als offizielles Plugin oder formellen Standard zu bezeichnen.

Es kann durchaus als De-facto-Referenz innerhalb eines Teils der Community für Agenten-Workflows gelten: Der Hacker-News-Thread vom März 2026 stellte es neben Superpowers, OpenSpec und Spec Kit, und mehrere Kommentatoren nutzten es als Vergleichspunkt. Dieser Status beschreibt Nutzung und Anerkennung durch die Community, nicht die Zertifizierung eines Anbieters oder eine Validierung der Ergebnisse.

Das Ökosystem

Von den GSD-Organisationen gepflegte Repositories

Die am 2. August 2026 abgerufene GitHub-API zeigt eine aktive Familie rund um die Open-GSD-Fortsetzung:

open-gsd/gsd-core: Hauptfortsetzung; 7.558 Sterne und 518 Forks.
open-gsd/gsd-pi: Anpassung für Pi; 989 Sterne und 88 Forks.
open-gsd/gsd-path: disziplinierte Entwicklung von der Idee bis zum ausgelieferten Code; 0 Sterne in der abgefragten Antwort.
open-gsd/gsd-spec-build-loop: Skill für den Zyklus Spezifikation → Build → Review; 5 Sterne.
open-gsd/gsd-browser: Kommandozeilen-Schnittstelle für Browser-Automatisierung auf Basis des Chrome DevTools Protocol; 36 Sterne.
open-gsd/gsd-test-runner: entfernter Node-Test-Runner in Containern; 9 Sterne.
open-gsd/gsd-cursor: Plugin für den Cursor-Marktplatz; 1 Stern.
open-gsd/marketplace-gsd-dev: Marktplatz von OpenGSD; 2 Sterne.
open-gsd/gsd-cloud-daemon: Daemon von GSD Cloud; 3 Sterne.

Die frühere Organisation gsd-build besitzt außerdem gsd-2 (7.749 Sterne), agent-inbox (57), gsd-browser (251), daemon (8), context-packet (50), docs (2) und protocol-go (1). Die Namen und Zahlen stammen aus der Abfrage der Repositories dieser Organisationen; sie implizieren nicht, dass alle den gleichen Support-Status haben.

Ports, Forks und Community-Erweiterungen

rokicool/gsd-opencode erscheint im README von GSD Core als der ursprüngliche Port für OpenCode. Die Sternezahl wurde in diesem Durchlauf nicht abgerufen.
itsjwill/gsd-pro, ein Fork, der Multi-Modell-Routing, Retrieval und adaptiven Kontext bewirbt, hatte 79 Sterne und 16 Forks.
sudokku/gsd-watch, ein Echtzeit-Dashboard für Phasen, Aufgaben und Sitzungen mit tmux, hatte 19 Sterne.
lgwanai/spec-skill präsentiert sich auf Chinesisch als tiefgreifende Nachbildung des GSD-Workflows und behauptet, .planning-Dokumente mit GSD interoperieren zu lassen; es hatte 6 Sterne. Es ist ein überprüfbares Beispiel für eine nicht-englische Adaption.
PCJIRON/gsd-qwen passt GSD an die Qwen-Code-Erweiterung an; es hatte 2 Sterne.
buildtheturfu/turfu-gsd erklärt auf Französisch, auf GSD aufzubauen und die Phasen Recherche, Besprechen, Planen, Ausführen, Verifizieren und Liefern zu bewahren; das Suchergebnis zeigte 0 Sterne.
uublive/GSD-Locksmith fügt Teamkoordination hinzu, um Kollisionen bei Meilensteinen und Phasen zu vermeiden; das Ergebnis zeigte 0 Sterne.
snipcodeit/mgw definiert sich als GitHub-Projektorchestrierung auf Basis von GSD, von Issue bis Pull Request; es zeigte 5 Sterne.

Dies sind über Suche gefundene Drittanbieter-Projekte. Ihre Existenz entspricht keiner Freigabe durch das Open-GSD-Team.

Leuchtender hexagonaler Kern von open-gsd/gsd-core, umgeben von Satellitenknoten, die Repositories wie gsd-pi, gsd-browser, gsd-test-runner, gsd-pro und gsd-watch darstellen.

Zahlen zum Repository

Messung: 2. August 2026, öffentliche GitHub-API.

Metrik	`gsd-build/get-shit-done` historisch	`open-gsd/gsd-core` aktiv
Sterne	64.783	7.558
Forks	5.463	518
Echte Abonnenten	266	31
Commits	2.928	4.898
Von der API angegebene offene Issues	0	150
Lizenz	MIT	MIT
Erstellung	14. Dezember 2025	22. Mai 2026
Letzte Metadaten-Aktualisierung	2. August 2026	2. August 2026
Letzte abgerufene Veröffentlichung	`v1.43.0-rc2`, 17. Mai 2026	`v1.9.1`, 31. Juli 2026

Die Commit-Summen ergeben sich aus der letzten Seite, die von den Paginierungslinks der API angegeben wird. Im historischen Repository ist die Hauptsprache laut API JavaScript, und die abgerufene Aufschlüsselung enthält JavaScript, TypeScript und Shell. Die allgemeine API spiegelt die Sterne in watchers_count; deshalb wird subscribers_count hier als echte Abonnentenzahl angegeben. Das Feld open_issues_count kann offene Pull Requests enthalten; es sollte nicht als ausschließliche Issue-Zählung interpretiert werden.

Die wichtigsten Beitragenden des aktiven Repositorys sind trek-e (2.982 Beiträge), glittercowboy (945), Tibsfox (127), davesienkowski (125) und jeremymcs (122).

Als zusätzliches Nutzungssignal meldete npm 41.372 Downloads von get-shit-done-cc zwischen dem 2. und 31. Juli 2026 sowie 38.843 von @opengsd/gsd-core im selben Zeitraum. Downloads identifizieren weder eindeutige Installationen noch erfolgreiche Nutzung.

Dashboard mit zwei holografischen Balkendiagrammen, die die Metriken des historischen und des aktiven Repositorys vergleichen, daneben ein Diagramm der npm-Downloads.

Wie man beiträgt

Beiträge sollten an open-gsd/gsd-core gerichtet werden, nicht an das archivierte Repository. Die Anleitung verlangt Node gemäß .nvmrc, npm run check:env, npm ci und npm test; npm ci ist verpflichtend, um die Lockfile zu respektieren.

Der Prozess lautet ausdrücklich „Issue vor Code”. Für eine Korrektur wird zuerst ein Bericht eröffnet und eine Bestätigung abgewartet; für eine Verbesserung ist das Label approved-enhancement erforderlich; für eine neue Funktion eine genehmigte Spezifikation und approved-feature. Danach wird ein Pull Request mit der passenden Vorlage, Tests und einem Verweis auf das Issue erstellt. Fast alle Pull Requests richten sich an den Branch next; main ist Produktion, kritischen Korrekturen und Releases vorbehalten. Die Anleitung besagt, dass Pull Requests ohne genehmigtes Issue automatisch geschlossen werden und dass CI grün bleiben muss.

Cyberpunk-Flussdiagramm des Beitragsprozesses: Ein Issue-Bericht führt zu einer genehmigten Verbesserung, einem Pull Request und schließlich einem grünen CI-Status, wobei sich die Branches next und main am Ende trennen.

Wie die Community reagierte

Der Hacker-News-Beitrag 47417804, veröffentlicht von stefankuehnel am 17. März 2026, erreichte laut Algolia-Suche 473 Punkte und 253 Kommentare; die direkte Abfrage des Elements ergab 65 Kommentare in der verfügbaren Antwort. Die Diskrepanz ist eine beobachtbare Einschränkung der abgerufenen Antworten, weshalb die zweite Zahl nicht als endgültige Gesamtzahl verwendet wird.

Hacker-News-Terminal mit einem Punktezähler, der auf 473 hochzählt, und Kommentarblasen, die zustimmende Reaktionen mit Kritik an Kosten und Sitzungslimits mischen.

Die Resonanz war eindeutig gemischt und bietet konkrete Beispiele:

yoaviram erklärte, GSD habe bei komplexen Aufgaben „95 %” der Arbeit übernommen und sie hätten es genutzt, um ein SaaS-Produkt zu launchen; er fügte hinzu, dass sich auch die Modelle im betreffenden Zeitraum verbessert hätten. Das ist auf persönlicher Erfahrung beruhende Begeisterung, keine kontrollierte Bewertung.
schnitzelstoat sagte im Thread 48019025, das Tool habe ihm bei der Planung geholfen und den Kontext klein gehalten, sei aber langsamer gewesen als die direkte Nutzung von Claude. Dieser Thread verzeichnete 270 Punkte und 40 Kommentare beim abgerufenen Element.
anentropic schätzte, dass das System Fragen stellt und Kontext verwaltet, wies aber darauf hin, dass es nicht erlaubt, eine Aufgabe einfach zu starten und zu vergessen, und dass es seine eigenen Planungsdateien recht häufig erneut liest.
Die am häufigsten wiederholte Kritik betraf die Kosten. MeetingsBrowser sagte, er habe keine messbare Verbesserung gegenüber direkten Anweisungen erzielt und innerhalb von etwa 30 Minuten Sitzungslimits erreicht; gtirloni schätzte nach eigener Erfahrung einen zehnfach höheren Token-Verbrauch; vinnymac kritisierte die Interaktionszeit und die übermäßige Planung.
ibrahim_h wandte ein, dass die historische Empfehlung, mit --dangerously-skip-permissions auszuführen, eine Risikofläche öffnen könne: Seiner Lesart nach prüft der Plan-Checker die logische Vollständigkeit, nicht jeden generierten Befehl. Das ist eine technische, diesem Kommentator zugeschriebene Kritik; sie wurde in diesem Durchlauf nicht durch ein unabhängiges Audit validiert.
Andrei_dev stellte infrage, ob viel generierter Code automatisch gut überprüft werde, und nannte Risiken wie hartcodierte Zugangsdaten und nicht authentifizierte Routen. joegaebel vertrat die Ansicht, dass Spezifikationen in natürlicher Sprache automatisierte Tests nicht ersetzen. Beides sind Einwände von Teilnehmern, keine bestätigten Mängel des Projekts.

Get Shit Done im Vergleich zu anderen Ansätzen

Ansatz	Überprüfbare Übereinstimmung	Überprüfbarer Unterschied oder Grenze des Vergleichs
`obra/superpowers`	Im HN-Thread verglichen mehrere Teilnehmer es mit GSD als strukturiertem Agenten-Workflow.	`gtirloni` sagte, er bevorzuge den nativen Planungsmodus, und ordnete beiden Frameworks einen höheren Token-Verbrauch zu; es wurde kein unabhängiger Test gefunden, der einen Gewinner feststellt.
`github/spec-kit`	`bgnm2000` und `ochronus` listeten es neben GSD als Planungs- oder spezifikationsgetriebenes Entwicklungswerkzeug auf.	Die gefundenen Quellen belegen nur, dass die Community sie zusammen einordnet; das reicht nicht, um architektonische oder leistungsbezogene Gleichwertigkeit zu behaupten.
OpenSpec	`gbrindisi` erklärte, er bevorzuge es, weil es erlaube, den Workflow schrittweise anzupassen.	Das ist eine Nutzerpräferenz, kein experimenteller Vergleich; GSD unterscheidet sich hier durch seinen Phasenzyklus und dokumentierte Artefakte.
`ChristopherKahler/paul`	`jankhg` stellte es als weitere Alternative vor und verlinkte einen Vergleich in seinem Repository.	Der Kommentator sagte, PAUL vermeide Subagenten und könnte daher weniger Tokens benötigen; die verlinkte Studie wurde nicht abgerufen oder verifiziert.
`buildomator/buildomator`	Wird als Plan-→-Ausführen-→-Verifizieren-Workflow für Claude Code beschrieben und gibt an, sich aus GSD entwickelt zu haben.	Die GitHub-Beschreibung wirbt mit Projektstatus über MCP und Abweichungserkennung; es hatte 83 Sterne, aber seine Versprechen zur Token-Ersparnis wurden nicht verifiziert.

Anwendungsfälle und wem dieses Repository helfen kann

Teams, die eine Codebasis starten oder ein bestehendes Projekt in einen Agenten-Workflow überführen, können die aktive Fortsetzung mit npx @opengsd/gsd-core@latest installieren und mit /gsd-new-project oder /gsd-onboard beginnen. Der Zyklus aus Besprechen, Planen, Ausführen, Verifizieren und Liefern hinterlässt Entscheidungen und Zustand in Artefakten wie CONTEXT.md und STATE.md, teilt die Arbeit nach Phasen auf und lässt Executors mit frischem Kontext Pläne in Wellen verarbeiten.

Maintainer, die zu GSD beitragen oder es aktualisieren müssen, sollten in open-gsd/gsd-core arbeiten, nicht im historischen Repository: die Umgebung mit .nvmrc vorbereiten, npm run check:env, npm ci und npm test ausführen, vor dem Code ein Issue eröffnen und die meisten Pull Requests an next richten. Das Repository kann außerdem jenen dienen, die spezifikationsgetriebene Workflows vergleichen, wobei Token-Kosten, zusätzliche Planung und Ausführungsberechtigungen abgewogen werden sollten, bevor es auf kleine oder sensible Aufgaben angewendet wird.

Ressourcen

Historisches Repository: https://github.com/gsd-build/get-shit-done
Aktueller Code, Issues und Releases: https://github.com/open-gsd/gsd-core
Dokumentation und Installation: https://github.com/open-gsd/gsd-core#quickstart
Befehle und Konfiguration: https://github.com/open-gsd/gsd-core/tree/main/docs
Offizieller Leitfaden für Beiträge: https://github.com/open-gsd/gsd-core/blob/main/CONTRIBUTING.md
Offizielle Skills und Workflow: https://github.com/open-gsd/gsd-core/tree/main/agents
Discord-Community: https://discord.gg/mYgfVNfA2r
Community-Gespräche und Reviews: https://news.ycombinator.com/item?id=47417804, https://news.ycombinator.com/item?id=48019025

Hinweis: Dieser Artikel kombiniert die README- und Contributing-Leitfäden von GSD, die GitHub-API, die npm-API und am 2. August 2026 abgerufene Hacker-News-Daten. Die Zahlen ändern sich mit der Zeit.