{"id":123561,"date":"2026-03-14T21:37:57","date_gmt":"2026-03-15T00:37:57","guid":{"rendered":"https:\/\/shipping.einnews.com\/article\/899516690"},"modified":"2026-03-14T21:37:57","modified_gmt":"2026-03-15T00:37:57","slug":"garry-tan-releases-gstack-an-open-source-claude-code-system-for-planning-code-review-qa-and-shipping","status":"publish","type":"post","link":"https:\/\/new7.shop\/zerocostfreehost\/index.php\/2026\/03\/14\/garry-tan-releases-gstack-an-open-source-claude-code-system-for-planning-code-review-qa-and-shipping\/","title":{"rendered":"Garry Tan Releases gstack: An Open-Source Claude Code System for Planning, Code Review, QA, and Shipping"},"content":{"rendered":"
<\/div>\n

What if AI-assisted coding became more reliable by separating product planning, engineering review, release, and QA into distinct operating modes?<\/strong> That is the idea behind Garry Tan\u2019s gstack<\/a><\/strong>, an open-source toolkit that packages Claude Code<\/strong> into 8 opinionated workflow skills backed by a persistent browser runtime. The tookit describes itself as \u2018Eight opinionated workflow skills for Claude Code<\/strong>\u2018 and groups common software delivery tasks into distinct modes such as planning, review, shipping, browser automation, QA testing, and retrospectives. The goal is not to replace Claude Code with a new model layer. It is to make Claude Code operate with more explicit role boundaries during product planning, engineering review, release, and testing.<\/p>\n

The 8 Core Commands<\/strong><\/h3>\n

The gstack<\/strong> repository currently exposes 8 main commands: \/plan-ceo-review<\/code>, \/plan-eng-review<\/code>, \/review<\/code>, \/ship<\/code>, \/browse<\/code>, \/qa<\/code>, \/setup-browser-cookies<\/code>, and \/retro<\/code>. Each command is mapped to a specific operating mode. \/plan-ceo-review<\/code> is positioned as a product-level planning pass. \/plan-eng-review<\/code> is used for architecture, data flow, failure modes, and tests. \/review<\/code> is focused on production risk and code review. \/ship<\/code> is used for preparing a ready branch, syncing with main, running tests, and opening a PR. \/browse<\/code> gives the agent browser access, while \/qa<\/code> is designed for systematic testing of affected routes and flows. \/setup-browser-cookies<\/code> imports cookies from a local browser into the headless session, and \/retro<\/code> is used for engineering retrospectives. <\/p>\n

The Persistent Browser Is the Core System<\/strong><\/h3>\n

The most important technical part of gstack is not the Markdown skills. It is the browser subsystem. gstack gives Claude Code a persistent browser<\/strong> and that the browser is the hard part, while the rest is mainly Markdown. Instead of launching a fresh browser for every action, gstack runs a long-lived headless Chromium daemon<\/strong> and communicates with it over localhost HTTP<\/strong>. The reason is latency and state retention. A cold start costs around 3\u20135 seconds per tool call<\/strong>, while subsequent calls after startup are designed to run in roughly 100\u2013200 ms<\/strong>. Because the browser stays alive, cookies, tabs, localStorage<\/code>, and login state persist across commands. The server also shuts down automatically after 30 minutes of idle time<\/strong>. <\/p>\n

How gstack Connects Browser Automation to QA<\/strong><\/h3>\n

That daemon architecture matters for QA and browser-driven development. In many agent workflows, browser automation is a separate debugging step or a screenshot utility. In gstack, browser access is part of the core workflow. The repo describes \/browse<\/code> as the mode that lets the agent log in, click through the app, take screenshots, and inspect breakage. \/qa<\/code> builds on top of that by analyzing the branch diff, identifying affected routes, and testing the relevant pages or flows. The sample flow in the repo shows \/qa<\/code> inspecting 8 changed files<\/strong> and 3 affected routes<\/strong>, then testing those routes against a local app instance. This means the project is trying to tie source changes to actual application behavior instead of treating QA as a detached manual pass. <\/p>\n

<\/div>\n

Installation Requirements and Project Layout<\/strong><\/h3>\n

The repository\u2019s implementation choices are also fairly specific. gstack requires Claude Code<\/strong>, Git<\/strong>, and Bun v1.0+<\/strong>. The package.json<\/code> shows the current version as 0.3.3<\/strong>, lists Playwright<\/strong> and diff<\/code> as runtime dependencies, and compiles a browse<\/code> executable from the browse<\/code> source tree. According to the repo\u2019s README, \/browse<\/code> compiles a native binary and is supported on macOS and Linux<\/strong>, for both x64<\/strong> and arm64<\/strong>. The install flow copies the repo into ~\/.claude\/skills\/gstack<\/code>, runs .\/setup<\/code>, and registers the skills for Claude Code. Teams can also copy the same setup into a repository-local .claude\/skills\/gstack<\/code> directory so the workflow is shared inside a project. <\/p>\n

Why the Project Uses Bun<\/strong><\/h3>\n

The architecture document explains why the project uses Bun<\/strong> rather than a more conventional Node.js setup. There are 4 stated reasons: compiled binaries, native SQLite access, native TypeScript execution, and a built-in HTTP server with Bun.serve()<\/code>. Those choices are practical rather than cosmetic. gstack reads Chromium\u2019s SQLite cookie database directly, and Bun\u2019s built-in database support removes the need for extra native packages. The compiled binary model also fits the repo\u2019s install style, because users are not expected to manage a separate runtime toolchain inside ~\/.claude\/skills\/<\/code>. <\/p>\n

Key Takeaways<\/strong><\/h3>\n