gstack: Garry Tan’s open-source “software factory” for Claude Code (and nine other agents)

Update — September 1, 2026: Tan published new evals for GBrain, his memory layer listed among gstack's supported host environments — but the eval set shares an author with the tool it's scoring, the same self-graded-benchmark issue explainx.ai flagged the same day in an unrelated model launch.

Update — August 25, 2026: Tan's viral systems of record → AI harness prediction extends his coding-side thesis — gstack is the developer harness reference; CRMs and SaaS need the same shape on canonical data.

gstack is Garry Tan’s public release of a large, Claude Code-centric, multi-host skill stack: on the order of 23 specialist slash workflows, eight “power” tools, MIT license, no paywall. The README leads with a reproducible take on “logical” change and line counts (On the LOC Controversy) and with GitHub contribution density (2026 vs 2013) on the author’s own repositories—then argues for gstack as the sprint process he uses in the open.

This explainx.ai note is a map, not a replacement for upstream docs. github.com/garrytan/gstack is canonical for install commands, slash names, and per-release features (for example the v0.19 CLIs mentioned in the README). Browse gstack on explainx.ai: explainx.ai/skills/gstack (pre-filtered skills registry view).

The thesis

Turn a long chat into a repeatable sprint where the output of one slash skill feeds the next: think → plan → build → review → test → ship → reflect.

Upstream frames that as a process, not a grab bag of prompts. It overlaps the “skills compound if you chain them” idea in our agent skills guide, at YC-style cadence.

The skill map (at a glance)

Philosophy per skill: docs/skills.md. Builder framing: ETHOS.md.

How you install it

1. Solo — shallow clone into ~/.claude/skills/gstack, run ./setup, add a CLAUDE.md gstack block that (a) routes web work through /browse and (b) lists slash commands. The long canonical list is only in the upstream README; do not copy stale lists from blogs.
2. Team — gstack-team-init in required or optional mode commits .claude/ metadata so peers auto-install; setup --team plus silent hourly update checks.
3. OpenClaw — spawn Claude Code with gstack loaded, or use ClawHub “native” skills for a subset. See docs/OPENCLAW.md.
4. Other coding agents — ./setup --host <name> to install under paths such as ~/.codex/skills/, ~/.cursor/skills/, and others listed in the README. Extending a host: docs/ADDING_A_HOST.md.

Requirements (per README): Claude Code, Git, Bun 1+; Windows also Node (Playwright + Bun pipe issue—upstream documents fallback to Node).

Design, browser automation, and security

• Shotgun → HTML — variant mockups (the README cites GPT Image-class generation in places), a browser comparison board, and gstack-taste-update to persist what you keep vs reject.
• Browse stack — GStack Browser with a sidebar mini-agent, $B handoff for MFA or CAPTCHAs, and a substantial prompt-injection story (classifiers, canary tokens, optional heavier ensemble, kill-switch env vars).

Before you aim this at untrusted pages or a compliance boundary, read ARCHITECTURE.md and BROWSER.md. This post is not a security audit.

Parallel sprints, CLIs, and ecosystem

• Conductor and the README’s “10–15 parallel sprints” are presented as a human coordination layer on many isolated Claude Code sessions: process tames agent proliferation, not the reverse.
• CLIs (the README cites v0.19+): gstack-model-benchmark (Claude, GPT, Gemini; --dry-run to validate), gstack-taste-update (persist design shotgun taste).
• /codex is a cross-model second opinion on the same diffs as /review, with overlap/unique-finding analysis when both have run.
• Checkpoint mode (opt-in) auto-commits WIP with structured [gstack-context]; /ship is documented to squash or filter WIP commits in a bisect-safe way (see the README).

Privacy and telemetry (per README)

• Default off; first run asks. If enabled, only skill name, duration, success, version, OS.
• Never (claimed in README): code, file paths, prompts, branch names.
• Supabase + edge functions; schema in supabase/migrations/. Local gstack-analytics on JSONL.

A minimal “try it” path

1. Install per Install — 30 seconds.
2. Run /office-hours on a real user pain, not a feature wish list.
3. Run /review on a real branch.
4. If it clicks, add /qa on a staging URL, then /ship.

Hiring (upstream README): Y Combinator — software (not affiliated with explainx.ai; listed for completeness).

How should you try gstack on an existing repository?

Start with one workflow that addresses a real gap. If your team struggles to review agent changes, try the review workflow before adopting the whole sprint sequence. If you lack browser checks, try a narrow QA pass on a development or staging screen. A large skill stack is easier to evaluate when you know which problem you expect it to solve.

Read the chosen skill and its referenced scripts before running it. Identify whether it edits files, runs shell commands, opens a browser, commits changes, or invokes another model. A command name can sound like a harmless checklist while its workflow includes consequential actions. The actual instructions and host permissions define the behavior.

Use an isolated branch or disposable checkout for the first trial, and preserve unrelated work. Record the installed revision and host configuration. That lets you connect any observed result to a particular version instead of assuming that a future auto-update behaves like the version you reviewed.

A worked example: reviewing an upload change

Imagine a branch adds an upload form. Give the review workflow the change and the intended behavior: accepted formats, size limits, error handling, and what happens when the user cancels. Ask for findings tied to the diff and missing verification. A useful review should identify concrete issues rather than merely recommend more tests everywhere.

Next, open the form in the browser through the QA workflow. Try a valid file, a rejected type, a large file, and a canceled upload. Inspect the loading and error states as well as the happy path. Record what was actually exercised. A screenshot of the default state cannot establish that cancellation or server failure works.

Then connect the code and browser findings. If a UI message claims the upload completed before the server confirms it, fix that state transition and repeat the affected case. Do not describe the whole application as production-ready because one screen passed a focused trial. Keep the acceptance claim as narrow as the evidence.

How do you fit an opinionated workflow into a team process?

Compare its stages with your existing requirements. Your repository may already have required tests, ownership rules, and a release checklist. Keep those requirements authoritative. A skill pack can help carry them out, but it should not silently replace a project-specific review rule with its own generic definition of shipping.

Decide which stages are advisory and which produce an artifact someone reviews. Planning can produce a scoped proposal. Review can produce findings. QA can produce screenshots and exercised cases. Release can produce a concrete diff and validation report. Clear outputs make the sequence easier to inspect than a long conversation that loosely claims every stage is complete.

Avoid adopting every skill simply because the sequence looks complete. A small team may need a product review and a browser check, while another already has those and needs better release evidence. Add the workflow that closes a known gap, then observe whether the extra coordination costs are justified.

What changes when skills update automatically?

An update can change prompts, scripts, defaults, and host integration. Those changes can affect what the agent reads or executes even when the slash-command name stays the same. Keep a way to inspect the installed revision and compare it with the previously reviewed one.

For a team, choose an update policy deliberately. A shared tool that changes during an active release can make debugging difficult. Review upgrades in a safe environment and tell collaborators when the workflow they rely on has materially changed. Upstream activity is useful, but it is not a substitute for knowing what runs in your repository.

How should you judge the result without relying on line counts?

Use the problem you started with. Did review find a credible bug? Did browser QA catch a visible state error? Did the workflow make the final diff easier to understand? Did a previously missing check become reproducible? These are practical outcomes you can inspect without treating generated code volume as a quality measure.

Keep failures in the evaluation. A browser tool may be unable to authenticate, a second model may disagree for an unhelpful reason, or a release command may encounter a project-specific gate. Record those limits and decide whether the workflow needs adaptation. An honest trial includes the setup and recovery work, not just the successful output.

The reusable idea is that specialist instructions can make an agent's process more explicit. Their value depends on the task, repository, and evidence they produce. Adopt gstack as a set of inspectable workflows, then keep the parts that improve your actual development process.

Read next (explainx.ai)

• What is a software factory? The SMB promise — economic claim; gstack is one packaged sprint implementation
• What are agent skills? Complete guide
• MCP: Model Context Protocol
• Caveman: token economics for agents
• Claude Code, Pro, and the April 2026 pricing test
• Naval podcast roundtable: Gary Tan, Daniel & Farbood on AI compute, jobs, and ASI — Gary Tan describes building GStack in this July 2026 founder conversation.

The GitHub default branch README and CHANGELOG are the canonical feature and version sources; star counts and social screenshots go stale in hours.