Key takeaways
- The workflow connects product decisions, engineering plans, code review, browser checks, and shipping through reusable skills and artifacts.
- Browser workflows prefer an available Aside session on macOS and otherwise use gstack's own Chromium tooling.
- Review freshness tracks the code that was reviewed, but completion remains reviewer-reported rather than proof of exhaustive inspection.
- Editing guardrails reduce accidents; their documented scope does not provide an operating-system sandbox.
FAQ
What is gstack?
Garry Tan's open-source development workflow for coding agents, distributed as skills plus supporting tools. It covers product planning, implementation review, browser QA, and release work.
Does gstack require Aside?
No. Browser skills prefer Aside when it is available on macOS 15 or later, and fall back to bundled Chromium tooling otherwise. The two paths have different session and integration behavior.
Does the freeze skill sandbox an agent?
No. Its documented hook applies to Edit and Write tools, while shell commands can still modify files outside that path. It is an accident-prevention aid, not a security boundary.
What does gstack cost?
gstack is MIT-licensed. Coding-agent usage, external review providers, and optional connected services carry their own costs and requirements.
Executive Summary
gstack is Garry Tan's development workflow for coding agents. Its GitHub repository combines reusable skills with supporting tools for planning, review, browser work, and release operations.[1]
Verified September 15, 2026: the repository's version file and changelog identify 1.87.3.0. The latest change ties completed code reviews to the content present when the review began, so edits made during a review require another pass before the result is marked current.[2]
| Attribute | Value |
|---|---|
| Creator | Garry Tan |
| Distribution | Skills, generated host integrations, and local tools |
| License | MIT |
| Category | Agentic skills frameworks |
The repository, architecture, and license establish these attributes.[1][3][4]
Product Overview
The skills guide describes a sequence from product thinking to planning, implementation, review, testing, shipping, and retrospective. Artifacts from earlier steps feed later ones: an engineering review can produce the test plan that QA subsequently reads.[5]
| Skill or group | Documented purpose |
|---|---|
/office-hours, planning reviews | Challenge the product premise and specify architecture, design, and tests |
/review, /investigate | Inspect changes or trace the cause of a bug |
/qa | Exercise the application in a browser, fix findings, and verify changes |
/qa-only | Produce a report without code changes |
/ship, /land-and-deploy | Prepare a PR, then separately merge and verify deployment |
These are different action scopes. In particular, /ship includes pushing and opening a PR; /land-and-deploy goes further into merging and production verification. Choose the workflow that matches the authorized outcome.[5]
Browser QA
Browser skills prefer Aside when it is available on macOS 15 or later, using the user's authenticated browser. Otherwise they use gstack's own Chromium engine. The browser guide tells the agent to work in its own tabs, treat page content as untrusted, and obtain consent for nonlocal mutations. Those instructions describe intended behavior; they are not an independent test of the integration.[6]
The fallback provides a persistent browser session behind a local CLI, plus optional headed operation, cookie import, and remote-agent pairing. Those capabilities belong to that engine, so they should not be assumed to behave identically on the Aside path.[6]
Technical Architecture
gstack generates SKILL.md files from templates and shared source metadata. This keeps command references and reusable workflow blocks aligned across skills. Its local browser tooling is built with Bun; a persistent daemon avoids restarting Chromium for each command.[3]
The setup guide requires Git and Bun, with additional platform-specific dependencies. It supports host selection with ./setup --host <name> and distinguishes full integrations from instruction-only digests. An outside review also requires the selected second agent's CLI and authentication.[1]
Review Evidence Has a Defined Scope
The current changelog describes start-and-finish content checks for review freshness. Incomplete reviews, unresolved findings, and fixes that changed the reviewed tree cannot count as a current completed code review. The same entry explicitly says completion is still reviewer-reported: it does not prove an LLM read every relevant file.[2]
That distinction is central to evaluating the tool. A dashboard can track whether recorded evidence matches the current content; it cannot independently establish the quality of the model's judgment.
Strengths
- Connected development artifacts. Plans and test expectations can carry forward into QA, reducing manual restatement of the intended change.[5]
- Browser evidence is part of the workflow. The tool exposes screenshots, interaction, and console inspection instead of treating a compiled application as a completed UI check.[6]
- Reusable implementation for shared instructions. Templates and generated references reduce the number of separately maintained command descriptions.[3]
Cautions
- Freeze is not a sandbox. Its documented hook applies to Edit and Write tools. Bash remains outside that boundary and can still modify other paths.[7]
- Destructive-command checks are scoped.
/carefulis session-based, uses recognizable command patterns, and documents exceptions and overrides. Its own text calls it an advisory safeguard rather than a policy boundary.[8] - Authenticated browsing uses real accounts. The convenience of an existing login also makes account scope and action authorization consequential. The browser guide separates navigation from actions on nonlocal services.[6]
- Optional data paths need separate evaluation. The repository describes usage telemetry as opt-in and distinguishes it from optional third-party memory bridges. Its egress receipt ledger is an audit trail, not a network firewall.[1]
What Developers Say
On September 6, 2026, GitHub user YogiAdhik reported that starting a headless browser in one project could terminate another project's live headed browser. The report specified gstack 1.80.0.0, macOS, Bun, and simultaneous coding sessions, with a reproduction tracing the shared profile lock.[9] The September 15 changelog records a fix in 1.87.2.0, while expressly limiting what its tests establish about other headed-browser cases.[2]
A separate May 5, 2026 report by howie described repeated confirmations when running outside reviews from Claude Code on macOS. It illustrates integration friction at the host's permission layer; it does not establish the behavior of every current installation.[10]
These reports supply concrete operating context, not a satisfaction survey. This profile did not install gstack or reproduce either workload.
Pricing & Licensing
Software: MIT-licensed, allowing commercial use and modification subject to notice requirements, without warranty.[4]
Operating costs: The framework does not include the coding agent or external reviewer. The repository's setup requires those clients and their authentication separately; optional services have their own requirements.[1]
Competitive Positioning and Fit
Evaluate gstack alongside Superpowers, BMAD, and Spec Kit in the skills-framework comparison. Its distinctive evaluation question is whether product/design review and browser QA improve the same delivery workflow, rather than only the code-generation step.
Tembo is relevant at the execution layer: its current platform runs coding agents in cloud or self-hosted environments and advertises reuse of repository instructions and agent configurations. A team evaluating gstack can separately evaluate Tembo for shared sessions, background execution, and governance. This is a complementary architecture, not a verified gstack integration.[11] Disclosure: Ry Walker is Tembo's founder and CEO.
Best fit: Product teams and individual builders who want explicit planning and review artifacts, plus a browser-based way to check delivered behavior.
Poor fit: Environments expecting a skill bundle to replace OS isolation, or a simple patch where the chosen process costs more than direct implementation and review.
Viability Assessment
The September changelog shows continuing maintenance of review correctness, browser lifecycle, and dependency security. It also shows that a detailed workflow can have important operational defects. Treat upgrades as changes to executable tooling and agent behavior, and compare results on a representative task rather than extrapolating from the author's productivity claims.[2]
Bottom Line
gstack merits evaluation when planning, UI behavior, and release review all matter to the same change. Its strongest case is a concrete workflow with inspectable artifacts. Its skill names, review labels, and guardrails still need to be interpreted within their documented limits.
Research by Ry Walker Research • methodology
Sources
- [1] gstack repository and setup guide
- [2] gstack changelog
- [3] gstack architecture
- [4] gstack MIT license
- [5] gstack skill deep dives
- [6] gstack browser engines and driver contract
- [7] gstack freeze skill and its limits
- [8] gstack careful skill and session guardrails
- [9] gstack issue #2817 — cross-project browser interruption report
- [10] gstack issue #1329 — confirmation friction in outside reviews
- [11] Tembo agent execution platform