# gstack: AI Software Engineering Stack > Source: > Published: 2026-09-28 05:33:00+00:00 AI coding agents can already write functions, modify repositories, run tests, and open pull requests. The harder problem is getting an agent to follow a repeatable engineering process before, during, and after the code is written. gstack, a project from Garry Tan originally built around Claude Code, takes a different route: instead of replacing your coding agent with another platform, it wraps the agent you already use with specialized skills, browser tooling, reviews, safety controls, and release processes. The project describes the result as a virtual engineering team -- twenty-three specialists and eight power tools, all slash commands, all Markdown, MIT licensed. The comparison targets depend on which part of gstack you need: skill collections such as Superpowers, specification systems such as OpenSpec and GitHub Spec Kit, methodologies such as BMAD, orchestration platforms such as Ruflo, or your own maintained set of agent skills. Several of these combine with gstack rather than replace it, and the wider ecosystem they all belong to is mapped in the [AI Developer Tools hub](https://www.glukhov.org/ai-devtools/) of this site. gstack is an open-source collection of AI engineering workflows. In gstack's framing, software development consists of several different kinds of reasoning, and asking one generic coding prompt to perform all of them is a poor abstraction -- so the project exposes specialized skills instead: The project presents these roles as a virtual engineering team: a CEO who rethinks the product, an eng manager who locks architecture, a designer who catches "AI slop", a reviewer who finds production bugs, a QA lead who opens a real browser, a security officer who runs OWASP and STRIDE audits, and a release engineer who ships the PR. The toolchain around the skill definitions is TypeScript and Bun: a setup script, generated skill documentation, session hooks, state under `~/.gstack/`, a bundled browser, and a set of standalone CLIs. gstack is not a foundation model and not a replacement for Claude Code; it is a process layer running on top of an agent harness: ``` php flowchart TD A[LLM] --> B[Claude Code or another supported harness] B --> C[gstack skills and workflow rules] subgraph G[gstack process stages] D1[Planning] D2[Architecture review] D3[Design review] D4[Code review] D5[Browser QA] D6[Security] D7[Release and deployment] D8[Learning and memory] end C --> G G --> E[Git repository, browser, and development tools] ``` Two structural properties decide where gstack fits. First, the project describes it as a process rather than a collection of tools: the skills run in the order a sprint runs -- think, plan, build, review, test, ship, reflect -- and each skill hands its artifacts to the next, so `/office-hours` writes a design doc that `/plan-ceo-review` reads, and `/plan-eng-review` writes a test plan that `/qa` picks up. Second, gstack is not Claude Code-only: `./setup` auto-detects the agents installed on the machine, and `./setup --host ` targets Codex CLI, OpenCode, Cursor, Factory Droid, Kiro, Slate, OpenClaw, and Hermes, while a 2KB instruction-only digest in the repo covers rules-reading agents that need no install at all. A blank Claude Code session is extremely flexible, and that flexibility is also one of its weaknesses. Consider a feature request such as: ``` Add organization-level API tokens to the application. ``` A capable agent might immediately inspect the repository and start modifying authentication code, whereas a senior engineer would first ask who owns the tokens, whether users can belong to multiple organizations, how tokens are revoked, whether permissions are inherited, what happens to existing authentication, whether tokens should expire, how secrets are displayed, and which audit events are required. The agent may discover some of these questions eventually, but there is no guarantee it will discover them before implementation. gstack moves that discipline into reusable workflows: instead of `idea -> coding agent -> code`, the change passes product review, technical planning, architecture review, implementation, code review, browser QA, and release as named stages, each with its own command (the full sequence is in A Practical gstack Workflow below). This does not make the AI correct; it changes the probability distribution of its mistakes. The agent is pushed to challenge assumptions earlier, inspect evidence, review its own work from several perspectives, and verify the application instead of stopping when the code compiles. Most of gstack's capabilities originate in Markdown skill definitions. An agent skill can describe: Such a skill acts somewhere between documentation, a reusable prompt, a standard operating procedure, and executable workflow configuration. The underlying mechanics are covered in [Claude Skills and SKILL.md for Developers](https://www.glukhov.org/ai-devtools/claude-code/claude-skills-for-developers/); gstack adds infrastructure on top of that primitive: generated skill definitions, startup and completion hooks, state management under `~/.gstack/`, browser automation, safety mechanisms, repository inspection, opt-in telemetry, cross-session memory managed by `/learn`, and optional persistent knowledge through the separate GBrain project, which `/setup-gbrain` can stand up as a local PGLite database, a Supabase project, or a remote MCP endpoint. The exact collection changes quickly, but several workflows illustrate how the system is intended to be used. `/office-hours` belongs near the beginning of a project or feature. It runs six forcing questions about the problem before any code is written, and in the README's worked example it reframes a request for a "daily briefing app" into a personal chief-of-staff AI, then writes the design doc that every downstream skill reads. For vague input like "we need better project search", the output is a requirement, not code. `/plan-ceo-review` examines the product-level assumptions behind a plan. It works in four scope modes -- Expansion, Selective Expansion, Hold Scope, Reduction -- and can challenge scope, identify missing opportunities, reduce unnecessary work, or suggest framing the problem differently. It runs before the requirements are fixed, a stage most coding-agent tools do not have. `/plan-eng-review` shifts the perspective toward engineering: architecture, data flow, diagrams, edge cases, a test matrix, failure modes, and security concerns. It stays separate from the product review because merging both into one large prompt makes the model mix product decisions with implementation decisions. gstack treats visual and interaction design as a separate discipline. `/plan-design-review` rates each design dimension from 0 to 10, describes what a 10 looks like, and edits the plan to close the gap, with "AI slop" detection as a named check. The later `/design-review` runs the same audit against the actual implementation and fixes what it finds with atomic commits and before/after screenshots. For web applications, both pair with gstack's browser automation. `/review` performs engineering review against repository changes from a staff-engineer perspective: it auto-fixes the obvious findings, flags the rest for approval, and keeps an advisory simplification lens for over-built code. Code written successfully is not necessarily code that should be merged. `/investigate` enforces a systematic debugging rule the project calls the Iron Law: no fixes without investigation. It traces data flow, tests hypotheses, and stops after three failed fix attempts instead of continuing to thrash. It also auto-activates `/freeze`, which locks edits to the module under investigation. `/qa` has the agent operate a browser, interact with the application, find bugs, fix them with atomic commits, re-verify, and generate a regression test for every fix. `/qa-only` runs the same methodology report-only. Many coding agents stop verification at "tests passed"; for a web application the browser is where integration errors, layout problems, incorrect flows, authentication failures, and JavaScript exceptions usually become visible. The release chain is three skills rather than one. `/ship` syncs main, runs tests, audits coverage, pushes, and opens the pull request, bootstrapping a test framework if the project has none. `/land-and-deploy` merges, waits for CI and the deployment, and verifies production health. `/canary` then runs a post-deploy monitoring loop that watches for console errors, performance regressions, and page failures. `/autoplan` runs the CEO, design, DX, and engineering review pipeline automatically -- engineering always last, so the shipping gate reviews the final amended plan -- and surfaces only taste decisions for approval. `/spec` turns vague intent into a precise, executable spec in five phases (why, scope, technical with mandatory code-reading, draft, file) with an outside-review quality gate before filing. `/learn` manages what gstack has learned across sessions -- patterns, pitfalls, and preferences -- with review, search, prune, and export. `/retro` produces a team-aware weekly retro; `/retro global` runs it across all your projects and AI tools. On supported macOS systems (macOS 15+), gstack drives the [Aside](https://aside.com) browser first -- your real browser, with your real logged-in sessions, in tabs the agent opens for itself and closes when done. When Aside is unavailable, gstack falls back to its own Chromium-based engine, which `./setup` builds and which runs a persistent daemon rather than launching a fresh browser for every command: ``` php flowchart LR A[Coding Agent] --> B[gstack Browser CLI] B --> C[Local Browser Service] C --> D[Aside or bundled Chromium] D --> E[Application] ``` Persistent browser state lets cookies, authentication sessions, and tabs survive between operations, which makes browser-based QA practical. `/open-gstack-browser` exposes the fallback engine headed, with a sidebar agent that routes fast actions (click, navigate, screenshot) to Sonnet and reading or analysis to Opus. When the agent hits a CAPTCHA, an auth wall, or an MFA prompt, `$B handoff` opens a visible browser at the same page with cookies and tabs intact; you solve it, and `$B resume` continues where the agent left off. The agent suggests a handoff automatically after three consecutive failures. `/pair-agent` shares the browser with other agents -- OpenClaw, Hermes, Codex, Cursor, or anything that can curl -- with scoped tokens, tab isolation, rate limiting, and per-tab activity attribution. The persistent engine also increases the security surface, since an agent with access to authenticated sessions holds a meaningful privilege. gstack ships a layered prompt-injection defense for this: content filters (datamarking, hidden-element stripping, ARIA scrubbing, URL blocklist) on every page read, plus a local ML classifier in a sidecar subprocess that scans page-derived content before the agent sees it, with a verdict combiner that requires classifier agreement before blocking. Page content is treated as untrusted input -- the agent takes syntax from a page, never instructions. Checks before and while using browser-driven QA: `GSTACK_SECURITY_OFF=1` disables the security layer -- do not leave it set.`ps aux | grep -i chrom`.`./setup` so generated components stay in sync with the skill definitions. Three power tools act as session-level safety switches. `/careful` warns before destructive commands -- `rm -rf`, `DROP TABLE`, force-push, `git reset --hard` -- and activates by saying "be careful"; recursive deletes of the root or home directory and force-pushes to the default branch are hard-denied. `/freeze` restricts file edits to one directory so the agent cannot "fix" unrelated code while debugging, and `/guard` activates both at once. Second-opinion reviews cross harnesses: on Claude Code, `/codex` sends the work to OpenAI Codex CLI for an independent review, challenge, or consultation; on the other harnesses, `/claude-code` does the reverse. Each report identifies the provider that actually completed the review. You do not need every gstack skill for every change. A reasonable feature workflow: ``` php flowchart TD A[Feature idea] --> B[office-hours] B --> C[plan-ceo-review] C --> D[Create implementation plan] D --> E[plan-eng-review] E --> F[Implement] F --> G[review] G --> H[qa] H --> I[ship] ``` Which review skills to add depends on who the software is for: | Building for | Plan stage (before code) | Live audit (after shipping) | |---|---|---| | End users (UI, web app, mobile) | `/plan-design-review` | `/design-review` | | Developers (API, CLI, SDK, docs) | `/plan-devex-review` | `/devex-review` | | Architecture (data flow, perf) | `/plan-eng-review` | `/review` | | All of the above | `/autoplan` | -- | For a trivial bug fix, going straight to investigate, implementation, review, and tests is often enough. A tool-neutral version of the same shape -- spec, design, tasks, implement, validate -- is in [Spec-Driven Development Workflow From Requirements to Code](https://www.glukhov.org/app-architecture/documentation/spec-driven-development-workflow/). The project's README describes running ten to fifteen of these sprints in parallel, each in its own isolated workspace; the sprint structure is what the project says keeps parallel agents from becoming sources of chaos. The current installation expects a working Claude Code setup, Git, Bun v1.0+, and, on Windows, Node.js -- Bun has a known bug with Playwright's pipe transport on Windows, so the browse server falls back to Node.js there. If you have not configured Claude Code yet, start with the [Claude Code overview](https://www.glukhov.org/ai-devtools/claude-code/) first. On macOS, the Aside browser (macOS 15+) is recommended for the browser skills; without it, the bundled Chromium daemon is used. `git --version` and `bun --version` (the toolchain is Bun-based). ``` git clone --single-branch --depth 1 \ https://github.com/garrytan/gstack.git \ ~/.claude/skills/gstack cd ~/.claude/skills/gstack ./setup ``` Setup installs and generates the components required by the supported skills and builds the bundled browser; a Chromium install failure is best-effort, setup records the reason, finishes registering every skill, and prints which skills are affected. `## gstack` section to the project's `CLAUDE.md`. The project's install instructions include this step, and it is what makes Claude Code route the skills: use `/browse` from gstack for all web browsing, never use `mcp__claude-in-chrome__*` tools, and list the available skills.`/office-hours` on a scratch project to confirm the skill is recognized. For repositories, gstack offers a team-oriented setup where developers share one workflow instead of individually configured environments: ``` (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` blocks AI-assisted work in the repo without gstack; swap it for `optional` to nudge teammates instead of blocking them. No files are vendored into the repo: every Claude Code session starts with a fast auto-update check (throttled to once per hour, network-failure-safe, silent), which removes version drift across the team. Personal configuration improves one developer; repository-level configuration creates a shared engineering convention. `./setup --host codex`, `--host opencode`, `--host cursor`, `--host factory`, `--host kiro`, `--host slate`, `--host openclaw`, and `--host hermes` install the skills into each agent's own skills directory. The 2KB instruction-only digest at `agents-digest/gstack-AGENTS.md` covers agents that only read rules files.`/qa`, `/review`); `./setup --prefix` switches to namespaced names (`/gstack-qa`), which matters when you run other skill packs alongside gstack.`git pull` (required on Windows, where installs are file copies), or use the `/gstack-upgrade` skill; setting `auto_upgrade: true` in `~/.gstack/config.yaml` keeps the install current automatically.`gstack-config set telemetry off` disables it at any time.`~/.claude/skills/gstack/bin/gstack-uninstall` removes skills, symlinks, `~/.gstack/` state, project-local state, browse daemons, and hook registrations.`~/.claude/skills/gstack`, that the project's `NEED_ASIDE` or `ASIDE_NOT_RUNNING`` cd ~/.claude/skills/gstack && bun install && bun run build`. Use gstack on a real but non-critical feature rather than migrating your development process. The project's quick start is the same trial, and it ends with "stop there": `/plan-ceo-review` -- product reasoning If those stages surface findings your normal Claude Code workflow misses, the rest of the system is worth exploring; if they mostly produce additional text without changing engineering decisions, adopting the entire stack probably will not help. **Separated engineering roles.** Instead of one giant "be a senior engineer" instruction, product strategy, architecture, UX, QA, security, and release engineering each get their own reasoning mode. **Verification, not just generation.** Review, browser QA with regression-test generation, security audits, benchmarking, and the ship-deploy-canary chain are first-class workflows in gstack rather than optional afterthoughts. **Inspectable.** Much of the behavioral layer is plain Markdown files developers can read and modify, unlike the internal workflows of a proprietary autonomous agent. The repo also ships audit tooling for the stack itself: `gstack-context-bill` reports what an installed skill tree costs in tokens, and `gstack-egress` writes a hash-chained receipt for every off-machine send, telemetry included. **Team infrastructure.** Skills can encode engineering conventions -- instead of typing ``` Remember to check API compatibility, run integration tests, inspect the browser console, and update the changelog. ``` in every session, the requirements live in a reusable workflow, and team mode makes that workflow a repository requirement. gstack is intentionally opinionated, and that limits its fit: a mature organization may already have architecture review procedures, release tooling, CI gates, QA automation, security scanning, ADR conventions, specification templates, and code review policies, and adding another complete methodology on top creates overlap instead of clarity. There is also a context and token cost: each additional review stage adds repository inspection, model reasoning, and potentially more external model calls. The goal is the minimum reliable process needed to ship correct software, not a maximum number of AI reviews; `gstack-context-bill` can quantify what your installed skill set actually costs per session before you decide how much of it to keep. gstack works best as a toolbox whose workflows you select and adapt, not as ceremony for every commit. The closest alternatives, and the layer each occupies: | System | Primary focus | Workflow style | Agent portability | Best fit | |---|---|---|---|---| | gstack | Full engineering workflow | Role-oriented skills and tools | 10 agents via `./setup --host` | End-to-end AI-assisted engineering | | Superpowers | Engineering methodology | Automatic composable skills | High | Disciplined coding and TDD | | OpenSpec | Change specifications | Lightweight spec artifacts | High | Brownfield feature development | | GitHub Spec Kit | Spec-driven development | Structured multi-stage workflow | High | Formal requirements-to-code process | | BMAD Method | AI-driven agile development | Adaptive roles and workflows | High | Larger end-to-end projects | | Ruflo | Multi-agent orchestration | Agents, swarms, memory | Platform-oriented | Parallel autonomous agent systems | | Custom skills | Your own process | Fully customizable | Potentially very high | Mature teams with established practices | Both are skill frameworks, so they overlap the most. The division of labor when combining them: gstack supplies the surrounding roles -- product, design, QA, release -- while Superpowers supplies the discipline inside the implementation phase (TDD, planning before implementation, systematic debugging, subagent review). Install both skill sets, then trim the overlapping skills so the agent never sees two conflicting instructions for the same phase; if command names collide, install gstack with `./setup --prefix` so its skills register as `/gstack-*` and coexist with the other pack. Install and workflow details are in the [Superpowers quickstart](https://www.glukhov.org/ai-devtools/superpowers/). OpenSpec keeps human and agent aligned around explicit change specifications -- artifacts for the proposed change, specifications, design decisions, and implementation tasks. The key property is persistence: a chat conversation disappears into context history, but a specification remains in the repository where humans and future agent sessions can review it. gstack adds the product review before the spec exists and the review and QA after it is implemented: ``` php flowchart LR A[Feature request] --> B[gstack product review] B --> C[OpenSpec change] C --> D[Implementation] D --> E[gstack review] E --> F[gstack QA] ``` A concrete sequence: run `/office-hours` and `/plan-ceo-review`, capture the outcome as an OpenSpec change, implement against it, then run `/review` and `/qa`. Note that gstack also ships its own `/spec` skill, which archives specs under `~/.gstack`; if OpenSpec owns the specification, keep gstack's `/spec` out of the loop so the two do not diverge. The [OpenSpec quickstart](https://www.glukhov.org/ai-devtools/openspec/) covers the explore-propose-apply-archive loop in detail. Spec Kit's core workflow is a sequence of explicit stages -- constitution, specify, plan, tasks, implement, converge -- and it has expanded into bug-fixing, idea-assessment, extensions, presets, and integrations. Since both Spec Kit and gstack center the planning stage, running both full flows duplicates work. If requirements traceability and formal stages matter, let Spec Kit own the specification backbone and use gstack for the layers Spec Kit does not enforce -- product review, design review, browser QA, and shipping. A broader comparison of spec-driven setups, including Kiro and Claude Code, is in [GitHub Spec Kit vs Kiro vs Claude Code SDD Workflows](https://www.glukhov.org/ai-devtools/ai-coding-assistants/spec-kit-vs-kiro-vs-claude-code/). BMAD is a broader AI-driven development methodology whose adaptive workflows cover product thinking, specifications, architecture, and implementation, scaling the ceremony to the size of the work. It and gstack both play the process-backbone role, so choose one as the backbone rather than running both in full; gstack's individual skills can still be selected alongside a methodology. Ruflo targets multi-agent orchestration: coordinated workers, shared memory, swarms. gstack applies multiple specialist perspectives to one engineering workflow; an orchestration platform applies multiple executing agents to one engineering objective. The boundary blurs -- gstack can call external tools and additional models, and orchestrators can implement structured engineering roles -- but the decision is independent: if the problem is that the agent skips engineering discipline, a skill framework is the direct fix; if it is running ten agents concurrently across many tasks and repositories, an orchestrator sits above a workflow like gstack rather than replacing it. You can also skip the framework entirely and create a small collection of skills for the procedures your team already follows: ``` skills/ architecture-review/ api-review/ database-migration-review/ incident-analysis/ release-check/ security-review/ ``` Each skill encodes organization-specific knowledge a generic framework cannot know. A database migration skill can require rollback analysis, table-lock analysis, index impact review, migration duration estimation, deployment ordering, and compatibility with the previous application version; an API review skill can require backwards compatibility, authentication checks, pagination consistency, idempotency analysis, rate-limit behavior, and OpenAPI changes. A practical path: start from the gstack skills you actually use, copy their structure into your own `skills/` directory, and rewrite the checks around your conventions. Four layers cover most of these tools, and they show how the combinations above fit together: gstack, Superpowers, and custom agent skills. OpenSpec and GitHub Spec Kit; the underlying spec-driven concepts and terminology are defined in [What Is Spec-Driven Development?](https://www.glukhov.org/app-architecture/documentation/what-is-spec-driven-development/). BMAD, Superpowers, and parts of gstack. Ruflo and other multi-agent runtimes. The layers compose; a development environment can contain all four: ``` php flowchart TD A[Product requirement] --> B[Specification system] B --> C[Engineering workflow] C --> D[Agent orchestrator] D --> E[Implementation agent] D --> F[Test agent] D --> G[Review agent] D --> H[QA agent] E --> I[Repository] F --> I G --> I H --> I ``` gstack already spans several of these boundaries. The project's README describes the audience as technical founders and CEOs who still want to ship, first-time Claude Code users who want structured roles instead of a blank prompt, and tech leads and staff engineers who want rigorous review, QA, and release automation on every PR. gstack is worth trying if you use coding agents extensively and the limiting factor is no longer code generation itself. Typical symptoms: If your automation already provides strong deterministic gates and the agent only handles small, well-specified tasks, gstack adds little. The shift gstack sits in tracks in generations: code completion (2022-2023), coding agents (2024-2025), specifications and agent workflows (2025-2026), and programmable AI engineering organizations. The products will change, but the model remains one component; engineering quality increasingly depends on the surrounding system: gstack is the engineering process around a coding agent, packaged as inspectable, version-controlled skills, and its value is in forcing that process onto the agent rather than in any single skill. Start from the trial sequence and keep only the skills that earn their place. Beyond it, the direction is composable layers -- specification, skills, deterministic verification, orchestration -- each doing what the others cannot.