gstack: KI-Software-Engineering-Stack

KI-Coding-Agenten können bereits Funktionen schreiben, Repositorien modifizieren, Tests ausführen und Pull Requests öffnen. Das schwierigere Problem ist es, einen Agenten dazu zu bringen, einen wiederholbaren Engineering-Prozess vor, während und nach dem Schreiben des Codes zu befolgen.

gstack, ein Projekt von Garry Tan, das ursprünglich um Claude Code herum aufgebaut wurde, wählt einen anderen Weg: Anstelle eines Coding-Agenten durch eine andere Plattform zu ersetzen, umhüllt es den bereits verwendeten Agenten mit spezialisierten Fähigkeiten, Browser-Tools, Reviews, Sicherheitskontrollen und Release-Prozessen. Das Projekt beschreibt das Ergebnis als ein virtuelles Engineering-Team – zweiunddreißig Spezialisten und acht Power-Tools, alles Slash-Befehle, alles Markdown, unter MIT-Lizenz.

Die Vergleichsziele hängen davon ab, welchen Teil von gstack Sie benötigen: Sammlung von Fähigkeiten wie Superpowers, Spezifikationssysteme wie OpenSpec und GitHub Spec Kit, Methodologien wie BMAD, Orchestrierungsplattformen wie Ruflo oder Ihre eigene gepflegte Sammlung von Agenten-Fähigkeiten. Einige dieser Lösungen werden mit gstack kombiniert, statt es zu ersetzen, und das größere Ökosystem, zu dem sie alle gehören, ist in der AI Developer Tools-Zentrale dieser Website kartografiert.

Was ist gstack?

gstack ist eine Open-Source-Sammlung von KI-Engineering-Workflows. In der Darstellung von gstack besteht die Softwareentwicklung aus mehreren verschiedenen Arten des Schließens, und die Erwartung, dass ein generischer Coding-Prompt all diese Aufgaben ausführt, ist eine schlechte Abstraktion – daher bietet das Projekt spezialisierte Fähigkeiten an:

• Produktexploration
• Produkt- und CEO-Review
• Architekturevaluierung
• Entwickler-Erfahrungs-Review (Developer Experience Review)
• Design-Review
• Implementierungs-Review
• Browser-basierte QA (Qualitätssicherung)
• Untersuchung und Debugging
• Sicherheitsanalyse
• Dokumentation
• Benchmarking
• Release-Vorbereitung
• Deployment
• Retrospektiven

Das Projekt stellt diese Rollen als ein virtuelles Engineering-Team dar: ein CEO, der das Produkt überdenkt, eine Engineering-Leitung, die die Architektur festlegt, eine Designerin, die „AI-Slop" erkennt, eine Reviewerin, die Produktionsfehler findet, eine QA-Leitung, die einen echten Browser öffnet, eine Sicherheitsbeauftragte, die OWASP- und STRIDE-Audits durchführt, und eine Release-Engineerin, die den PR ausliefert. Die Werkzeugkette um die Fähigkeit-Definitionen herum besteht aus TypeScript und Bun: ein Setup-Skript, generierte Fähigkeiten-Dokumentation, Sitzungs-Hooks, Status unter ~/.gstack/, ein gebundener Browser und eine Reihe von eigenständigen CLIs.

gstack ist kein Foundation-Modell und kein Ersatz für Claude Code; es ist eine Prozessschicht, die über einer Agenten-Harness läuft:

Zwei strukturelle Eigenschaften bestimmen, wo gstack einzuordnen ist. Erstens beschreibt das Projekt es als Prozess und nicht als Sammlung von Werkzeugen: Die Fähigkeiten laufen in der Reihenfolge ab, in der ein Sprint läuft – denken, planen, bauen, reviewen, testen, ausliefern, reflektieren – und jede Fähigkeit übergibt ihre Artefakte an die nächste, sodass /office-hours ein Design-Dokument schreibt, das /plan-ceo-review liest, und /plan-eng-review einen Testplan schreibt, den /qa aufgreift. Zweitens ist gstack nicht nur für Claude Code: ./setup erkennt automatisch die auf dem Gerät installierten Agenten, und ./setup --host <name> richtet Codex CLI, OpenCode, Cursor, Factory Droid, Kiro, Slate, OpenClaw und Hermes ein, während eine 2-kB-Anweisungs-Zusammenfassung im Repository Regeln lesende Agenten abdeckt, die überhaupt keine Installation benötigen.

Warum gstack existiert

Eine leere Claude Code Sitzung ist extrem flexibel, und diese Flexibilität ist auch eine ihrer Schwächen. Betrachten wir einen Funktionswunsch wie:

Füge organisationsebene API-Tokens zur Anwendung hinzu.

Ein fähiger Agent würde möglicherweise sofort das Repository inspizieren und damit beginnen, den Authentifizierungscode zu ändern, während ein Senior Engineer zuerst fragen würde, wer die Tokens besitzt, ob Benutzer mehreren Organisationen angehören können, wie Tokens widerrufen werden, ob Berechtigungen vererbt werden, was mit der bestehenden Authentifizierung passiert, ob Tokens ablaufen sollten, wie Secrets angezeigt werden und welche Audit-Ereignisse erforderlich sind. Der Agent könnte einige dieser Fragen schließlich entdecken, aber es gibt keine Garantie, dass er sie vor der Implementierung entdeckt. gstack verlagert diese Disziplin in wiederverwendbare Workflows: Anstatt Idee -> Coding-Agent -> Code, durchläuft die Änderung ein Produkt-Review, technische Planung, Architekturevaluierung, Implementierung, Code-Review, Browser-QA und Release als benannte Stufen, jeweils mit ihrem eigenen Befehl (die vollständige Sequenz befindet sich unten in Ein praktischer gstack-Workflow).

Das macht die KI nicht korrekt; es verändert die Wahrscheinlichkeitsverteilung ihrer Fehler. Der Agent wird dazu angehalten, Annahmen früher in Frage zu stellen, Beweise zu inspizieren, seine eigene Arbeit aus mehreren Perspektiven zu überprüfen und die Anwendung zu verifizieren, anstatt aufzuhören, wenn der Code kompiliert.

Wie gstack Markdown-Fähigkeiten in Prozess verwandelt

Die meisten Fähigkeiten von gstack stammen aus Markdown-Fähigkeitsdefinitionen. Eine Agenten-Fähigkeit kann beschreiben:

• wann sie ausgeführt werden soll
• welchen Kontext sie inspizieren soll
• welche Fragen sie stellen soll
• welche Werkzeuge sie verwenden darf
• welche Befehle sie ausführen soll
• welche Beweise sie sammeln muss
• welche Checks bestehen müssen
• wie das Ergebnis strukturiert sein soll

Eine solche Fähigkeit agiert irgendwo zwischen Dokumentation, wiederverwendbarem Prompt, Standard-Verfahrensanweisung und ausführbarer Workflow-Konfiguration. Die zugrunde liegenden Mechanismen werden in Claude Skills und SKILL.md für Entwickler behandelt; gstack fügt Infrastruktur auf dieser Primitivschicht hinzu: generierte Fähigkeitsdefinitionen, Start- und Abschluss-Hooks, Statusverwaltung unter ~/.gstack/, Browser-Automatisierung, Sicherheitsmechanismen, Repository-Inspektion, optionalen Telemetrie-Service, Cross-Session-Gedächtnis, verwaltet von /learn, und optionales persistentes Wissen durch das separate GBrain-Projekt, das /setup-gbrain als lokale PGLite-Datenbank, Supabase-Projekt oder entfernten MCP-Endpunkt aufbauen kann.

Die wichtigsten gstack-Fähigkeiten

Die genaue Sammlung ändert sich schnell, aber mehrere Workflows veranschaulichen, wie das System genutzt werden soll.

office-hours

/office-hours gehört an den Anfang eines Projekts oder einer Funktion. Es führt sechs drängende Fragen zum Problem durch, bevor Code geschrieben wird, und rahmt in dem durchgearbeiteten Beispiel im README einen Wunsch für eine „tägliche Briefing-App" als persönlichen Chief-of-Staff-KI um und schreibt dann das Design-Dokument, das jede abwärtsgelegene Fähigkeit liest. Für vage Eingaben wie „wir brauchen eine bessere Projektsuche" ist die Ausgabe eine Anforderung, nicht Code.

plan-ceo-review

/plan-ceo-review untersucht die produktspezifischen Annahmen hinter einem Plan. Es arbeitet in vier Scope-Modi – Expansion, Selektive Expansion, Scope erhalten, Reduktion – und kann den Scope in Frage stellen, fehlende Chancen identifizieren, unnötige Arbeit reduzieren oder vorschlagen, das Problem anders zu rahmen. Es läuft, bevor die Anforderungen festgelegt sind, eine Stufe, die die meisten Coding-Agenten-Tools nicht haben.

plan-eng-review

/plan-eng-review verlagert die Perspektive zum Engineering: Architektur, Datenfluss, Diagramme, Edge-Cases, eine Testmatrix, Fehlerszenarien und Sicherheitsbedenken. Es bleibt vom Produkt-Review getrennt, da das Zusammenfügen beides in einen großen Prompt dazu führt, dass das Modell Produkt- und Implementierungsentscheidungen vermischt.

plan-design-review und design-review

gstack behandelt visuelles und Interaktionsdesign als eigenständige Disziplin. /plan-design-review bewertet jede Design-Dimension von 0 bis 10, beschreibt, wie eine 10 aussieht, und bearbeitet den Plan, um die Lücke zu schließen, mit „AI-Slop"-Erkennung als benanntem Check. Das spätere /design-review führt das gleiche Audit an der tatsächlichen Implementierung durch und behebt das Gefundene mit atomaren Commits und Vorher/Nachher-Screenshots. Für Web-Anwendungen paaren sich beide mit der Browser-Automatisierung von gstack.

review

/review führt ein Engineering-Review an Repository-Änderungen aus der Perspektive eines Staff-Engineers durch: Es behebt offensichtliche Befunde automatisch, markiert den Rest zur Genehmigung und behält eine beratende Vereinfachungsperspektive für überbaute Code bei. Erfolgreich geschriebener Code ist nicht unbedingt Code, der gemergt werden sollte.

investigate

/investigate erzwingt eine systematische Debugging-Regel, die das Projekt als Eisernes Gesetz bezeichnet: keine Fixes ohne Untersuchung. Es verfolgt den Datenfluss, testet Hypothesen und stoppt nach drei fehlgeschlagenen Fix-Versuchen, anstatt weiter zu thrashen. Es aktiviert auch automatisch /freeze, das Bearbeitungen auf das Modul unter Untersuchung einschränkt.

qa und qa-only

/qa lässt den Agenten einen Browser bedienen, mit der Anwendung interagieren, Fehler finden, sie mit atomaren Commits beheben, neu verifizieren und für jeden Fix einen Regressionstest generieren. /qa-only führt dieselbe Methodik nur berichtend aus. Viele Coding-Agenten halten die Verifikation bei „Tests bestanden" auf; für eine Web-Anwendung ist der Browser der Ort, an dem Integrationsfehler, Layoutprobleme, falsche Flows, Authentifizierungsfehler und JavaScript-Ausnahmen normalerweise sichtbar werden.

ship, land-and-deploy, und canary

Die Release-Kette besteht aus drei Fähigkeiten und nicht aus einer. /ship synchronisiert main, führt Tests aus, auditiert die Abdeckung, pusht und öffnet den Pull Request und legt ein Test-Framework an, falls das Projekt keines hat. /land-and-deploy merget, wartet auf CI und das Deployment und verifiziert die Produktionsgesundheit. /canary führt dann eine Post-Deploy-Überwachungsschleife aus, die auf Konsolenfehler, Performance-Regressionen und Seitenfehler achtet.

autoplan, spec, learn, und retro

/autoplan führt die CEO-, Design-, DX- und Engineering-Review-Pipeline automatisch aus – Engineering immer zuletzt, damit das Shipping-Gate den final geänderten Plan prüft – und bringt nur Geschmacksentscheidungen zur Genehmigung ein. /spec wandelt vage Absichten in eine präzise, ausführbare Spezifikation in fünf Phasen (Warum, Scope, Technisch mit obligatorischem Code-Lesen, Entwurf, Datei) mit einem externen Review-Qualitätsgate vor der Einreichung um. /learn verwaltet, was gstack über Sitzungen hinweg gelernt hat – Muster, Fallstricke und Präferenzen – mit Review, Suche, Pruning und Export. /retro erstellt eine teambewusste wöchentliche Retrospektive; /retro global führt sie über alle Ihre Projekte und KI-Tools durch.

Browser-Automatisierung in gstack

Auf unterstützten macOS-Systemen (macOS 15+) steuert gstack zuerst den Aside Browser – Ihren echten Browser, mit Ihren echten angemeldeten Sitzungen, in Tabs, die der Agent für sich selbst öffnet und schließt, wenn er fertig ist. Wenn Aside nicht verfügbar ist, fällt gstack auf seinen eigenen Chromium-basierten Engine zurück, die ./setup baut und die einen persistenten Daemon ausführt, anstatt für jeden Befehl einen neuen Browser zu starten:

Persistenter Browser-Status ermöglicht es Cookies, Authentifizierungssitzungen und Tabs, zwischen Operationen zu überleben, was browser-basierte QA praktikabel macht. /open-gstack-browser stellt die Fallback-Engine sichtbar zur Verfügung, mit einer Sidebar-Agent, der schnelle Aktionen (Klick, Navigation, Screenshot) an Sonnet und Lese- oder Analyse-Operationen an Opus routet. Wenn der Agent auf ein CAPTCHA, eine Authentifizierungsmauer oder eine MFA-Anfrage trifft, öffnet $B handoff einen sichtbaren Browser auf derselben Seite mit intakten Cookies und Tabs; Sie lösen es auf, und $B resume setzt dort fort, wo der Agent aufgehört hat. Der Agent schlägt eine Handoff automatisch nach drei aufeinanderfolgenden Fehlern vor. /pair-agent teilt den Browser mit anderen Agenten – OpenClaw, Hermes, Codex, Cursor oder allem, was curl kann – mit scopierten Tokens, Tab-Isolation, Rate-Limiting und per-Tab-Aktivitätszuordnung.

Der persistente Engine erhöht auch die Sicherheitsfläche, da ein Agent mit Zugriff auf authentifizierte Sitzungen ein bedeutsames Privileg hält. gstack liefert eine geschichtete Prompt-Injection-Verteidigung dafür: Inhaltsfilter (Datamarking, Entfernen von unsichtbaren Elementen, ARIA-Säuberung, URL-Sperreliste) bei jedem Seitenlesen, plus einen lokalen ML-Klassifizierer in einem Sidecar-Subprozess, der seitenabgeleitete Inhalte scannt, bevor der Agent sie sieht, mit einem Urteils-Kombinator, der die Zustimmung des Klassifizierers vor dem Blockieren erfordert. Seiteninhalte werden als nicht vertrauenswürdige Eingabe behandelt – der Agent nimmt Syntax von einer Seite, niemals Anweisungen. Checks vor und während der Nutzung browser-gesteuerter QA:

• Entscheiden Sie im Voraus, in welchen authentifizierten Umgebungen der Agent arbeiten darf, und bevorzugen Sie ein isoliertes Profil für QA-Arbeit, wenn der Fallback-Engine verwendet wird.
• Wissen Sie den Notfall-Kill-Schalter: GSTACK_SECURITY_OFF=1 deaktiviert die Sicherheitsschicht – lassen Sie ihn nicht eingestellt.
• Der persistente Daemon behält Cookies und Sitzungen zwischen Läufen bei, daher beenden Sie ihn, wenn Sie fertig sind, und stellen Sie sicher, dass nichts weiterläuft, beispielsweise ps aux | grep -i chrom.
• Lesen Sie die Hooks und Sicherheitsmechanismen im geklonten Repository, bevor Sie sie aktivieren – es sind einfache Dateien, daher überprüfen Sie sie so, wie Sie CI-Konfiguration überprüfen würden.
• Führen Sie nach einem Update des Klons ./setup neu aus, damit generierte Komponenten mit den Fähigkeitsdefinitionen synchron bleiben.

Sicherheits-Guardrails und Zweitmeinungen

Drei Power-Tools wirken als sitzungsweite Sicherheits-Schalter. /careful warnt vor destruktiven Befehlen – rm -rf, DROP TABLE, Force-Push, git reset --hard – und wird aktiviert, indem man „be careful" sagt; rekursive Löschen des Root- oder Home-Verzeichnisses und Force-Pushes auf die Default-Branch sind hart abgelehnt. /freeze beschränkt Datei-Editierungen auf ein Verzeichnis, damit der Agent während des Debuggings nicht „irrelevante" Code „beheben" kann, und /guard aktiviert beide gleichzeitig.

Zweitmeinungs-Reviews überschreiten Harnesses: Auf Claude Code sendet /codex die Arbeit an OpenAI Codex CLI für ein unabhängiges Review, eine Herausforderung oder eine Konsultation; auf den anderen Harnesses tut /claude-code das Gegenteil. Jeder Bericht identifiziert den Anbieter, der das Review tatsächlich abgeschlossen hat.

Ein praktischer gstack-Workflow

Sie benötigen nicht jede gstack-Fähigkeit für jede Änderung. Ein vernünftiger Funktions-Workflow:

1. /office-hours
2. /plan-ceo-review
3. Erstellung des Implementierungsplans
4. /plan-eng-review
5. Implementierung
6. /review
7. /qa
8. /ship

Welche Review-Fähigkeiten hinzugefügt werden, hängt davon ab, für wen die Software entwickelt wird:

Für einen trivialen Bug-Fix reicht oft, direkt zu Untersuchung, Implementierung, Review und Tests zu gehen. Eine toolneutrale Version der gleichen Form – Spezifikation, Design, Aufgaben, Implementierung, Validierung – ist in Spezifikations-getriebener Entwicklungs-Workflow von Anforderungen zu Code. Die README des Projekts beschreibt das parallele Ausführen von zehn bis fünfzehn dieser Sprints, jeder in seinem eigenen isolierten Workspace; die Sprint-Struktur ist das, was laut Projekt verhindert, dass parallele Agenten zu Quellen des Chaos werden.

gstack installieren

Die aktuelle Installation erwartet eine funktionierende Claude Code-Einrichtung, Git, Bun v1.0+ und, auf Windows, Node.js – Bun hat einen bekannten Bug mit Playwrights Pipe-Transport auf Windows, daher fällt der Browse-Server dort auf Node.js zurück. Wenn Sie Claude Code noch nicht konfiguriert haben, beginnen Sie mit der Claude Code Übersicht zuerst. Auf macOS wird der Aside-Browser (macOS 15+) für die Browser-Fähigkeiten empfohlen; ohne ihn wird der gebundene Chromium-Daemon verwendet.

1. Verifizieren Sie Ihre Voraussetzungen: git --version und bun --version (die Werkzeugkette ist Bun-basiert).

2. Klonen Sie gstack in das Claude Skills-Verzeichnis:

   git clone --single-branch --depth 1 \
     https://github.com/garrytan/gstack.git \
     ~/.claude/skills/gstack
   

3. Führen Sie das Setup-Skript aus dem geklonten Verzeichnis aus:

   cd ~/.claude/skills/gstack
   ./setup
   

   Setup installiert und generiert die Komponenten, die von den unterstützten Fähigkeiten benötigt werden, und baut den gebundenen Browser; ein Chromium-Installationsfehler ist Best-Effort, Setup protokolliert den Grund, beendet die Registrierung jeder Fähigkeit und gibt aus, welche Fähigkeiten betroffen sind.

4. Fügen Sie eine ## gstack-Sektion zum Projekts CLAUDE.md hinzu. Die Installationsanweisungen des Projekts umfassen diesen Schritt, und es ist das, was Claude Code dazu bringt, die Fähigkeiten zu routen: Verwenden Sie /browse von gstack für alle Web-Browsings, verwenden Sie niemals mcp__claude-in-chrome__*-Werkzeuge, und listen Sie die verfügbaren Fähigkeiten auf.

5. Verifizieren Sie die Installation: Stellen Sie sicher, dass die generierten Dateien im geklonten Verzeichnis vorhanden sind, starten Sie eine Claude Code-Sitzung und führen Sie /office-hours auf einem Scratch-Projekt aus, um zu bestätigen, dass die Fähigkeit erkannt wird.

Team-Modus

Für Repositorien bietet gstack eine teamorientierte Einrichtung, bei der Entwickler einen Workflow teilen, anstatt individuell konfigurierte Umgebungen zu haben:

(cd ~/.claude/skills/gstack && ./setup --team) && \
  ~/.claude/skills/gstack/bin/gstack-team-init required && \
  git add .claude/ CLAUDE.md && \
  git commit -m "require gstack for AI-assisted work"

required blockiert KI-gestützte Arbeit im Repository ohne gstack; ersetzen Sie es durch optional, um Teammitglieder anzutreiben, anstatt sie zu blockieren. Es werden keine Dateien in das Repository eingebacken: Jede Claude Code-Sitzung beginnt mit einem schnellen Auto-Update-Check (drosselt auf einmal pro Stunde, netzwerkfehlersicher, still), was Versionsdrift im Team beseitigt. Persönliche Konfiguration verbessert einen Entwickler; Repository-Ebene-Konfiguration schafft eine geteilte Engineering-Konvention.

Andere Harnesses, Upgrades und Deinstallation

• Andere Agenten: ./setup --host codex, --host opencode, --host cursor, --host factory, --host kiro, --host slate, --host openclaw und --host hermes installieren die Fähigkeiten in das eigene Skills-Verzeichnis jedes Agenten. Die 2-kB-Anweisungs-Zusammenfassung in agents-digest/gstack-AGENTS.md deckt Agenten ab, die nur Regeldateien lesen.
• Befehlsbenennung: Fähigkeiten registrieren sich standardmäßig mit kurzen Namen (/qa, /review); ./setup --prefix wechselt zu namespaced Namen (/gstack-qa), was wichtig ist, wenn Sie andere Skill-Packs neben gstack ausführen.
• Upgrades: Führen Sie ./setup nach einem git pull neu aus (erforderlich auf Windows, wo Installationen Datei-Kopien sind), oder verwenden Sie die /gstack-upgrade-Fähigkeit; die Einstellung von auto_upgrade: true in ~/.gstack/config.yaml hält die Installation automatisch aktuell.
• Telemetrie ist standardmäßig aus und fragt beim ersten Start nach der Opt-in. Wenn Sie opt-in, sendet es den Fähigkeitsnamen, die Dauer, Erfolg/Fehlschlag, die gstack-Version und das Betriebssystem – niemals Code, Dateipfade, Repository-Namen oder Prompts. gstack-config set telemetry off deaktiviert es jederzeit.
• Deinstallation: ~/.claude/skills/gstack/bin/gstack-uninstall entfernt Fähigkeiten, Symlinks, ~/.gstack/-Status, projektlokalen Status, Browse-Daemons und Hook-Registrierungen.

Installation verifizieren und häufige Fehler beheben

• ./setup schlägt fehl – Stellen Sie sicher, dass Bun in Ihrem PATH ist, mit bun --version; die generierten Komponenten werden von der Bun-Werkzeugkette gebaut.
• Fähigkeiten werden von Claude Code nicht erkannt – Stellen Sie sicher, dass der Klon tatsächlich in ~/.claude/skills/gstack liegt, dass das Projekt CLAUDE.md eine gstack-Sektion hat, und führen Sie ./setup neu aus.
• /browse meldet NEED_ASIDE oder ASIDE_NOT_RUNNING – Die Probe sagt Ihnen, dass sie den Fallback-Browser verwenden wird. Das ist normal auf Linux und Windows; auf macOS bedeutet es, dass Aside nicht geöffnet oder angemeldet ist.
• Der Fallback-Browser schlägt fehl – cd ~/.claude/skills/gstack && bun install && bun run build.
• Veraltete Installation nach einem Update – Führen Sie /gstack-upgrade aus, oder setzen Sie auto_upgrade: true in ~/.gstack/config.yaml.

gstack ausprobieren, ohne alles zu adoptieren

Verwenden Sie gstack für eine echte, aber nicht kritische Funktion, anstatt Ihren Entwicklungsprozess zu migrieren. Der schnelle Start des Projekts ist derselbe Versuch, und er endet mit „stop there":

1. /office-hours – Problemdefinition
2. /plan-ceo-review – Produktüberlegung
3. /review – Engineering-Verifikation, nach der Implementierung
4. /qa – Laufzeit-Verifikation, für Web-Projekte

Wenn diese Stufen Befunde hervorbringen, die Ihr normales Claude Code-Workflow verpasst, ist der Rest des Systems lohnend zu erkunden; wenn sie größtenteils zusätzlichen Text erzeugen, ohne Engineering-Entscheidungen zu ändern, wird die Adoption des gesamten Stacks wahrscheinlich nicht helfen.

Was gstack gut kann

Getrennte Engineering-Rollen. Anstelle einer riesigen „sei ein Senior Engineer"-Anweisung erhalten Produktstrategie, Architektur, UX, QA, Sicherheit und Release-Engineering jeweils ihren eigenen Modus des Schließens.

Verifikation, nicht nur Generierung. Review, Browser-QA mit Regressionstest-Generierung, Sicherheitsaudits, Benchmarking und die Ship-Deploy-Canary-Kette sind erste-Klasse-Workflows in gstack, nicht optionale Nachgedanken.

Inspektierbar. Ein großer Teil der Verhaltensschicht sind einfache Markdown-Dateien, die Entwickler lesen und modifizieren können, im Gegensatz zu internen Workflows einer proprietären autonomen Agenten. Das Repository liefert auch Audit-Werkzeuge für den Stack selbst: gstack-context-bill berichtet, was ein installierter Fähigkeiten-Baum in Tokens kostet, und gstack-egress schreibt einen Hash-verketteten Beleg für jede Off-Machine-Sendung, einschließlich Telemetrie.

Team-Infrastruktur. Fähigkeiten können Engineering-Konventionen kodieren – anstatt

Denken Sie daran, API-Kompatibilität zu überprüfen, Integrations_tests auszuführen,
das Browser-Konsol zu inspizieren und das Changelog zu aktualisieren.

in jeder Sitzung zu tippen, leben die Anforderungen in einem wiederverwendbaren Workflow, und der Team-Modus macht diesen Workflow zu einer Repository-Anforderung.

Wo gstack zu viel sein kann

gstack ist absichtlich Meinungsvertritt, und das begrenzt seinen Pass: Eine reife Organisation kann bereits Architektur-Review-Verfahren, Release-Werkzeuge, CI-Gates, QA-Automatisierung, Sicherheitsscanning, ADR-Konventionen, Spezifikationstemplates und Code-Review-Richtlinien haben, und das Hinzufügen einer anderen vollständigen Methodologie darüber schafft Überlappung statt Klarheit.

Es gibt auch einen Kontext- und Token-Kosten: Jede zusätzliche Review-Stufe fügt Repository-Inspektion, Modell-Schließung und potenziell mehr externe Modellaufrufe hinzu. Das Ziel ist der minimale zuverlässige Prozess, der benötigt wird, um korrekte Software auszuliefern, nicht eine maximale Anzahl von KI-Reviews; gstack-context-bill kann quantifizieren, was Ihr installierter Fähigkeiten-Satz pro Sitzung tatsächlich kostet, bevor Sie entscheiden, wie viel davon Sie behalten.

gstack funktioniert am besten als Werkzeugkasten, dessen Workflows Sie auswählen und anpassen, nicht als Zeremonie für jeden Commit.

gstack-Alternativen und Kombinationen

Die nächsten Alternativen und die Schicht, die jede einnimmt:

gstack + Superpowers: Implementierungsdisziplin innerhalb der Rollen

Beide sind Frameworks für Fähigkeiten, daher überlappen sie am meisten. Die Aufgabenteilung bei ihrer Kombination: gstack liefert die umgebenden Rollen – Produkt, Design, QA, Release – während Superpowers die Disziplin innerhalb der Implementierungsphase liefert (TDD, Planung vor Implementierung, systematisches Debugging, Subagent-Review). Installieren Sie beide Fähigkeit-Sätze, und streichen Sie dann die überlappenden Fähigkeiten, damit der Agent nie zwei widersprüchliche Anweisungen für dieselbe Phase sieht; wenn Befehlsnamen kollidieren, installieren Sie gstack mit ./setup --prefix, damit seine Fähigkeiten als /gstack-* registriert werden und mit dem anderen Pack koexistieren. Installations- und Workflow-Details finden sich in der Superpowers-Schnellstart.

gstack + OpenSpec: Durable Spezifikationen, Live-Reviews

OpenSpec hält Mensch und Agenten um explizite Änderungs-Spezifikationen zusammen – Artefakte für die vorgeschlagene Änderung, Spezifikationen, Design-Entscheidungen und Implementierungsaufgaben. Die Eigenschaft ist Persistenz: Ein Chat-Gespräch verschwindet in der Kontext-Historie, aber eine Spezifikation bleibt im Repository, wo Menschen und zukünftige Agenten-Sitzungen sie überprüfen können. gstack fügt das Produkt-Review hinzu, bevor die Spezifikation existiert, und das Review und QA, nachdem sie implementiert ist:

Eine konkrete Sequenz: Führen Sie /office-hours und /plan-ceo-review aus, erfassen Sie das Ergebnis als OpenSpec-Änderung, implementieren Sie dagegen, und führen Sie dann /review und /qa aus. Beachten Sie, dass gstack auch seine eigene /spec-Fähigkeit liefert, die Spezifikationen unter ~/.gstack archiviert; wenn OpenSpec die Spezifikation besitzt, lassen Sie gstacks /spec aus dem Prozess heraus, damit die beiden nicht divergieren. Der OpenSpec-Schnellstart deckt den Erkunde-Vorschlage-Anwenden-Archivieren-Loop im Detail ab.

gstack + GitHub Spec Kit: Wählen Sie eine Planungsrückgrat

Der Kern-Workflow von Spec Kit ist eine Sequenz expliziter Stufen – Verfassung, Spezifikation, Planung, Aufgaben, Implementierung, Konvergenz – und es hat sich auf Bug-Fixing, Ideenbewertung, Erweiterungen, Presets und Integrationen erweitert. Da sowohl Spec Kit als auch gstack die Planungsstufe in den Mittelpunkt stellen, verdoppelt das Ausführen beider voller Flows die Arbeit. Wenn Nachverfolgbarkeit von Anforderungen und formale Stufen wichtig sind, lassen Sie Spec Kit das Spezifikations-Rückgrat besitzen und verwenden Sie gstack für die Schichten, die Spec Kit nicht erzwingt – Produkt-Review, Design-Review, Browser-QA und Shpping. Ein breiterer Vergleich spezifikations-getriebener Setups, einschließlich Kiro und Claude Code, ist in GitHub Spec Kit vs Kiro vs Claude Code SDD Workflows.

BMAD und Ruflo: Verschiedene Achsen

BMAD ist eine breitere KI-getriebene Entwicklungsmethodologie, deren adaptive Workflows Produktdenken, Spezifikationen, Architektur und Implementierung abdecken und die Zeremonie auf die Größe der Arbeit skalieren. Es und gstack spielen beide die Rolle des Prozess-Rückgrats, daher wählen Sie eines als Rückgrat, anstatt beide vollständig auszuführen; gstacks individuelle Fähigkeiten können immer noch neben einer Methodologie ausgewählt werden.

Ruflo zielt auf Multi-Agenten-Orchestrierung ab: koordinierte Arbeiter, geteiltes Gedächtnis, Schwärme. gstack wendet mehrere Spezialistenperspektiven auf einen Engineering-Workflow an; eine Orchestrierungsplattform wendet mehrere ausführende Agenten auf ein Engineering-Ziel an. Die Grenze verschwimmt – gstack kann externe Werkzeuge und zusätzliche Modelle aufrufen, und Orchestrierer können strukturierte Engineering-Rollen implementieren – aber die Entscheidung ist unabhängig: Wenn das Problem ist, dass der Agent Engineering-Disziplin überspringt, ist ein Fähigkeiten-Framework der direkte Fix; wenn er zehn Agenten parallel über viele Aufgaben und Repositorien ausführt, sitzt ein Orchestrierer über einem Workflow wie gstack, anstatt ihn zu ersetzen.

Eigene Fähigkeiten: Die am meisten anpassbare Schicht

Sie können auch das Framework vollständig überspringen und eine kleine Sammlung von Fähigkeiten für die Verfahren erstellen, die Ihr Team bereits folgt:

skills/
  architecture-review/
  api-review/
  database-migration-review/
  incident-analysis/
  release-check/
  security-review/

Jede Fähigkeit kodiert organisations-spezifisches Wissen, das ein generisches Framework nicht kennen kann. Eine Datenbank-Migrations-Fähigkeit kann Rollback-Analyse, Tabellen-Sperr-Analyse, Index-Auswirkungs-Review, Migrationsdauer-Schätzung, Deployment-Reihenfolge und Kompatibilität mit der vorherigen Anwendungsverversion erfordern; eine API-Review-Fähigkeit kann Rückwärtskompatibilität, Authentifizierungs-Checks, Paginierungskonsistenz, Idempotenz-Analyse, Rate-Limit-Verhalten und OpenAPI-Änderungen erfordern. Ein praktischer Weg: Beginnen Sie mit den gstack-Fähigkeiten, die Sie tatsächlich verwenden, kopieren Sie ihre Struktur in Ihr eigenes skills/-Verzeichnis und schreiben Sie die Checks um Ihre Konventionen herum.

Vier Schichten: Fähigkeiten, Spezifikationen, Methodologien, Orchestrierer

Vier Schichten decken die meisten dieser Tools ab, und sie zeigen, wie die Kombinationen oben zusammenpassen:

Fähigkeiten beantworten „Wie sollte der Agent sich verhalten?"

gstack, Superpowers und eigene Agenten-Fähigkeiten.

Spezifikationssysteme beantworten „Was bauen wir genau?"

OpenSpec und GitHub Spec Kit; die zugrunde liegenden spezifikations-getriebenen Konzepte und Terminologien sind definiert in Was ist Spezifikations-getriebene Entwicklung?.

Methodologien beantworten „Wie sollte das Projekt von der Idee zur Software bewegen?"

BMAD, Superpowers und Teile von gstack.

Orchestrierer beantworten „Wie sollten mehrere Agenten Arbeit ausführen?"

Ruflo und andere Multi-Agenten-Runtimes.

Die Schichten komponieren sich; eine Entwicklungsumgebung kann alle vier enthalten:

gstack erstreckt sich bereits über mehrere dieser Grenzen.

Sollten Sie gstack verwenden?

Die README des Projekts beschreibt die Zielgruppe als technische Gründer und CEOs, die immer noch ausliefern wollen, erste Claude Code-Nutzer, die strukturierte Rollen anstelle eines leeren Prompts wollen, und Tech-Leads und Staff-Engineer, die rigoroses Review, QA und Release-Automatisierung auf jeden PR wollen. gstack ist es wert, ausprobiert zu werden, wenn Sie Coding-Agenten ausgiebig verwenden und der begrenzende Faktor nicht mehr die Code-Generierung selbst ist. Typische Symptome:

• Der Agent beginnt zu implementieren, bevor er das Problem versteht
• Implementierungspläne verpassen architektonische Auswirkungen
• Generierter Code besteht Tests, aber schlägt im Browser fehl
• Reviews sind inkonsistent zwischen Sitzungen
• Release-Schritte werden wiederholt vergessen
• Verschiedene Entwickler prompten den Agenten auf völlig unterschiedliche Weise
• Nützliche Engineering-Anweisungen bleiben in CLAUDE.md-Dateien begraben
• Sie tippen dieselben Review-Prompts wiederholt manuell

Wenn Ihre Automatisierung bereits starke deterministische Gates bereitstellt und der Agent nur kleine, gut spezialisierte Aufgaben behandelt, fügt gstack wenig hinzu.

gstack und die Richtung der KI-Softwareentwicklung

Der Wandel, in dem gstack steht, folgt Generationen: Code-Vervollständigung (2022-2023), Coding-Agenten (2024-2025), Spezifikationen und Agenten-Workflows (2025-2026) und programmierbare KI-Engineering-Organisationen. Die Produkte werden sich ändern, aber das Modell bleibt eine Komponente; Engineering-Qualität hängt zunehmend vom umgebenden System ab:

• persistente Spezifikationen
• wiederverwendbare Fähigkeiten
• Repository-Wissen
• Browser-Zugriff
• Tests
• deterministische Werkzeuge
• Review-Schleifen
• Sicherheitskontrollen
• Gedächtnis
• menschliche Genehmigungsgrenzen
• Orchestrierung

Fazit

gstack ist der Engineering-Prozess um einen Coding-Agenten, verpackt als inspektierbare, versionierte Fähigkeiten, und sein Wert liegt darin, diesen Prozess auf den Agenten zu erzwingen, nicht in einer einzelnen Fähigkeit.

Beginnen Sie mit der Prüfsequenz und behalten Sie nur die Fähigkeiten, die ihren Platz verdienen. Darüber hinaus ist die Richtung komponierbare Schichten – Spezifikation, Fähigkeiten, deterministische Verifikation, Orchestrierung – jede tut das, was die anderen nicht können.

Referenzen

• gstack Repository – Quelle, Fähigkeitsdefinitionen und Setup
• gstack Fähigkeit tiefergraben – Philosophie, Beispiele und Workflow für jede Fähigkeit
• Aside Browser – der Browser, den gstack zuerst auf macOS steuert
• Superpowers Repository – Quelle, Fähigkeiten und Plugin-Manifeste
• OpenSpec Repository – Quelle, Docs und das CLI-Paket
• GitHub Spec Kit Dokumentation – offizielle Spec Kit Workflow-Referenz
• BMAD-METHOD Repository – die adaptive KI-getriebene agile Methodologie
• Ruflo Repository – die Multi-Agenten-Orchestrierungsplattform