gstack: Garry Tan's 57-Skill Claude Code Setup, Measured

gstack is Garry Tan's personal Claude Code setup, published as open source. Tan is the President and CEO of Y Combinator. Before YC, Tan was one of the first engineer, PM and designer hires at Palantir, cofounded Posterous (sold to Twitter), and built Bookface, YC's internal social network. The repository opened on 11 March 2026. It has since passed 136,000 stars and 20,000 forks, and it is MIT licensed with no paid tier.

What you install is a folder of skills. Each skill is a Markdown file called SKILL.md that Claude Code loads when you type its slash command: /office-hours, /review, /qa, /ship. Each one plays a role on a software team. One is a CEO who questions whether you are building the right thing, one an engineering manager who locks the architecture, one a staff engineer who reviews the diff, one a QA lead who opens a real browser, one a release engineer who opens the pull request.

The Markdown is the part people see, but it is not all of it. Behind the skills sit compiled TypeScript tools that run on Bun: a browser daemon, a design binary, and a few dozen command-line helpers for receipts, evidence and review records. That is why GitHub labels the repo TypeScript and not Markdown.

The README sells it with Tan's own output: by its count, Tan's 2026 pace in logical lines of code per day is about 810 times the 2013 pace. That number is the reason the repo went viral, and it gets its own section below, together with what the repo concedes about it.

This page describes version 1.91.101.0, the release in the changelog on 16 October 2026. The articles ranking for "gstack" today mostly describe the March launch, when the pitch was "23 specialists and 8 power tools". The project has more than doubled since then. We also measured something none of them covers: what all those skills cost your context window.

You need Claude Code, Git and Bun 1.4.2 or newer, the version the project tests against. Setup refuses Bun older than 1.3.3, because those versions let compiled tools read a project's .env file, and warns for anything in between. Windows also needs Node.js. On a Mac, the README recommends the Aside browser for the browser skills; without it, setup builds gstack's own Chromium and the same skills use that instead.

Installation is a prompt, not a command you run yourself. Open Claude Code and paste this:

Install gstack: run git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup then add a "gstack" section to CLAUDE.md that says to use the /browse skill from gstack for all web browsing and lists the available skills.

The README's full version of that prompt lists every skill by name. Claude clones the repo, runs ./setup, and edits your CLAUDE.md. The README timed setup at 31 seconds after the clone on a 4-vCPU Linux machine, including building the binaries and downloading Chromium. Expect longer on a laptop or a slow connection.

For a shared repository there is team mode:

(cd ~/.claude/skills/gstack && ./setup --team) && ~/.claude/skills/gstack/bin/gstack-team-init required

That commits a small bootstrap so every teammate gets gstack, without vendoring its files into your repo. Each session then runs an update check at most once an hour. Swap required for optional to nudge teammates instead of blocking them.

The README's own quick start is four commands: /office-hours to describe what you are building, /plan-ceo-review on a feature idea, /review on a branch with changes, and /qa on a staging URL. Its last step reads "Stop there. You'll know if this is for you."

There is an uninstall script, and a manual path for when the repo is already gone. Neither one edits your CLAUDE.md, so remove the ## gstack and ## Skill routing sections yourself.

The README calls gstack "a process, not a collection of tools", and the order matters more than any one skill:

Think → Plan → Build → Review → Test → Ship → Reflect

The skills hand files to each other. /office-hours writes a design doc, and /plan-ceo-review reads it. /plan-eng-review writes a test plan that /qa picks up. /review flags bugs, and /ship checks they were fixed before it opens the pull request.

The README's worked example shows why the first step exists. A user asks for "a daily briefing app for my calendar". /office-hours asks about the pain, then pushes back: what you described is a personal chief-of-staff AI, and the full version is a three-month project. Its recommendation is to ship the narrowest wedge first. The plan reviews then add diagrams, a test matrix and failure modes. The build writes 2,400 lines across 11 files in about eight minutes. /review auto-fixes two issues and asks about a race condition. /qa finds and fixes a bug on staging, and /ship takes the test count from 42 to 51.

If you are not sure which review to run, the README maps it. Design reviews are for end-user UI, developer-experience reviews for APIs, CLIs and SDKs, and engineering reviews for architecture. /autoplan runs all of them in order, with engineering last so it reviews the final plan.

Tan runs 10 to 15 of these sprints at once, each in its own Claude Code session through Conductor. The argument is that the process is what makes that possible: without one, ten agents are ten sources of chaos.

The README's opening still says gstack is "twenty-three specialists and eight power tools", and so do the articles that rank for it. That was accurate in March. On 16 October 2026 a fresh checkout has 58 `SKILL.md` files at the top level: 56 distinct skills, one alias (/connect-chrome is a link to /open-gstack-browser), and a router skill called /gstack that sends a request to the right one. Counting the router and not the alias, that is 57.

Grouped by job:

The newer groups are where the growth went. The iOS skills drive a real iPhone or iPad over USB. The GBrain skills connect a separate persistent memory project, also by Tan. /spec turns vague intent into an issue that has passed an outside review. /eval-plan makes you write down the bars and stop rules for a paid model evaluation before the first priced call.

Design is the other big addition since launch. /design-shotgun generates four to six mockup variants with GPT Image, opens a comparison board in your browser and iterates on your feedback, learning your taste over the rounds. /design-html turns the chosen mockup into production HTML using Pretext computed layout, which the README says reflows text and adjusts heights rather than looking right at one viewport width only. The quickest way to test that on your own output is to swap the real copy for paragraphs of very different lengths. DevPik's lorem ipsum generator produces those by exact word, sentence or paragraph count.

Two skills turn text into documents. /diagram takes an English description and produces the mermaid source, an editable Excalidraw file and a rendered SVG or PNG, with no network. If you already have mermaid source and only need the image once, DevPik's Mermaid diagram converter renders it to PNG or SVG in the browser. /make-pdf turns Markdown into a publication-quality PDF, or one self-contained HTML file with --to html. For a plain Markdown-to-HTML conversion, the Markdown converter does that part without the PDF pipeline.

A skill pack this size raises a fair question: does installing it fill your context window before you type anything? We measured it.

Claude Code puts every installed skill's name and description in each session, so it knows what it can call. The rest of a skill's SKILL.md loads only when you invoke it. We parsed the frontmatter of all 58 files in the 16 October checkout and counted tokens with the o200k tokenizer. Claude's own tokenizer gives different counts, so treat these as estimates of scale rather than exact figures.

That is small, and it is deliberate. gstack's descriptions are terse to the point of being cryptic: /review is described as "Pre-landing PR review", and /canary as "Post-deploy canary monitoring". The "when to use this" guidance that many skill packs pack into the description sits in the body instead, where it costs nothing until the skill runs. The job of routing a request to the right skill moves into one 13-rule block in CLAUDE.md: bugs go to /investigate, code review to /review, shipping to /ship.

The repo has worked on this before. Since version 1.71.0.0, each skill's startup block is a short call to a shared script, which replaced about 18 KB of inline bash in most skills. Another change made each checkout render skills only for the agents installed from it. The README reports that cut a global Claude install from 632 SKILL.md files (34.7 MB) to 63 (2.5 MB), after the full tree was freezing the Cursor agent.

One practical consequence. The README suggests gstack-config set disabled_skills make-pdf,pair-agent for skills you do not use, "so their descriptions stop loading into each session". It works, but at about 21 tokens a skill, disabling ten saves about 210 tokens. That is not where the cost is.

The cost arrives when you invoke a skill. The median gstack SKILL.md is about 10,300 tokens. The large workflow skills are much bigger, and those are the ones the sprint uses:

The largest single skill is /design-review, at about 34,100 tokens. The smallest is /unfreeze, at about 440.

/autoplan deserves a note, because it is pitched as "one command, fully reviewed plan". Its own description says it reads the full CEO, design, engineering and DX review skills from disk and runs them in sequence. That is its own 15,900 tokens plus the four reviews, about 84,300 tokens of instructions for one command.

These are floors. Several skills read further files on demand: checklists, QA methods, design catalogues. The skills' output and your code come on top.

None of this makes gstack wasteful. Those tokens are the process: the forcing questions, the review checklists, the rules about when to stop and ask. But it changes how you should run it. Six workflow skills in one long session put roughly 107,000 tokens of instructions into that session's history before any of your code. Splitting the sprint helps. Plan in one session, then use /context-save and /context-restore to carry the result into a fresh one for the build. That is the same pattern the parallel-sprint setup already uses.

gstack ships its own tool for this, gstack-context-bill. It is a read-only, offline audit that splits a skills tree into the always-on part and the per-invocation part, with --diff to compare two trees and --budget to enforce a ceiling. We counted the files directly rather than running it, because it needs Bun and a built install. It draws the same line this section does.

Most of gstack is prompts. The browser is not. The LOC document in the repo describes it as "the thing that isn't just markdown prompts": a Playwright-based CLI browser Tan wrote "so I could stop manually black-box testing my stuff".

On a Mac with Aside open, the browser skills (/qa, /qa-only, /design-review, /canary, /benchmark, /scrape and /browse) run in your real browser with your real logged-in sessions. gstack opens its own tabs there and closes them when it is done. Elsewhere, or with Aside closed, they fall back to gstack's own Chromium, which runs as a long-lived daemon. Playwright takes 2 to 3 seconds to launch Chromium, so a daemon that stays up turns each later command into an HTTP call of about 100 to 200 ms, and keeps your logins and open tabs between commands.

The fallback browser adds features that only make sense when it is gstack's browser rather than yours:

• `$B handoff`: when the agent hits a CAPTCHA, a login wall or an MFA prompt, a visible Chrome opens at the same page with the cookies and tabs intact. You solve it, say you are done, and $B resume continues. The agent suggests it on its own after three failures in a row.
• Prompt injection defence for the sidebar agent: page content passes through filters (hidden-element stripping, ARIA scrubbing, a URL blocklist) and a 22 MB classifier that runs locally, before the agent sees it. No network calls are involved.
• `/pair-agent`: share the browser with another agent, such as Codex, OpenClaw or Hermes. Each gets its own tab and a scoped token.
• Domain skills: the agent saves a note per site ("LinkedIn's Apply button lives in an iframe"), which loads automatically next time. A note becomes active only after three successful uses.

QA does not need a webpage. /qa and /qa-only test CLIs, APIs, background jobs and webhooks against a local fixture. Before each new probe they record the previous result and the assumption being tested. A bug only counts if it can be reproduced, and its new test has to fail before the fix and pass after it.

Tan calls /qa "a massive unlock": it took Tan from 6 parallel workers to 12. In the README's words, "The agent has eyes now."

Four small skills deal with the risk of handing an agent your repository.

• `/careful` warns before destructive commands: rm -rf, DROP TABLE, force-push, git reset --hard. You can override a medium warning, but recursive deletes of root or your home directory, and force-pushes to the default branch, are refused outright. Saying "be careful" turns it on.
• `/freeze` restricts edits to one directory, so a debugging session cannot "fix" unrelated code. /investigate freezes itself to the module it is investigating.
• `/guard` is both together. `/unfreeze` removes the boundary.

On Claude Code these rules are enforced by hooks that block the action. On every other agent they are advice only. Copilot, for example, ignores skill hooks.

The security skill is more careful about its own claims than most. /cso runs an OWASP- and STRIDE-style audit with an independent challenge pass and explicit coverage. Its README entry says that no qualified runtime or scanner profile has been published yet, so for now every audit is a static assessment. Project-test completion is labelled self_reported, because the target's own code controls its test process.

File permissions show up throughout. Evidence logs are written with mode 0600, readable and writable by your user only. The iOS remote-access allowlist uses the same mode. During paid evaluations, the curated source copy is sealed with 0555 on directories and 0444 on files. If octal modes are not second nature, enter 600, 555 or 444 in the chmod calculator to see the owner, group and other bits each one sets.

Plain ./setup installs gstack for Claude Code. ./setup --host auto installs it for every supported agent it finds on the machine, and ./setup --host codex installs it for one. ./setup --status lists every install with its version and path.

For anything else that reads a rules file, such as Zed, Amp or Jules, there is a 2 KB digest of gstack's principles, agents-digest/gstack-AGENTS.md, to paste into your AGENTS.md. Copilot and Antigravity call skills by prefixed names (/gstack-review), because /review is a built-in command there.

The cross-agent design pays off in outside reviews. Under Claude Code, plan reviews, /autoplan and the adversarial passes in /review and /ship can ask Codex for an independent second opinion. Under Codex, they ask Claude Code. /codex and /claude-code call the other model directly. The repo's LOC document gives an example: while /plan-tune was being planned, a Codex review surfaced more than 15 findings that four Claude reviews had missed, and part of the plan's scope was rolled back.

If the model you chose for a review is invalid or unavailable to your account, gstack stops with a repair message. It never silently switches to its default.

There are three kinds of network traffic, and each has its own switch.

Telemetry is opt-in and off by default. gstack asks once on first run. If you agree, each skill run sends the skill name, outcome, duration, gstack version, OS and an error class. Code, file paths, repo names, branch names and prompts are never sent. The database schema is in the repo, so you can check that. gstack-config set telemetry off turns it off at any time.

The update check is on by default. An interactive skill start checks GitHub for a newer version, roughly once an hour. GitHub sees your IP address; with telemetry on, the check also reports your gstack version and OS. gstack-config set update_check false disables it.

Outside reviews are on by default, and this is the one to know about. When a skill asks the other model for a review, it sends the review prompt and the relevant code, diff or plan to that provider, using your own Codex or Claude Code login. It only happens if that other CLI is installed and signed in, and the first send on a machine says which provider and account it used. gstack-config set codex_reviews disabled turns it off.

Every send gstack makes writes a hash-chained receipt to ~/.gstack/security/egress.jsonl first. gstack-egress list shows what was sent and where, gstack-egress grants shows your standing consents and how to revoke each, and gstack-egress verify recomputes the chain, exiting with code 3 if a record was edited, reordered or deleted. The README is clear about the limit: it is an audit trail, not a firewall, and deleting the whole file is out of its scope.

The README's headline number: in 2026 Tan wrote 11,417 logical lines of code a day, against 14 in 2013. Logical lines exclude blanks and comments. Across Tan's 41 repositories, 15 public and 26 private (one demo repo excluded from 2026), the first 108 days of 2026 produced 1,233,062 logical lines, against 5,143 in all of 2013. That is where 810x and 240x come from.

The repo's document "On the LOC controversy" takes the critics seriously. It agrees that lines of code measure nothing about quality and that AI inflates them. It then deflates its own number: assume AI code is twice as verbose as a senior engineer's, which it calls an upper bound, and the daily multiple drops to 408x. It lists the quality signals it has: a 2.0% revert rate across 351 commits, and tests going from about 100 to over 2,000. It also reports that a third-party AI-code scanner, slop-scan by Sentry's Ben Vinegar, scored gstack 5.24, the worst result Vinegar had measured at the time. Tan cut that by 62% in one session.

It also concedes several points in writing:

• The 2026 numbers are mostly new projects. They say nothing about maintaining 10 million lines of legacy code.
• The 2013 baseline has some survivorship bias. If the real 2013 rate was 50 lines a day, the multiple is 228x.
• Quality-adjusted productivity is "not fully proven". There is no clean bug-density comparison between the two years.
• If most of what shipped in 2026 is dead in two years, the critics will have a point.

Read it as one builder measuring their own output, with the script published so others can rerun it, not as a benchmark of gstack. The usage data in the same document is more useful for judging the skills. From opt-in telemetry as of April 2026: 14,965 installs, 305,309 skill runs with a 95.2% success rate, with /qa the most-run skill it lists, at 57,650 runs.

Yes, if you want a process and not just a prompt. gstack's value is in the order of the steps: question the product, lock the plan, review, test against real behaviour, ship with evidence. If your Claude Code sessions tend to jump straight to code, /office-hours and /plan-eng-review alone are worth the install. The README says as much: try four commands, then stop.

Keep an eye on what it loads. Keeping the skills installed costs little, about 1,600 tokens a session with the CLAUDE.md sections. Running them costs a lot, about 107,000 tokens for the full sprint. Split long sprints across sessions. Do not expect disabling unused skills to save much.

It works best on Claude Code on a Mac. That is the only full-tier host, and the only one where the safety skills actually block. With Aside, the browser skills use your real sessions. On other agents the skills work, but the guardrails are advice.

Check the outside-review default. If Codex is installed and signed in, review passes send code and diffs to it. That is probably what you want, but decide on purpose.

The README describes gstack as "my open source software factory". The measurements back up the first part: it is a factory, with a lot of machinery, and it uses a lot of tokens when it runs.