gstack installs by asking Claude Code to clone a repo and edit your CLAUDE.md

The install is a prompt, so the agent writes to your disk and your CLAUDE.md

There is no package to add and no install script you run yourself. Step one says to open Claude Code and paste a prompt, and Claude does the rest. The prompt tells it to run:

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup

and then to add a gstack section to CLAUDE.md instructing the agent to use the /browse skill from gstack for all web browsing, never use `mcp__claude-in-chrome__*` tools, and to list the available skills. The shallow single branch clone is a sensible choice for a large repository, and the install target is a directory inside your Claude configuration rather than your project.

The consequence is that the setup is performed by a model reading instructions, in two places: your skills directory and your CLAUDE.md. Nothing here is a checksummed binary you inspected first, and the file that changes your future agent behavior is edited for you. Read the prompt, and read the diff afterward.

Requirements are Claude Code, Git, Bun v1.0+, and Node.js on Windows only.

Team mode commits a requirement and adds an hourly silent network check

Step two is the part with lasting consequences, and it is a single command you paste from inside your repository:

(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"

The stated benefit is no vendored files in your repo, no version drift, and no manual upgrades, which is real: the repository is referenced rather than copied. The cost is stated in the same breath. Every Claude Code session starts with a fast auto-update check, throttled to once per hour, network-failure-safe, and completely silent.

So opting in means two things a reviewer should know about. A commit lands in your shared repository with the message `require gstack for AI-assisted work`, and every session thereafter makes an outbound request you will not see. The word `required` is the switch: swapping it for `optional` nudges teammates instead of blocking them. If your repository has a policy about agents or a network policy about tooling, this is where you find out.

The headline says 23 tools, the install prompt lists close to forty commands

The count and the surface do not match, and that mismatch is the fastest way to misunderstand what you are installing. The project description calls it 23 opinionated tools, and the body repeats the framing as twenty-three specialists and eight power tools, all slash commands, all Markdown, all free, MIT licensed.

The list the install prompt tells your agent to write into CLAUDE.md is much longer. It runs from /office-hours, /plan-ceo-review, /plan-eng-review, /plan-design-review, /design-consultation, /design-shotgun, /design-html, /review, /deslop-shared-libs, /test-audit, /ship, /land-and-deploy, /canary, /benchmark, /browse, /connect-chrome, /qa, /qa-only, /design-review, /scrape, /setup-browser-cookies, /setup-deploy, /setup-gbrain, /retro, /investigate, /document-release, /document-generate, /codex, /cso, /autoplan, /plan-devex-review, /devex-review, /careful, /freeze, /guard, /unfreeze, /gstack-upgrade, and /learn.

That is the number that matters for scoping. The roles described in prose are 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, a security officer running OWASP and STRIDE audits, and a release engineer. Use the list, not the number, to decide whether the surface is one you want to live with.

/cso returns not assessed instead of an audit when the toolchain is missing

The security role has prerequisites the rest of the toolkit does not. Beyond Bun v1.0+, /cso needs a Bun release built with all four `--no-compile-autoload-*` build flags plus a native toolchain: a static-capable C compiler on Linux, Xcode command-line tools on macOS, or Visual Studio 2022 Build Tools with Desktop development with C++ on Windows.

The failure mode is chosen carefully and it is worth understanding. If those are absent, setup still installs everything else and removes stale CSO helpers, and /cso reports `not assessed` together with the prerequisite it found missing.

That is better than a crash and worse than an error, in one specific way: a report that says not assessed can be filed, forwarded, or read at a glance and mistaken for a clean result. So the practical rule is to check the output for that string before you treat the security officer as having reviewed anything. On a machine without a C compiler, the OWASP and STRIDE audits described in the overview simply have not run, and the file that tells you so is the output of the command.

The CSO image preload has a 30 second window per image and a one hour cap

When qualified CSO runtime images are published, setup gives each automatic preload a 30-second window plus a bounded setup allowance for the declared catalog. The knob is an integer environment variable, and the documented example is:

GSTACK_CSO_IMAGE_PULL_TIMEOUT_SECONDS=120

The accepted range is 5 to 300 seconds, so a slow registry is tunable but bounded on both ends. Two behaviors are called out because they are the difference between a failed install and an interrupted one. One image timing out does not consume the remaining images' windows, and setup reports partial progress rather than giving up. A later run resumes from exact digests already present in local Docker, not from tags, which means a retried preload cannot silently pick up different content for an image it already has.

The consequence for a reader is that the security capability depends on container image pulls at all. The complete preload is capped at one hour, so a machine on a slow link can spend that hour and still come back partial, and the audit you eventually run is running against images that were fetched in pieces.

Aside is the recommended browser, and the fallback is not equivalent

The browser skills have a recommended path and a fallback, and the two have different properties. On macOS 15+ the recommendation is the Aside browser, because the browser skills, /make-pdf, and /diagram drive it first, with your real logged-in sessions.

Without it, ./setup builds gstack's own bundled browser, and the same skills use that instead.

The consequence is that one skill name covers two very different situations. In the recommended case, a headless browser is operating inside sessions you are already logged into, which is what makes /qa on a staging URL and /browse on an authenticated page possible at all. In the fallback case the browser is a fresh bundled binary with no sessions of yours in it, so the same commands run against a clean profile and anything requiring authentication will not be authenticated. If you are evaluating whether the QA and browse skills can do the job, the browser you end up with is a deciding input, not a detail.

The package manifest also ships two compiled binaries directly, `browse` from browse/dist/browse and `make-pdf` from make-pdf/dist/pdf, and the build that produces them is a separate compiled step rather than a script run.

The productivity numbers are self-measured, and the reproduction script is elsewhere

The case for the toolkit rests on a measurement, and the measurement has a specific definition. The claim is a 2026 run rate of roughly 810 times the 2013 pace on logical code change, stated as 11,417 against 14 logical lines per day, and 2026 year to date through April 18 having produced 240 times the entire 2013 year. The scope is stated too: 40 public and private `garrytan/*` repositories including Bookface, after excluding one demo repository, and the contribution counts are 1,237 in 2026 against 772 in 2013.

Two features of the framing are load bearing. The metric is logical code change rather than raw lines, with the explicit argument that raw line counts inflate with AI, so the normalization is the author's own definition and the comparison is against a baseline the author also produced. And the author does not claim sole credit, saying AI wrote most of it and that the point is what shipped rather than who typed it.

The methodology, the caveats, and a reproduction script are in docs/ON_THE_LOC_CONTROVERSY.md, outside the README. If you intend to repeat or cite these numbers, that file is the thing to read, and until you have, treat them as a claim with a stated method rather than as a verified result.

Every skill is a directory, and the version lives in two places with no releases

The layout explains how the tool is built and how it is versioned. Each capability is its own top-level directory: agents/, autoplan/, benchmark/, browse/, browser-skills/, canary/, careful/, cso/, design/ plus design-consultation/, design-html/, design-review/, and design-shotgun/, devex-review/, diagram/, document-generate/, document-release/, freeze/, gstack-upgrade/, guard/, health/, and hosts/, alongside bin/, codex/, contrib/, extension/, and the generated agents-digest/.

There is also a build and test surface, and it is Bun-based rather than npm-based. The manifest declares type module, license MIT, and two binaries, and the scripts compile the browser and PDF tools with `bun build --compile`, vendor xterm assets into extension/lib, and run separate cso test suites for Docker, macOS, and Windows, with the Docker suite pinned to `--max-concurrency 1`. An .env.example shows what secrets the test tooling needs, an ANTHROPIC_API_KEY for LLM-as-judge evals, with a note that Bun auto-loads .env so no dotenv is needed.

Two things follow. The version appears in the manifest at 1.91.9 and again in a VERSION file, and the repository has no GitHub releases, so there is no tag to pin a checkout to. The skills are Markdown, which is why the whole surface is reviewable, and also why what actually runs is whatever ./setup produced.

Editorial conclusion

Use gstack if you want role-shaped workflows rather than a blank prompt, and read the install prompt before you paste it, because the setup step and the CLAUDE.md edit are both carried out by the agent rather than by you. Do not adopt team mode without deciding whether a once per hour silent network check and a committed requirement belong in your repository, and do not rely on /cso until you have confirmed it returns an assessment instead of `not assessed` on your platform. Treat the productivity figures as a self-measured claim and read docs/ON_THE_LOC_CONTROVERSY.md before repeating them.

Frequently asked questions

Official sources

1. Official README
2. Project repository