Garry Tan releases gstack, a workflow system for Claude Code with QA, review and release modes

Garry Tan has open-sourced gstack, a set of skills for Claude Code that turns working with an AI coding agent into a stricter, more predictable process. The idea is simple: don't mix planning, engineering review, QA and release in one endless prompt, but split them into separate modes with clear roles.

What gstack is

Gstack is not a new model or yet another agent framework. It is a workflow layer on top of Claude Code. The project packages the typical stages of software delivery into separate commands and sets a distinct mindset for each. Instead of improvising along the lines of "build the feature and check yourself," the developer gets a sequence of steps: first a product framing, then an engineering plan, then review, browser testing, and only after that release preparation. In other words, gstack tries to bring process discipline to AI development, not magic.

"Eight opinionated workflow skills for

Claude Code" is how the project describes itself.

The key idea is not to give the agent more freedom but the opposite: to narrow the context of each task. According to the project's description, this should reduce the number of weak decisions that appear when the same AI simultaneously invents a feature, writes the code, tests the interface and decides whether it can ship to production. Gstack separates these roles and makes the agent go through them in sequence, as if different people with different areas of responsibility were working on the task.

Eight working modes

At release, the repository had eight main commands, and each covered a separate part of the process rather than "everything at once." This is gstack's main bet: quality improves not through new intelligence but through discipline around an existing coding agent. One command checks the product idea, another the architecture and tests, another the risks in the code, and one more handles the last step before merge and release.

• `/plan-ceo-review` — product review of the idea and priorities
• `/plan-eng-review` — architecture, data flow, edge cases and tests
• `/review` — hunting for production risks and code problems
• `/ship` — syncing the branch, running tests and preparing the PR
• `/browse`, `/qa`, `/setup-browser-cookies`, `/retro` — browser, QA, cookie import and retrospective

Splitting the work into roles looks especially logical given a typical problem of AI coding: the agent quickly writes the happy path but often misses edge cases, regressions and UX failures. In gstack these checks are moved into separate modes so they don't compete with the task of "writing code as fast as possible." This does not guarantee the absence of bugs, but it brings the process closer to ordinary engineering practice, where design, implementation, verification and release are not lumped into one step.

Browser, QA and stack

The most interesting part of gstack is not the markdown skills but the persistent browser runtime. Instead of launching a new browser for every action, the system starts a long-lived headless Chromium daemon and talks to it over localhost HTTP. This serves both speed and state retention between steps. According to the project description, a cold start of the browser tool takes about 3–5 seconds, and subsequent calls after startup take roughly 100–200 milliseconds. As a result, cookies, tabs, localStorage and login state persist between commands.

How this browser fits into the QA flow also matters. The `/browse` command lets the agent open the app, click through the interface, take screenshots and see where things break. `/qa` goes further: it analyzes the branch diff, identifies the affected routes and checks exactly the pages and scenarios that the changes could have broken. In the repository's example, this mode analyzed eight changed files, found three affected routes and ran them against a local instance of the app, tying code changes to real interface behavior.

Technically, gstack is also pragmatic. It requires Claude Code, Git and Bun 1.0+, and at the time of publication the repository used Playwright and the `diff` package, with the `/browse` command built as a separate executable binary. The set can be installed in `~/.claude/skills/gstack` or placed in a local `.claude/skills/gstack` inside a project so the whole team uses the same process. The authors explain the choice of Bun for simple reasons: compiled binaries, native SQLite access, TypeScript execution without extra scaffolding, and a built-in HTTP server via `Bun.serve()`.

What it means

Gstack is interesting not as "yet another set of prompts" but as an attempt to turn AI coding into a repeatable pipeline with checks at every stage. If this approach catches on, the market will move not only toward stronger models but also toward stricter operational layers on top of them, with separate modes for planning, review, QA and release. The main shift is that trust in AI is being built not on a model's promises but on verification stages.