Anatomie eines Claude Code Workflows: Wie aus Slash Commands ein KI-Entwicklungssystem wird

Das Tooling rund um KI-getriebene Entwicklungs-Workflows rund um Claude-Code entwickelt sich aktuell mit atemberaubender Geschwindigkeit.

Um zu verstehen, wie so ein Tool unter der Haube funktioniert, habe ich mir GSD (Get Shit Done) mal genauer angeschaut. In diesem Beitrag werde ich am Beispiel von GSD kurz erläutern, wie Spec-Driven-Development-Workflows funktionieren und welche Tools von Claude Code dabei zum Einsatz kommen. Das Ziel ist es, grundlegende Muster zu verstehen um diese in eigenen Workflows einzusetzen.

Die Idee von Spec-Driven Development

Kurz: die Idee ist es, detaillierte Anforderungen und das erwartete Verhalten einer Software vor der Implementierung zu definieren. Diese Spezifikation wird dann als Leitfaden für die Entwicklung und als Basis für Tests verwendet, um sicherzustellen, dass der Code die Anforderungen erfüllt.

Das Ziel ist es, besseren Context für die Implementierung durch ein LLM zu schaffen.

Tools, wie GSD, helfen durch ausgeklügelte Frage-Antwort Workflows dabei, Anforderungen klar zu definieren und lösen zusätzlich ein Kernproblem von Agentic-Coding, Context-Rot: der schleichende Qualitätsverlust, wenn sich die limitierten Token-Kontextfenster während langer Coding-Sessions füllen.

Was ist "Get-Shit-Done"

GSD zählt aktuell mit 23k Stars bei GitHub (Stand März 2026) unter den bekanntesten Spec-Driven-Development-Tools. Die Komplexität ist, im Vergleich zu anderen Tools wie BMAD oder Speckit, überschaubar.

Das System baut dabei vollständig auf native Features von Claude Code auf. Keine eigene Runtime. Kein Framework. Nur ~50 Markdown-Dateien, ein Node.js-CLI-Helfer und ein paar Hooks — die einen kompletten Software-Entwicklungszyklus orchestrieren, von der Idee bis zum ausgelieferten Code.

Der GSD-Workflow ist in eine Kette von Slash-Commands unterteilt. Jeder Befehl übernimmt eine Phase — und jede Phase läuft idealerweise in einem frischen Kontextfenster.

Befehl	Zweck
/gsd:new-project	Idee erfassen, Domäne recherchieren, Anforderungen & Roadmap definieren
/gsd:discuss-phase N	Implementierungsdetails für Phase N klären
/gsd:plan-phase N	Task-Breakdown für Phase N erstellen
/gsd:execute-phase N	Pläne parallel ausführen, ein Commit pro Task
/gsd:verify-work N	Validieren, dass Phase-Ziele erreicht wurden
/gsd:complete-milestone	Archivieren, Release taggen, nächsten Zyklus initialisieren

Hinter diesen Befehlen stecken ausschließlich Claude Code Bordmittel:

• 29 Skills — die Slash Commands, die ich als Nutzer aufrufe
• 12 Custom Agents — spezialisierte Subagenten für Recherche, Planung, Ausführung, Verifikation
• 2 Hooks — eine Statusleiste und ein Update-Checker, die im Hintergrund laufen

Bei der Installation werden die entsprechenden Dateien in die .claude/-Verzeichnisstruktur geschrieben und stehen damit auch unabhängig von GSD-Commands in jeder Claude-Session zur Verfügung.

Da mein Fokus aber auf den Tools hinter den Commands liegen soll, möchte ich alle, die GSD besser verstehen wollen, auf die offizielle Dokumentation verweisen.

Aus den oben beschriebenen Commands, habe ich mir /gsd:new-project ausgesucht und werde diesen Stück für Stück zerlegen und erklären, was bei der Ausführung passiert. Dieser Befehl steht an erster Stelle des Workflows und startet einen geführten Ablauf, der Fragen stellt, Informationen sammelt, Research-Agenten startet, daraus nachverfolgbare Anforderungen definiert und eine Roadmap für die weitere Ausführung bzw. Implementierung generiert.

Slash Commands, bzw. Skills

Jeder GSD-Command, der in Claude ausgeführt werden kann, ist in einer Markdown-Datei claude/commands/gsd/ definiert (daher das Präfix /gsd).

Die Datei für /gsd:new-project sieht so aus:

1---
2name: gsd:new-project
3description: Initialize a new project with deep context gathering and PROJECT.md
4argument-hint: "[--auto]"
5allowed-tools: [Read, Bash, Write, Task, AskUserQuestion]
6---

Oben steht der sogenannte Frontmatter, Meta-Daten für den Command:

• argument-hint signalisiert ein optionales Flag --auto (in GSD wird beim Setzen dieses Flags auf einige Nutzer-Rückfragen verzichtet).
• allowed-tools setzt explizite Privilegien für die Ausführung von Tools (alle internen Tools).
• description erscheint in der Command-Palette.

Unterhalb des Frontmatters folgt der eigentliche Prompt, strukturiert durch XML-Tags (hier etwas gekürzt):

1<objective>
2Initialize a new project through unified flow: questioning → research
3(optional) → requirements → roadmap.
4
5**Creates:**
6- `.planning/PROJECT.md` — project context
7- `.planning/config.json` — workflow preferences
8- `.planning/research/` — domain research (optional)
9- `.planning/REQUIREMENTS.md` — scoped requirements
10- `.planning/ROADMAP.md` — phase structure
11- `.planning/STATE.md` — project memory
12
13**After this command:** Run `/gsd:plan-phase 1` to start execution.
14</objective>
15
16<execution_context>
17@./.claude/get-shit-done/workflows/new-project.md
18@./.claude/get-shit-done/references/questioning.md
19@./.claude/get-shit-done/references/ui-brand.md
20@./.claude/get-shit-done/templates/project.md
21@./.claude/get-shit-done/templates/requirements.md
22</execution_context>
23
24<process>
25Execute the new-project workflow from @./.claude/get-shit-done/workflows/new-project.md end-to-end.
26Preserve all workflow gates (validation, approvals, commits, routing).
27</process>

Claude-Modelle wurden darauf trainiert, XML-Tags als strukturelle Grenzen zu erkennen, da bei Markdown-Headern nicht immer klar ist wo eine Sektion endet.

Die Sektionen folgen einer internen Konvention von GSD und teilen die Verantwortung auf: <objective> Was erreicht werden soll <execution_context> Welche Dateien geladen werden (via @-Referenzen) <process> Wie ausgeführt wird — meist ein Verweis auf eine Workflow-Datei

Die gesamte Logik — Questioning, Research, Requirements, Roadmap — steckt in der referenzierten Workflow-Datei.

@-Dateireferenzen für Context Injection

Im <execution_context> des Slash Commands werden über @./ Referenzen zu anderen Dateien eingefügt. Das hilft komplexe Prompts zu strukturieren:

• Slash Command: WAS darf getan werden (Berechtigungen, Ziel)
• Workflow-Datei: WIE es getan wird (Schritt-für-Schritt-Ablauf)
• References: Wiederverwendbares Wissen (Techniken, Regeln)
• Templates: Ausgabeformate (Dateistrukturen)

Vorteile fragmentierter Prompts

• Modularität: Einmal definieren (z.B. Fragetechniken), überall nutzen.
• Token-Effizienz: Subagenten laden nur das, was sie wirklich brauchen.
• Wartbarkeit: Klare Trennung von Was (Command) und Wie (Workflow).

Benutzereingabe über $ARGUMENTS

Wie oben beschrieben, kann das /gsd:new-project mit einem Flag --auto aufgerufen werden. Im Prompt kann über $ARGUMENTS auf alle Übergabeparameter zugegriffen werden. Im Prinzip wird die Variable einfach mit dem übergebenen Wert ersetzt. Im Beispiel von new-project-Workflow:

1<auto_mode>
2## Auto Mode Detection
3Check if `--auto` flag is present in $ARGUMENTS.
4
5**If auto mode:**
6(…) überspringe die interaktive Questioning-Phase
7</auto_mode>

Bash Scripte für effiziente Projekt Zustandserfassung

Der erste Schritt in fast jedem GSD-Workflow ist ein Bash-Befehl:

1INIT=$(node ./.claude/get-shit-done/bin/gsd-tools.cjs init new-project)

Viele Prompts benötigen Informationen über den Projektzustand — existiert .planning/? Gibt es schon Code? Welches Model-Profil ist konfiguriert? Da das über Claude Tools mehrere separate Aufrufe kosten würde, nutzt GSD aus Effizienzgründen ein Script, das diese Informationen als JSON-Object zurückgibt.

Dahinter steckt ein wichtiges Designprinzip: Deterministische Logik gehört in Code, nicht in Prompts. Dateien auf Existenz prüfen, Konfiguration laden, Phasennummern berechnen — das sind Aufgaben, bei denen ein Script zuverlässiger ist als ein LLM-Prompt.

AskUserQuestion — Interaktive Entscheidungen

GSD nutzt häufig eine Mischung aus Automatisierung und gezielten Entscheidungspunkten und nutzt dafür das Tool AskUserQuestion. Z.B. direkt nach dem Command-Aufruf:

1Use AskUserQuestion:
2
3- header: "Existing Code"
4- question: "I detected existing code in this directory. Would you like to map the codebase first?"
5- options:
6  - "Map codebase first" — Run /gsd:map-codebase to understand existing architecture (Recommended)
7  - "Skip mapping" — Proceed with project initialization

Der Nutzer kann dann im Terminal eine Auswahl treffen und Claude verzweigt den Ablauf entsprechend. Dabei unterstützt AskUserQuestion über das multiSelect-Flag sowohl mehrfache als auch exklusive Auswahl.

In new-project entsteht so eine Kette von Fragen mit Gates und Feedback-Schleifen:

• Brownfield-Erkennung — "Bestehenden Code analysieren?" (ja/nein)
• Readiness-Gate — "Genug Kontext für PROJECT.md?" (erstellen/weiter erkunden)
• Workflow-Einstellungen — Modus, Tiefe, Parallelisierung, Git-Tracking
• Agent-Toggles — Drei Fragen: Researcher, Plan-Checker, Verifier aktivieren?
• Requirements-Scoping — Pro Kategorie: Welche Features in v1? (multiSelect: true)
• Roadmap-Freigabe — "Passt die Roadmap?" (freigeben/anpassen/Datei ansehen)

Andere Abschnitte sind als Freitext-Gespräch gestaltet, z.B:

1**Open the conversation:**
2Ask inline (freeform, NOT AskUserQuestion):
3
4"What do you want to build?"
5Wait for their response. This gives you the context needed to ask intelligent follow-up questions.

Agents & das Task Tool — Parallele Orchestrierung

Nachdem der Claude-Prozess alle Informationen aufgenommen hat, wird die Recherche an 4 Agenten übergeben. Das hat nicht nur den Vorteil, dass diese parallel arbeiten, sondern auch, dass jeder Agent in einem frischen Kontextfenster startet.

1◆ Spawning 4 researchers in parallel...
2→ Stack research
3→ Features research
4→ Architecture research
5→ Pitfalls research

Das Task-Tool ist der Mechanismus dahinter. Jeder Aufruf startet einen neuen Subagenten als eigenständigen Prozess. Hier der Aufruf für "Stack research":

1Task(
2      prompt="
3            First, read ./.claude/agents/gsd-project-researcher.md ...
4            <research_type>Stack dimension for [domain]</research_type>
5            <question>What's the standard 2025 stack for [domain]?</question>
6            <project_context>[PROJECT.md summary]</project_context>
7            <output>Write to: .planning/research/STACK.md</output>
8      ",
9      subagent_type="general-purpose",
10      model="{researcher_model}",
11      description="Stack research")

prompt ist der vollständige Arbeitsauftrag. Der Agent bekommt alles, was er braucht, in einem einzigen Prompt.

model bestimmt, welches Claude-Modell der Agent nutzt. Der Wert kommt aus dem Init-Script und hängt vom gewählten Profil ab.

subagent_type legt fest, welche Art von Agent instanziiert wird.

Zwei Spawning-Patterns

GSD nutzt zwei verschiedene Ansätze, um Agenten ihre Rolle zuzuweisen:

1. General-Purpose mit manueller Rollenzuweisung. Die vier Researcher werden als subagent_type="general-purpose" gespawnt. Ihre Rolle bekommen sie über den Prompt: "First, read ./.claude/agents/gsd-project-researcher.md for your role and instructions." Der Agent liest seine eigene Definition als ersten Schritt.
2. Registrierter Agent-Typ. Der Roadmapper wird als subagent_type="gsd-roadmapper" gespawnt. Claude Code lädt die Agent-Definition aus .claude/agents/gsd-roadmapper.md automatisch — der Agent kennt seine Rolle, bevor er den Prompt sieht.

Die vier Researcher teilen sich dieselbe Agent-Definition (gsd-project-researcher.md), aber jeder bearbeitet eine andere Dimension (Stack, Features, Architecture, Pitfalls). Die Spezialisierung kommt aus dem Prompt, nicht aus der Rolle. Der Roadmapper hingegen hat eine einzigartige Aufgabe, die immer gleich ist.

Die Orchestrierung

Der Workflow orchestriert die Agenten in zwei Wellen:

1. Vier Researcher starten parallel. Jeder schreibt sein Ergebnis in eine eigene Datei unter .planning/research/.
2. Erst wenn alle vier fertig sind, startet der Synthesizer. Er liest die vier Ergebnis-Dateien und destilliert sie in eine SUMMARY.md:

1Task(
2      prompt="
3            Read these files:
4                  - .planning/research/STACK.md
5                  - .planning/research/FEATURES.md
6                  - .planning/research/ARCHITECTURE.md
7                  - .planning/research/PITFALLS.md
8            Write to: .planning/research/SUMMARY.md
9      ",
10      subagent_type="gsd-research-synthesizer",
11      model="{synthesizer_model}",
12      description="Synthesize research")

Danach startet eine dritte Welle: der Roadmapper, der die Synthese, die Requirements und den Projektkontext bekommt, um die Roadmap zu erstellen.

Das Muster ist immer: unabhängige Arbeit parallelisieren, abhängige Arbeit sequenzieren. Die Kommunikation zwischen Agenten läuft ausschließlich über Dateien.

Agent-Definitionen

Im Verzeichnis .claude/agents/ liegen Markdown-Dateien, die einem Agenten seine Identität geben. GSD hat dort zwölf Definitionen — vom Researcher über den Planner bis zum Verifier. Der Aufbau ähnelt dem der Commands: Frontmatter + Prompt-Body mit XML-Sektionen:

<role> Wer bin ich, was ist mein Auftrag, wer konsumiert meine Ergebnisse <philosophy> Leitprinzipien — z.B.: "Be comprehensive but opinionated. 'Use X because Y' not 'Options are X, Y, Z.'" <tool_strategy> Wann welches Tool nutzen, Confidence-Level-System <output_formats> Exakte Templates für jede Ausgabedatei <execution_flow> Schritt-für-Schritt-Ablauf <success_criteria> Checkliste, wann die Arbeit als fertig gilt

Persistenter State — Überleben zwischen Sessions

Claude hat kein Gedächtnis zwischen Kontextfenstern. Wenn ich /clear tippe oder eine neue Session starte, ist alles weg. GSD löst das pragmatisch und hält alles in Dateien im .planning/-Verzeichnis fest:

.planning/
      ├── PROJECT.md          ← Was bauen wir und warum
      ├── config.json         ← Workflow-Einstellungen
      ├── REQUIREMENTS.md     ← Was genau, mit IDs
      ├── ROADMAP.md          ← In welcher Reihenfolge
      └── STATE.md            ← Wo stehen wir gerade

Zusätzlich wird nach jedem abgeschlossenen Schritt nach Git committet.

So kann GSD in jeder neuen Session mit /gsd:resume-work den vorherigen Zustand rekonstruieren und daran anknüpfen.

Ein weiterer Vorteil: Jede Zwischenstufe ist inspizierbar. Wenn die Roadmap seltsam aussieht, kann ich in SUMMARY.md nachschauen, ob die Synthese das Problem ist. Wenn die Synthese falsch wirkt, schaue ich in die einzelnen Research-Dateien. Die gesamte Kette ist nachvollziehbar.

Hooks — Automatisierung im Hintergrund

Hooks sind Event-Listener, die Claude Code bei bestimmten Ereignissen automatisch auslöst. Die Konfiguration steckt in .claude/settings.json:

1{
2  "hooks": {
3    "SessionStart": [
4      { "hooks": [{ "type": "command", "command": "node .claude/hooks/gsd-check-update.js" }] }
5    ],
6    "PostToolUse": [
7      { "matcher": "Edit", "hooks": [{ "command": "npx prettier --write \"$FILE_PATH\"" }] },
8      { "matcher": "Write", "hooks": [{ "command": "npx prettier --write \"$FILE_PATH\"" }] }
9    ]
10  },
11  "statusLine": {
12    "type": "command",
13    "command": "node .claude/hooks/gsd-statusline.js"
14  }
15}

Drei Mechanismen sind hier im Einsatz:

SessionStart feuert einmal beim Öffnen einer neuen Session. GSD nutzt das für einen Update-Check: Ein Node.js-Script fragt die npm-Registry ab, ob eine neuere Version existiert.

PostToolUse feuert nach jedem Tool-Aufruf. Über den matcher wird gefiltert, welches Tool den Hook auslöst. Hier läuft Prettier automatisch nach jedem Edit und Write.

statusLine ist kein Hook im eigentlichen Sinne, sondern eine permanent laufende Anzeige am unteren Terminalrand. GSD zeigt dort das aktuelle Modell, die laufende Aufgabe und einen Fortschrittsbalken für die Kontextauslastung — der sich bei hoher Auslastung rot färbt.

Alles zusammen — Der Ablauf im Überblick

Fazit

Während der Nutzung von GSD, hatte ich ein komplexes System basierend auf mehreren Skripten erwartet. Im Nachhinein bin ich sehr überrascht, wie mächtig LLMs wie Claude-Code mittlerweile geworden sind und dass komplexe Workflows fast alleine mit Bordmitteln und Markdown-Dateien gebaut werden können.

Das Schöne ist, dass jede Anweisung in menschlicher Sprache ausformuliert ist und somit ein Großteil der Abstraktionsebenen, die normalerweise durch Code abgebildet werden, wegfallen.

Get-Shit-Done ist darauf ausgerichtet, eine breite Palette an kleineren bis mittelgroßen Projekten schnell automatisiert umzusetzen. Es passt nicht in jede Anforderung, geht vielleicht an manchen Stellen nicht tief genug und an anderen zu wenig ins Detail. Wenn man aber versteht, wie die Workflows umgesetzt sind, ist es nicht so schwer, eigene spezifische Systeme aufzubauen.