Source: https://aiprimetech.io/de/blog/gstack-claude-code-setup-guide/ Juli 15, 2026 · 7 Min. · Werkzeuge # gstack für Claude Code: Was der Workflow mit 23 Agenten tatsächlich leistet A Von [AI Prime Tech](https://aiprimetech.io/de/) · KI-unterstützt Ein Pull Request mit 14 Dateien kann Unit-Tests bestehen und dennoch aus drei völlig unterschiedlichen Gründen scheitern: Das Produktverhalten ist nicht ausreichend spezifiziert, die Benutzeroberfläche ist umständlich und in den Release Notes fehlt ein Migrationsschritt. Claude Code einmal mit „Prüfe diesen PR“ auszuführen, presst diese Anliegen in eine einzige überladene Unterhaltung. gstack verfolgt einen Ansatz mit klareren Vorgaben. Seine 23 rollenbasierten Tools unterteilen die Softwareauslieferung in Planung, Design, Implementierung, Review, Browser-QA, Release-Arbeiten und Dokumentation. Statt einen universellen Programmierassistenten zu bitten, einen Prozess zu improvisieren, rufen Sie eine Abfolge fokussierter Claude Code-Workflows auf, etwa /plan-ceo-review, /plan-eng-review, /review, /qaund /ship. Diese Unterscheidung ist wichtig. gstack ist nicht bloß ein Verzeichnis nützlicher Prompts, und seine „23 Agenten“ sind keine 23 autonomen Arbeitskräfte, die sich kontinuierlich im Hintergrund koordinieren. Es handelt sich um rollenspezifische Claude Code-Skills, die an bestimmten Punkten eines Entwicklungs-Workflows aufgerufen werden. Der Nutzen entsteht durch das Arbeitsmodell, das sie vorgeben; ebenso der größte Teil des Mehraufwands. ## gstack für Claude Code ist ein Betriebssystem, keine Prompt-Sammlung Das hilfreiche Denkmodell für gstack für Claude Code ist ein Entwicklungsbetriebssystem, das auf Claude Code aufsetzt. Jedes Tool gibt Claude eine Rolle, ein Verfahren und erwartete Ausgaben vor. Zusammen legen diese Tools fest, wie Software von einer Idee bis in den Produktivbetrieb gelangen sollte. Ein allgemeiner Prompt könnte lauten: ``` Review my implementation plan. ``` Ein rollenbasierter Workflow stellt eine enger gefasste Frage: ``` /plan-eng-review ``` Dieser Skill kann Claude anweisen, Architektur, Abhängigkeiten, Fehlerszenarien, Testbarkeit, Risiken beim Rollout und die Reihenfolge der Implementierung zu untersuchen. Ein produktorientierter Planungsskill kann denselben Plan auf Nutzen für die Anwender und Umfang prüfen. Ein designorientierter Skill kann Interaktionsdetails hinterfragen statt Backend-Grenzen. Der Unterschied liegt in der Wiederholbarkeit. Nicht jedes Teammitglied muss sich einen 40-zeiligen Review-Prompt merken oder eine eigene Checkliste erfinden. Der Skill enthält das Vorgehen. Der damit verbundene Kompromiss ist ebenso wichtig: gstack bringt das Vorgehen anderer in Ihr Repository. Es setzt voraus, dass mehrere Review-Durchgänge, explizite QA und strukturierte Release-Arbeit den Kontext und die Zeit wert sind, die sie beanspruchen. Bei Änderungen an Produktionssystemen ist das oft angemessen, für einen Tippfehler oder ein internes Skript mit zwei Zeilen jedoch übertrieben. ## Was die 23 rollenbasierten Tools tatsächlich abdecken Die genaue Zusammenstellung im Repository kann sich ändern. Deshalb betrachte ich die ausgecheckten SKILL.md Dateien als maßgeblich, statt mich auf Screenshots oder Beschreibungen zur Veröffentlichung zu verlassen. Entscheidend für die Architektur ist die Aufteilung der Verantwortlichkeiten. | Auslieferungsphase | Typische Tools | Was Claude tun soll | Wichtigste Einschränkung | Produktplanung | /plan-ceo-review, /office-hours | Problem, Nutzen für die Anwender, Umfang und Produktannahmen hinterfragen | Die Produktbewertung hängt weiterhin vom bereitgestellten Kundenkontext ab | Technische Planung | /plan-eng-review | Architektur, Datenfluss, Randfälle, Tests und Rollout prüfen | Kann undokumentierte Einschränkungen der Infrastruktur nicht überprüfen | Design | /plan-design-review, /design-consultation | Interaktionsstruktur, visuelle Entscheidungen und Benutzerfreundlichkeit prüfen | Text und Screenshots sind weniger aussagekräftig als die Beobachtung realer Nutzer | Kontrolle der Implementierung | /careful, Tools zum Absichern oder Einfrieren | Riskante Änderungen begrenzen und die Arbeit innerhalb festgelegter Grenzen halten | Einschränkungen können berechtigte übergreifende Änderungen verlangsamen | Code-Review | /review | Diffs auf Fehler, Regressionen, Sicherheitsprobleme und fehlende Tests untersuchen | Große Diffs können weiterhin die praktisch verfügbare Aufmerksamkeit für Reviews übersteigen | QA zur Laufzeit | /qa, /browse | Die Anwendung über einen Browser bedienen und ihr tatsächliches Verhalten prüfen | Die Einrichtung der Umgebung und die Testdaten bestimmen die Abdeckung | Version | /ship | Release-Prüfungen durchführen und Schritte für Commits oder Auslieferung koordinieren | Git- und Deployment-Berechtigungen müssen bewusst kontrolliert werden | Dokumentation | /document-release, /retro | Ausgeliefertes Verhalten, Release-Kontext und gewonnene Erkenntnisse festhalten | Generierte Texte müssen mit dem endgültigen System abgeglichen werden Deshalb wird die Bezeichnung „Sammlung von Prompts“ gstack nicht gerecht. Planungsergebnisse fließen in die Implementierung ein; die Implementierung erzeugt einen Diff; Review und QA prüfen diesen Diff; Auslieferung und Dokumentation bereiten das Ergebnis auf. Das erklärt auch, warum „Workflow mit 23 Agenten“ irreführend sein kann. Wenn Sie einen Skill aufrufen, lädt Claude Code tatsächlich Anweisungen und führt den zugehörigen Workflow mit den Tools aus, die in der aktuellen Sitzung verfügbar sind. Sofern ein Skill nicht ausdrücklich Arbeit delegiert, gibt es keine 23 dauerhaft laufenden Prozesse, die einen globalen Zustand teilen. ### Die Planung ist bewusst redundant Die Produkt-, Technik- und Design-Reviews überschneiden sich. Das ist beabsichtigt. Betrachten wir eine vorgeschlagene Funktion zum „Exportieren aller Kundenaktivitäten“: - Das Produkt-Review fragt, ob Nutzer einen vollständigen Export oder einen gefilterten Bericht benötigen. - Das technische Review fragt, ob der Export in den Arbeitsspeicher passt und wie Wiederholungsversuche funktionieren. - Das Design-Review fragt, wo Exportstatus, Fehlermeldungen und Bedienelemente für den Download erscheinen. - Die QA fragt, was bei fehlenden Datensätzen, abgelaufenen Links und unterbrochenen Aufträgen passiert. In der Praxis deckt diese Trennung Annahmen auf, die in einem allgemeinen Implementierungsplan untergehen. Der Preis dafür ist das wiederholte Laden von Kontext. Wenn der Plan bereits 8,000 Tokens umfasst, können drei Review-Durchgänge teuer werden und doppelte Beobachtungen hervorbringen. ### Review und QA sind unterschiedliche Aufgaben /review stützt sich hauptsächlich auf Belege aus dem Code: Diffs, Typen, Tests, Aufrufstellen und Konventionen des Repositorys. /qa und /browse kann Laufzeitbelege direkt aus der Anwendung sammeln. Diese Trennung ist eine der überzeugenderen Ideen von gstack. Ein Diff kann korrekt aussehen, während das gerenderte Ergebnis unbrauchbar ist. Umgekehrt kann eine Browserprüfung des Erfolgsfalls bestehen, während die Implementierung eine Race Condition oder eine Umgehung der Autorisierung einführt. Eine praktische Abfolge sieht so aus: ``` /plan-eng-review /careful # Implement the approved plan in Claude Code /review /qa /document-release /ship ``` Betrachten Sie dies nicht als verpflichtende Pipeline. Bei einer Datenbankmigration können ein technisches Review und die Rollback-Planung deutlich wichtiger sein als das visuelle Design. Bei einer CSS-Regression können /browse, Design-Review und QA den Kern des Workflows bilden. ## gstack installieren, ohne ihm blind zu vertrauen Bei einer typischen Installation auf Benutzerebene wird das Repository im Skills-Verzeichnis von Claude Code abgelegt und sein Setup-Skript ausgeführt: ``` git clone https://github.com/garrytan/gstack.git \ ~/.claude/skills/gstack cd ~/.claude/skills/gstack ./setup ``` Starten Sie Claude Code nach der Einrichtung neu, falls die neuen Befehle nicht sofort erkannt werden. Prüfen Sie anschließend die installierten Skills, statt davon auszugehen, dass die veröffentlichte Anzahl noch mit Ihrem ausgecheckten Stand übereinstimmt: ``` find ~/.claude/skills/gstack \ -name SKILL.md \ -print | sort find ~/.claude/skills/gstack \ -name SKILL.md | wc -l ``` Ein häufiger Fallstrick besteht darin, Installationsskripte auszuführen, weil das Repository beliebt ist, ohne zu lesen, was sie ändern. gstack enthält ausführbare Workflow-Mechanismen, nicht bloß inaktives Markdown. Prüfen Sie das Setup vor der Ausführung: ``` cd ~/.claude/skills/gstack git status --short git log -1 --oneline sed -n '1,240p' setup ``` Für einen Rollout im Team sollten Sie einen geprüften Commit festschreiben, statt stillschweigend dem neuesten Stand des Repositorys zu folgen: ``` git clone https://github.com/garrytan/gstack.git vendor/gstack cd vendor/gstack git checkout ./setup ``` Das genaue Installationsverfahren und die Abhängigkeiten können sich im Laufe der Projektentwicklung ändern. Deshalb sollten die aktuelle README und das Setup-Skript des Repositorys Vorrang vor kopierten Befehlen aus einem älteren Artikel haben – auch aus diesem. ## Den Workflow durch Claude Code-Berechtigungen begrenzen Einige gstack-Tools benötigen umfassenden Zugriff, um Dateien zu prüfen, Tests auszuführen, einen Browser zu bedienen oder mit Git zu interagieren. Das bedeutet nicht, dass jedes Tool uneingeschränkte Shell- und Release-Berechtigungen erhalten sollte. Eine projektbezogene .claude/settings.json kann eine restriktive Grundlage schaffen: ``` { "permissions": { "allow": [ "Bash(git status:*)", "Bash(git diff:*)", "Bash(npm test:*)", "Bash(npm run lint:*)" ], "deny": [ "Read(./.env)", "Read(./.env.*)", "Bash(git push:*)", "Bash(git push --force:*)" ] } } ``` Betrachten Sie dies als Beispielrichtlinie, nicht als universell direkt einsetzbare Datei. Passen Sie die Befehle an Ihren Paketmanager, Ihren Test-Runner und Ihre Claude Code-Version an. Das bewusste Verweigern von git push ist während der Evaluierung besonders nützlich. /ship kann weiterhin die Release-Bereitschaft prüfen, aber die abschließende Aktion mit Auswirkungen über das Netzwerk bleibt in menschlicher Hand. Sobald das Team den Workflow versteht, können Sie entscheiden, ob eine eng begrenzte Push-Berechtigung gerechtfertigt ist. Testen Sie browserorientierte Skills außerdem in einer Staging-Umgebung oder mit vorbereiteten lokalen Daten. Browserautomatisierung mit einer Produktionssitzung kann echte Datensätze verändern, wenn der Workflow ein destruktives Bedienelement anklickt. ## Zuerst einen Teil übernehmen, dann das gesamte System Ich würde einem Team nicht gleich am ersten Tag alle 23 Tools vorstellen. Beginnen Sie an den Stellen, an denen Ihr bestehender Prozess die meisten Informationen verliert. Eine sinnvolle Evaluierungsmatrix ist: | Problem im Team | Beginnen mit | Zunächst zurückstellen | Pläne übersehen Randfälle | /plan-eng-review | Vollständige Design- und Release-Abfolge | UI-Änderungen verursachen unbemerkte Regressionen | /browse, /qa, /plan-design-review | Workflows zur Produktstrategie | Reviews sind uneinheitlich | /review | Automatisierte Auslieferung | Releases fehlt Kontext | /document-release, /retro | Browser-Tools | Claude nimmt zu weitreichende Änderungen vor | /careful und Kontrollen des Änderungsumfangs | Übernahme des durchgängigen Workflows Setzen Sie die ausgewählten Tools bei mehreren echten Änderungen ein und halten Sie fest: - Welche Erkenntnisse führten zu Änderungen am Code oder am Umfang? - Welche Erkenntnisse waren doppelt? - Wie viel Kontext musste wiederholt werden? - Blieben generierte Artefakte mit der Implementierung synchron? - Welche Befehle erforderten Berechtigungen, die das Team in CI nicht gewähren würde? - Verstanden die Entwickler, wann sie welche Rolle aufrufen sollten? Der zusätzliche Kontextaufwand ist nicht theoretisch. Jede Rolle benötigt den Repository-Zustand, die Anforderungen und frühere Entscheidungen. In getrennten Sitzungen können Begründungen verloren gehen; in einer langen Sitzung können sich veraltete Annahmen ansammeln. Ich halte den genehmigten Plan in einer Repository-Datei fest, etwa in docs/plans/export-jobs.md, und weise dann jeden Workflow an, dieses Artefakt zu verwenden. Dauerhaft gespeicherte Dateien sind zuverlässiger als die Erwartung, dass Gesprächskontext als Projektgedächtnis dient. ## Dokumentiertes Verhalten gegenüber Werbeversprechen Die belegbare Aussage ist, dass gstack 23 rollenorientierte Claude Code-Tools und einen Workflow mit klaren Vorgaben bereitstellt, der den gesamten Softwarelebenszyklus abdeckt. Sie können dieses Verhalten überprüfen, indem Sie die installierten Skills lesen und in einem Test-Repository ausführen. Weitergehende Aussagen, etwa deutlich mehr Ergebnisse zu erzielen, ein Entwicklungsteam zu ersetzen oder Wochen auf Stunden zu verkürzen, bleiben Werbeversprechen, bis sie in Ihrer Umgebung nachgewiesen sind. Die Ergebnisse hängen von der Qualität des Repositorys, der Testabdeckung, der Mehrdeutigkeit der Aufgabe, der Modellwahl, den Berechtigungen und dem Entwickler ab, der die Arbeit beaufsichtigt. Auch die aktuelle Modellauswahl hebt diese Einschränkungen nicht auf. Sonnet 4.6 kann eine praktische Standardwahl für länger andauernde Programmierarbeit sein, während Haiku 4.5 sich für einfachere Klassifikations- oder Dokumentationsaufgaben eignen kann. Der 1M-Kontext von Fable 5 kann bei sehr umfangreichem Material helfen, und gpt-5.6-sol bietet in unterstützten Umgebungen eine weitere auf Entwicklung ausgerichtete Option. Keines davon verwandelt einen Rollen-Prompt in verifiziertes Produktwissen oder Belege aus dem Produktionsbetrieb. ## Praktische Empfehlungen - Betrachten Sie gstack als Entwicklungsprozess mit klaren Vorgaben, der durch Claude Code-Skills umgesetzt wird. - Verstehen Sie „23 Agenten“ als rollenbasierte Tools, nicht als automatisch koordinierte, dauerhaft aktive Worker. - Installieren Sie aus dem Repository, prüfen Sie setup, und legen Sie für die Nutzung im Team einen geprüften Commit fest. - Beginnen Sie mit zwei oder drei Workflows, die bekannte Probleme bei der Auslieferung beheben. - Halten Sie genehmigte Pläne und Entscheidungen in Dateien fest, damit die Rollen einen dauerhaften gemeinsamen Kontext haben. - Trennen Sie Code-Reviews von der Qualitätssicherung zur Laufzeit; sie erkennen unterschiedliche Fehlerklassen. - Beschränken Sie während der Evaluierung den Zugriff auf Geheimnisse, Produktionssitzungen, Git-Pushes und Deployment-Befehle. - Messen Sie hilfreiche Erkenntnisse und vermiedene Fehler, nicht die Anzahl ausgeführter Befehle. - Übernehmen Sie das vollständige Betriebssystem erst dann, wenn sein Prozessaufwand geringer ist als der Aufwand durch die Fehler, die es verhindert. [Programmierung](/de/blog/tag/coding/)[Claude](/de/blog/tag/claude/)[Agenten](/de/blog/tag/agents/)[Modelle](/de/blog/tag/models/) A [AI Prime Tech](https://aiprimetech.io/de/) AI Prime Tech veröffentlicht diesen Blog. Die Artikel werden mit KI-Unterstützung verfasst; prüfen Sie versionsspezifische Angaben wie Modell-IDs, Preise und Limits anhand der offiziellen Dokumentation, bevor Sie sich darauf verlassen. Günstigeren Zugang zur Claude API erhalten Ein API-Schlüssel für Claude Opus 5.5, Sonnet 5, Haiku 4.5 und Fable 5.1 sowie GPT-6 Modelle. Nutzungsbasierte Abrechnung, kein Abonnement. [API-Schlüssel erhalten →](/register) AI Prime Tech ist ein unabhängiges API-Gateway eines Drittanbieters. Claude™ und Anthropic® sind Marken von Anthropic, PBC. Eine Verbindung oder Unterstützung wird nicht impliziert.