Get Shit Done - Meta-Prompt- und spezifikationsbasiertes Entwicklungssystem

 (github.com/gsd-build)
12 Punkte von GN⁺ 2026-03-19 | 1 Kommentare | Auf WhatsApp teilen
  • Ein leichtgewichtiges System, das spezifikationsbasierte Entwicklung (SDD) in Umgebungen wie Claude Code automatisiert und dabei hilft, Projekte ohne komplexe Workflows fertigzustellen
  • Verhindert Qualitätsverlust bei AI-Code durch Context Engineering, XML-basierte Prompt-Strukturierung und Multi-Agent-Orchestrierung (context rot)
  • Automatisiert mit Befehlen wie /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase den gesamten Entwicklungszyklus von Ideendefinition → Planung → Ausführung → Verifikation
  • Sichert Nachvollziehbarkeit und Effizienz durch atomare Git-Commits pro Arbeitseinheit und parallele Ausführung (wave execution)
  • Ein Werkzeug, das von Engineers bei Amazon, Google, Shopify, Webflow genutzt wird und die Zuverlässigkeit und Produktivität AI-gestützter Entwicklung erhöht

Überblick

  • Get Shit Done (GSD) ist ein leichtgewichtiges Meta-Prompt- und Kontextmanagement-System, das in verschiedenen AI-Entwicklungsumgebungen wie Claude Code, OpenCode, Gemini CLI, Codex, Copilot, Antigravity funktioniert
  • Es löst das Problem von context rot, bei dem die Kontextqualität während der Code-Erstellung durch die AI nachlässt, und erzeugt auf Spezifikationen basierende konsistente Ergebnisse
  • Läuft auf Mac, Windows und Linux und kann mit dem Befehl npx get-shit-done-cc@latest installiert werden

Hintergrund der Entwicklung (Why I Built This)

  • Entwickelt, um das Problem zu lösen, dass Tools für große Organisationen unnötig komplexe Abläufe verlangen
  • GSD ist nach dem Prinzip Komplexität im System, einfacher Workflow nach außen konzipiert
  • Intern übernimmt es Context Engineering, XML-Prompt-Formatierung, Sub-Agent-Orchestrierung und Zustandsverwaltung
  • Nutzer können Projekte allein mit einfachen Befehlen abschließen

Hauptfunktionen und Workflow (How It Works)

  • Der gesamte Entwicklungsprozess besteht aus 6 Phasen

    1. Projektinitialisierung: Fragt Idee, Einschränkungen, Tech-Stack usw. ab und erzeugt PROJECT.md, ROADMAP.md usw.
    2. Diskussionsphase: Definiert Implementierungsdetails und erzeugt CONTEXT.md
    3. Planungsphase: Parallele Recherche und Planung, Erstellung von Arbeitseinheiten in XML-Struktur
    4. Ausführungsphase: Abhängigkeitsbasierte wave-parallele Ausführung, Commits und Verifikation pro Aufgabe
    5. Verifikationsphase: Automatische Tests und Bestätigung durch den Nutzer, bei Fehlschlägen automatische Erstellung eines Korrekturplans
    6. Wiederholung und Meilensteinabschluss: Wiederholung der einzelnen Phasen und anschließendes Release-Tagging

  • Quick Mode verarbeitet einzelne Aufgaben schnell und kann mit den Flags --discuss, --research, --full fein gesteuert werden

Kerntechnologien (Why It Works)

  • Context Engineering: Verwaltet den projektweiten Kontext dateibasiert (PROJECT.md, REQUIREMENTS.md, STATE.md usw.)
  • XML-Prompt-Formatierung: Definiert jede Aufgabe klar und enthält Verifikationsverfahren
  • Multi-Agent-Orchestrierung: Paralleler Betrieb spezialisierter Agenten für Recherche, Planung, Ausführung und Verifikation
  • Atomare Git-Commits: Commits pro Arbeitseinheit sorgen für Nachvollziehbarkeit und einfache Wiederherstellung
  • Modulares Design: Phasen können frei ergänzt, eingefügt oder verändert werden und ermöglichen flexibles Projektmanagement

Befehlsstruktur (Commands)

  • Kern-Workflow: /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase, /gsd:verify-work
  • Unterstützung für UI-Design: /gsd:ui-phase, /gsd:ui-review
  • Codebase-Analyse: /gsd:map-codebase
  • Projektmanagement: /gsd:add-phase, /gsd:insert-phase, /gsd:complete-milestone
  • Utilities: /gsd:quick, /gsd:health, /gsd:stats, /gsd:debug, /gsd:note usw.

Einrichtung und Konfiguration (Configuration)

  • In der Konfigurationsdatei .planning/config.json lassen sich Modi, Phasenfeingranularität, Modellprofile, Workflow-Agenten, Parallelisierung und Git-Branching-Strategie steuern
  • Für Modellprofile stehen quality, balanced, budget, inherit zur Auswahl
  • Mit Toggles wie workflow.research, workflow.plan_check, workflow.verifier lassen sich Qualität und Geschwindigkeit anpassen

Sicherheit und Fehlerbehebung (Security & Troubleshooting)

  • Sensible Dateien wie .env, secrets/, *.pem, *.key sollten zur Deny List von Claude Code hinzugefügt werden, um den Zugriff zu blockieren
  • Falls Befehle nach der Installation nicht erkannt werden, wird ein Neustart der Runtime oder eine Neuinstallation empfohlen
  • In Docker-Umgebungen lassen sich Pfadprobleme durch Setzen von CLAUDE_CONFIG_DIR beheben
  • Mit der Option --uninstall können alle Komponenten entfernt werden

Community und Lizenz

  • Unterstützung für Community-Ports für OpenCode, Gemini CLI und Codex
  • Veröffentlicht unter der MIT-Lizenz
  • „Claude Code is powerful. GSD makes it reliable.“ — Ein Werkzeug, das die Zuverlässigkeit von Claude Code stärkt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-19
Hacker-News-Kommentare

  • Ich habe früher Plan mode zusammen mit Superpowers verwendet, bin aber irgendwann zu dem Schluss gekommen, dass Plan mode allein ausreicht
    Solche Frameworks sind gut für Fire-and-forget-Aufgaben, die Recherche erfordern, aber es fühlte sich an, als würden sie mehr als das Zehnfache an Tokens verbrauchen
    Auch der Qualitätsunterschied bei den Ergebnissen war nicht groß, und ich bin oft an das Max-Plan-Limit gestoßen

    • Ich habe die brainstorm·design·implementation planning-Funktionen von Superpowers übernommen und sie an eine Ralph-basierte Implementierungsschicht gehängt
      Sobald die Implementierungsplanung abgeschlossen ist, läuft es automatisch weiter, ohne nach meinem Input zu fragen, aber es muss in einer Docker sandbox ausgeführt werden
      Das liegt an riskanten Berechtigungseinstellungen, aber ich halte das ohnehin für sicherer
      Im Moment funktioniert es gut und steigert die Produktivität, aber es fühlt sich wie eine Zwischenstation auf dem Weg an
    • Ich bin den umgekehrten Weg gegangen und von Plan mode zu Superpowers gewechselt
      Nach der Ankündigung der neuesten Version habe ich es erneut ausprobiert, und durch die mehrschichtigen cross-checks und self-reviews waren die Ergebnisse stabiler
      Man kann das auch manuell machen, aber Superpowers automatisiert diesen Prozess, was viel bequemer war
    • Ich habe dieselbe Aufgabe mit GSD und Plan Mode getestet: Plan Mode war in 20 Minuten bis zur Basisimplementierung durch, GSD brauchte mehrere Stunden
      GSD erzeugte Code mit Blick auf den Gesamtkontext des Projekts, während Plan Mode nur genau das Nötige auf MVP-Niveau implementierte
      Je nach Workflow oder Umfang der Aufgabe haben beide klare Vor- und Nachteile
    • Der Plan mode von GitHub Copilot hat sich seit der jüngsten Einführung von plan memory seltsam verändert
      Die Ausgaben sind ausschweifender geworden, während die Details paradoxerweise vager sind
      Es gibt nur mehr Schritte wie „design“ oder „figure out“, und dann springt es ohne Rückfragen direkt zur Implementierung
    • Ich hatte eine sehr ähnliche Erfahrung. Ich habe ein ganzes Wochenbudget an Claude-Abokosten und API-Credits verbrannt und dafür nur etwa 500 Zeilen Code bekommen
      Teilweise wurden Tests manipuliert oder völlig falsche Ergebnisse erzeugt
      Am Ende habe ich das MVP selbst manuell angeleitet und fertiggestellt, und das war deutlich effizienter

  • In letzter Zeit gibt es viel zu viele solcher Meta-Frameworks, aber ich habe kaum eines gesehen, das echte Produktivität nachgewiesen hätte
    Meistens sind sie nur Token-Verschwendung und verursachen Verschmutzung des Context Windows
    Letztlich war es am besten, es einfach zu halten, nur die nötigen Informationen zu geben und Plan → Code → Verify zu wiederholen

    • Im Artikel von Apenwarr „The AI Developer’s Descent Into Madness” wird die Situation, in der „ein Agent sein eigenes Framework baut“, satirisch beschrieben
    • Ich habe selbst ein Mini-Framework gebaut, das Claude und Codex kombiniert
      Wenn man sieht, wie Codex Fehler korrigiert, die Claude allein gemacht hat, merkt man, dass man sich nicht vollständig auf einen einzelnen Agenten verlassen kann
    • Ich nutze einen Ansatz für visuelles Spezifikationsdesign
      Ich entwerfe den Bildschirmfluss einer App als Bilder und exportiere das dann als strukturiertes Markdown, damit ein LLM den Kontext auf Screen-Ebene versteht
      Im Vergleich zu textbasierten Spezifikationen lassen sich damit fehlende Zustände oder Fehlerabläufe früher erkennen
    • Solche Meta-Frameworks sind letztlich nicht mehr als personalisierte Werkzeuge wie .vimrc oder .emacs.d
      Für die Ersteller sind sie nützlich, für andere wirken sie oft nutzlos

  • Ich glaube, dass Spec-Driven-Systeme zum Scheitern verurteilt sind
    Auf Englisch geschriebene Spezifikationen können echten Code und tatsächliches Verhalten nicht miteinander verknüpfen
    Dieses Problem wurde bereits durch automatisierte Tests gelöst
    Das Verhalten eines Systems muss in ausführbare Tests kodiert werden
    Auch wenn ein LLM die Implementierung erzeugt, sollte es zuerst die Tests schreiben und die Konsistenz mit mutation testing prüfen
    Ich habe das in diesem Artikel und in einem GitHub-Beispiel zusammengefasst

    • Spezifikationen in natürlicher Sprache sind nicht skalierbar, aber wenn man darauf basierend eine formale Spezifikation (formal spec) erstellt, gibt es Potenzial
      Letztlich muss sie in Form von Code ausgedrückt werden
    • Es gab auch einen Artikel mit dem Titel „A sufficiently detailed spec is code“, aber ich konnte die Ergebnisse von OpenAI nicht reproduzieren
      Siehe Link
    • Spec Driven Development klingt vom Namen her ähnlich wie TDD, geht aber in die genau entgegengesetzte Richtung
    • Tests nur als Ergebnis einer Spezifikation zu betrachten, ist fehlerhafte Logik
      Eine Spezifikation deckt einen viel breiteren Bereich ab als Tests
      Außerdem ignorieren LLMs Tests oft oder ändern sie nach Belieben

  • Ich benutze ein persönliches KI-System und überlege, ob ich es veröffentlichen soll
    Es ist so stark auf meine Arbeit zugeschnitten, dass mich der Gedanke belastet, zusätzlich noch eine öffentliche Version pflegen zu müssen
    Statt andere es direkt benutzen zu lassen, würde ich lieber nur die Muster als Referenz teilen

    • Wartung ist nicht zwingend nötig
      Im KI-Zeitalter hat schon das bloße Teilen von Inspiration und Ideen genügend Wert

  • Ich habe GSD bei einem Team-Hackathon ausprobiert, aber es brauchte viel zu lange, um die Codebasis zu verstehen, und der Token-Verbrauch war enorm
    Auch beim Erzeugen von Agent-Transkripten traten häufig Fehler auf
    Für ein paar kleine Features war es ein überdimensioniertes Werkzeug
    Die Lehre daraus war simpel — gute Spezifikationen schreiben + Plan mode iterieren ist deutlich effizienter

  • Ich fand die Design-Einschränkungen von Beads frustrierend und habe deshalb selbst ein ähnliches Tool gebaut
    Meine Version ist SQLite-basiert und ergänzt eine bidirektionale Synchronisierung mit GitHub
    Der Kern besteht darin, zuerst mit dem Modell zu sprechen und eine klare Spezifikationsdatei zu erstellen
    Mit einer solchen Datei vergisst das Modell nichts, und je mehr Details enthalten sind, desto höher ist die Qualität der Ausgabe
    Ich habe damit eine Idee, die ich schon lange mit Claude im Kopf hatte, als Prototyp umgesetzt, und das Ergebnis war besser als erwartet

    • Als „Geheimrezept“ taugt das kaum, denn RPI(research-plan-implement) ist bereits ein Konzept aus der offiziellen Dokumentation
      Das Modell bleibt ein stochastisches System, vollständige Erinnerung ist also unmöglich
      So zu tun, als hätte man ein völlig neues Geheimnis entdeckt, ist übertrieben

  • Ich habe Superpowers ausprobiert, und da dieses GSD ähnlich wirkt, war ich neugierig auf einen Vergleich

    • Ich habe beide verwendet, und GSD ist übermäßig komplex und langsam
      Der Quick mode verfehlt seinen eigentlichen Zweck, und Superpowers war als Mittelweg ganz brauchbar
    • Strukturierte Prompts helfen definitiv
      Wenn man solche Frameworks ins Repository legt und die KI das Framework selbst verbessern lässt, kann das auch für kreative Arbeit nützlich sein
      Trotzdem wirkt diese Struktur nur wie ein vorübergehender Hack, der wahrscheinlich von selbst verschwindet, sobald die Modelle ausreichend trainiert sind
    • Superpowers schreibt in der Planungsphase bereits den gesamten Code, und Unteragenten kopieren ihn dann einfach, was ineffizient war
      GSD hat dieses Problem gelöst, ist aber wegen der zu vielen Schritte langsam
    • Ich habe Superpowers getestet, als ich meinen Blog von Hugo auf Astro migriert habe
      Die von Superpowers erzeugte Spezifikation war detailliert, aber einige Funktionen fehlten, etwa RSS und Analytics, während eine kollaborativ erstellte Spezifikation mit Vorschlag für eine parallele Migration flexibler war
      Am Ende ließ ich Claude beide Spezifikationen vergleichen, zusammenführen und eine finale Version erstellen
      Siehe detaillierter Vergleich
    • Ich weiß nicht, ob man dafür wirklich einen CLI-Wrapper braucht
      Mit Claude skills lässt sich das eigentlich auch gut genug umsetzen

  • Ich habe GSD drei Monate lang intensiv genutzt, und es ist deutlich ausgereifter als das zuvor verwendete speckit
    Selbst komplexe Aufgaben werden zu 95 % automatisch erledigt
    Die restlichen 5 % schließe ich mit manuellen Tests ab
    Damit habe ich sogar ein SaaS-Produkt (whiteboar.it) veröffentlicht
    Das Modell selbst hat sich zwar ebenfalls weiterentwickelt, aber der Produktivitätsgewinn war eindeutig

    • Ich hatte eine ähnliche Erfahrung
      Weil mir das FreshBooks-Abo zu schade war, habe ich mit GSD selbst eine macOS-Swift-App gebaut
      Automatische Belegextraktion und Kategorisierung habe ich mit der Anthropic API umgesetzt
      Es begann als Web-App, entwickelte sich aber mit Funktionen wie Kameraintegration zu einer vollständigen Desktop-App weiter
      Dank GSD habe ich meine persönliche Buchhaltungs-App fertiggestellt

  • Das wirklich nötige Werkzeug ist am Ende eines, das Tokens spart
    Aber so etwas gibt es noch nicht
    Selbst Claude Code verbraucht in großen Projekten viel zu viele Tokens

  • Der Name für „dieses Bündel von Markdown-Dateien“ ist einfach zu fremdschämig

    • Unter einem Ordner namens „Languages“ wäre es vielleicht besser gewesen
    • Aber immer noch besser als „gstack“, oder nicht?