gstack für Claude Code: Was der Workflow mit 23 Agenten tatsächlich leistet

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.

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 <reviewed-commit-sha>
./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:

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.