How to Use gstack to Turn Claude Code Into a World-Class Product Team

gstack is an open source skill pack from Garry Tan, President and CEO of Y Combinator, that turns Claude Code into a product team of 28 slash commands. In his YC demo, /office-hours reframed a tax-document app into a CPA lead-gen business and adversarial review caught 16 issues before a line of code was written.

Video Summary and Key Insights

Garry Tan spent the first decade of his career as an engineer: computer systems engineering at Stanford, employee number 10 at Palantir doing engineering, design, and product at once, cofounder of Posterous (acquired by Twitter), and author of the first version of Bookface, YC's internal knowledge base. In this 22-minute video he demos gstack, the MIT-licensed repo he shipped in March 2026 that wraps Claude Code in a set of role-based skills. He builds a tax-document collector live, starting with /office-hours — a distillation of what YC's 16 partners do with founders — and runs it through adversarial review and AI-generated design before writing any code. The core argument: the bottleneck is not model intelligence, it's the absence of process.

Key Insights:

• gstack went from zero to more GitHub stars than Ruby on Rails in three weeks. Tan created the repo on March 11, 2026. By the time of this demo it had passed 70,000 stars; as of August 2026 it sits at 127,781 stars and 19,239 forks, all MIT licensed and free.

It turns out the way to get agents to do real work is the same way humans have always done it — as a team, with roles, with process, with review.

• The bottleneck is process, not intelligence. Tan's diagnosis is that out of the box the model wanders, doesn't know your data, and guesses, and guessing at scale produces plausible-looking code that silently breaks. His fix is what he calls the "thin harness, fat skills" approach: keep the scaffolding trivially thin and put the sophistication in markdown skill files.

• /office-hours opens with six forcing questions distilled from 16 YC partners. Tan describes it as a 10%-strength version of what YC does with founders every day. The question that anchors the session: what's the strongest evidence that someone actually wants this?

• The agent reframed the demo product into a different business. Tan asked for a tool to pull 1099-INT forms out of Gmail. Office hours came back with a wedge strategy: document collection is the hook, matchmaking users with tax preparers is the business. His own read is that aggregation supports maybe $10 a year per user, while a cut of the tax-prep transaction is roughly 10x that.

• Adversarial review caught and fixed 16 issues before any code existed. Two rounds of automated review took the design doc from 6/10 to 8/10, flagging missing failure handling, an absent privacy section, and a 2FA handoff with no proposed solution.

The barrier to building just collapsed. The only question left is what are you gonna build?

• /design-shotgun generates three visual directions in about 60 seconds. It farms image generation out to OpenAI Codex and runs the variants in parallel, so three directions cost the same wall-clock time as one. Tan star-rates them in a comparison board and picks a winner.

• He runs 10 to 15 parallel Claude Code sessions and lands up to 50 PRs a day. His slide puts the March 2026 numbers at 3 projects simultaneously, 15 concurrent sessions, 17,000 lines of code per day, and 600,000+ lines in 60 days, part-time. 35% of shipped code is tests.

• Tan rewrote browser automation because the existing MCP was too slow. He calls Claude in Chrome MCP one of the worst pieces of software he's used, citing 2-3 second action latency and context bloat. He wrapped Playwright and Chromium at the CLI level instead, which became /qa and /browse.

• He rates gstack a "level 7" software factory, not level 8. The honest ceiling: it gets him parallel branches landing more or less simultaneously, but a human is still in the loop on taste decisions and PR review.

Why This Demo Is Worth 22 Minutes

I've watched a lot of AI coding demos that are really just autocomplete with better marketing. This one is different because the interesting part happens before any code gets written. Tan spends the first eleven minutes arguing with his agent about whether the product should exist.

That's the part worth studying. gstack's contribution isn't a better prompt. It's a sequence of specialist roles that each refuse to let you skip a step. I've pulled out how the sprint actually works, what the numbers hold up to, and where I think the approach has real limits.

Worth knowing where this started: Tan says he picked up Claude Code in January after hearing Andrej Karpathy and Boris Cherny say they'd stopped writing code by hand. Karpathy has since described that same shift as agentic engineering, and gstack is essentially one answer to the question it leaves open, which is what you do with your time once you're not typing the code.

What Is gstack and Why Does It Turn Claude Code Into a Team?

gstack is an open source repository of markdown skills that install as slash commands in Claude Code. Each skill encodes one specialist role (YC partner, CEO, eng manager, designer, staff engineer, QA lead, release engineer), and each one hands its output to the next.

Tan's framing is that the model was never the constraint.

The bottleneck here is not the model's intelligence. As long as you set the models up right, they are already smart enough to do extraordinary work on your code base.

This is the "thin harness, fat skills" idea, and it's the most portable lesson in the video. A thin harness means minimal orchestration code. Fat skills means the sophistication lives in plain markdown skill files that a person can read and edit. Nothing about it is Claude-specific — gstack's setup script targets Codex CLI, Cursor, OpenCode, and several other agents, because the skills are just instructions.

The role-based framing isn't unique to Tan either. Paperclip organizes its agents into an explicit org chart with a CEO, CTO, QA engineer, and evals engineer. The convergent idea across both is that agents do better work when you give them a job title and a scope than when you give them a task.

The practical implication for anyone building agent tooling: your differentiation is the process you encode, not the wrapper you write around the API.

Why Does /office-hours Start With Six Forcing Questions?

Because the most expensive mistake is building the wrong thing well. /office-hours is modeled directly on YC partner sessions, and Tan describes it as a distilled version of thousands of hours of partner experience run at reduced strength.

Here's the question that determines everything else: what's the strongest evidence that you have that someone actually wants this?

In the demo, Tan's answer is that he personally hunted down 1099s across five-plus accounts the day before, and his accountant sends him annoyed emails about it. The agent doesn't accept that at face value. It counters that the pain is real but the consequence is friction, not penalties, then asks why TurboTax, H&R Block, and Plaid haven't already solved it.

That's a genuine YC-partner move. It's also the thing a blank Claude Code prompt will never do for you.

If I just type the original thing — I need to go find my 1099s — it'll go do that. It will literally just do it. But it won't think about who's the user, what is the business model, who wants this, what's the pain point.

Tan also volunteers the failure rate, which I appreciate more than any of the success numbers: roughly one in three office hours sessions ends with him deciding the idea doesn't make sense. A planning tool that never kills anything isn't planning.

What Happens When the Agent Pushes Back on Your Idea?

It proposes architectures you wouldn't have reached alone. Midway through, the agent challenges Tan's third premise and suggests skipping OAuth entirely: the user logs into their own bank, then AI takes over the visible browser, navigates to tax documents, and downloads the PDF. No Plaid. No stored credentials.

The reasoning on screen is sharper than the summary: with LLM-driven browser automation you don't pre-map every bank portal, because the model can find "Tax Documents" or "Statements & Tax Forms" on most bank sites. As the agent puts it, that's semantic navigation rather than brittle scraping — and it changes the product from a cloud web app into a local-first desktop or extension product.

Tan's reaction to his own agent is the honest moment of the video.

Browser automation is a very out-of-pocket, unusual way to solve this problem. A year ago, two years ago, even three months ago, it's not clear to me that anyone would even try this.

Then it lays out three approaches with completeness scores, which is where the screen carries more detail than the narration.

The agent scores Approach A (Gmail scanner plus checklist) at 4/10 and calls it a feature, not a product. Approach B, full automation plus marketplace, scores 8/10 but tries to solve everything at once. It recommends C, CPA-first, at 7/10, with actual unit economics: each CPA relationship is worth 50 to 200 taxpayers, so landing 5 CPAs at $10-20 per client is $500 to $4,000 per CPA per tax season.

Tan overrides the recommendation and picks B with a modification. That's the right use of the tool. It did the analysis, he made the call.

How Does Adversarial Review Catch Bugs Before You Write Code?

By running the design doc through multiple rounds of automated critique and auto-fixing what it can. In the demo, this is the step with the hardest evidence attached.

The design doc survived two rounds. 16 issues were caught and fixed. The quality score moved from 6/10 to 8/10, with one minor remaining note about Electron packaging. The specific gaps it found: no failure handling, no privacy section, and a 2FA handoff with no proposed solution — all three of which would have surfaced much later and much more expensively.

Tan's slide on review is blunter than anything he says out loud, and it includes a second data point from a different project.

Three reviews, three different questions. /plan-ceo-review asks should we build this. /plan-eng-review asks can we ship this safely. A Codex review asks did we miss anything. On a telemetry sprint, running all three before coding caught 19 bugs before a single line was written — the critical one an ADD/RENAME column conflict in a migration that would have crashed production.

The line at the bottom of that slide is the whole thesis in one sentence: tests verify you built what you planned, reviews verify you planned the right thing.

Can AI Actually Do the Design Work?

Partly. /design-shotgun generates multiple visual directions and asks you to judge them, which is a smarter division of labor than asking a model to have taste.

The mechanic worth stealing: each direction takes about 60 seconds, but they run in parallel, so three directions cost 60 seconds total. It farms the image generation to OpenAI Codex. Tan gets Command Center (dense data table), Friendly Progress (warm, card-based), and Split View (CPA requests left, found documents right).

He rates Command Center 4/5 ("if you're a Linux hacker, you'd really like this"), picks Friendly Progress at 5/5 as better for normal people, and rejects Split View as more complicated than it needs to be. The generated mockup is a real interface, not a wireframe.

If you don't like any of them, you leave feedback and regenerate. The taste stays human; the production is automated. That split is why this works better than "make me a beautiful dashboard."

What Does the Full gstack Sprint Look Like?

Seven stages, each one feeding the next, with a feedback loop at the end. This slide is the most useful artifact in the video.

/retro, /learn, and /document-release feed back into the next sprint. Tan notes that users report spending 80 to 90% of their Claude Code time in just three of the 28 commands: /office-hours, /plan-ceo-review, and /autoplan. All three are planning tools. None of them write code.

/autoplan exists for people who don't want the back-and-forth. It runs CEO, engineering, design, and developer experience review using Tan's default answers, surfacing only the taste decisions that need a human.

How Do You Run 15 Claude Code Sessions at Once?

With isolated worktrees, one per work item. Tan uses Conductor, which creates a fresh git worktree per session, and the numbers on his slide are the most concrete productivity claim in the video.

His March 2026 figures: 3 projects simultaneously, 15 concurrent sessions, 17,000 lines of code per day, 35% of shipped code is tests, and 600,000+ lines in 60 days working part-time. He's sitting on roughly 400 open PRs across his open source projects and lands 10 to 50 PRs on a given day depending on his meeting load.

That's an aggressive number by any standard. Peter Steinberger, who maintains OpenClaw, settled at five or six parallel agents and explicitly rejects merging without human review. The two aren't really in conflict: Tan runs more sessions because he automated the review layer first, which is the whole point of the sprint.

The workflow change underneath the numbers is the part I'd actually adopt.

I don't have a to-do list anymore. Whenever I have an idea or I get a bug report, I just click the plus icon in Conductor, it creates a new worktree, and each one of these things is a new work item.

The worktree is the to-do item. That's a real organizational idea, not a productivity hack. The queue and the workspace become the same object, so nothing sits in a list decaying into staleness.

Two caveats Tan raises himself. He rates this a level 7 software factory rather than level 8, meaning it isn't autonomous. And he flags supply chain attacks as the thing that genuinely scares him about AI coding right now, given how much community code he's merging.

On the 17,000 lines per day figure: treat it the way Tan treats it elsewhere. Lines of code inflate badly with AI, and in his Startup School talk on personal AGI he applies a verbosity discount to his own numbers and lands on a much lower floor. The 35% test share is the more meaningful stat here, because it's a ratio rather than a volume.

Why Did He Rewrite Browser Automation?

Because the existing tooling was too slow to sit inside a loop. Once planning, design, and coding were automated, Tan found himself doing QA by hand, and he's direct about what he tried first.

Claude in Chrome MCP is one of the worst pieces of software I've ever used. Every time it would try to do an action, it would think and think and think. There was crazy context bloat.

His measurement: 2 to 3 seconds per action even when it worked, and often it didn't do anything at all. So he wrapped Playwright and Chromium at the CLI level, which became /browse and /qa. The resulting tool takes screenshots, clicks, fills forms, downloads media, runs regression tests, and updates CSS.

That detour is worth noting for anyone building agent tools. The MCP protocol is convenient, but a CLI the agent shells out to can be dramatically cheaper in tokens and latency, because the agent isn't paying context cost for a protocol handshake on every click. Tan built the CLI using gstack itself, which is a decent argument that the skills compound.

One model-routing note he raises: he treats Opus 4.6 as the idea-generating generalist and reaches for Codex when the debugging gets hard, framing the pair in neurodivergence terms as a CEO and a CTO. The routing advice underneath is sound regardless of the metaphor — use the model that's better at exhaustive, systematic work for the exhaustive, systematic jobs.

Where I Think gstack Has Limits

Three honest ones, none of which Tan hides.

It's tuned for greenfield. Every demo starts from a fresh project with an initial commit and no prior design docs. /office-hours asking what your business model is lands differently when you're adding a feature to a five-year-old codebase with existing users. The review skills port cleanly; the product-reframing skills mostly don't.

The reframing depends on your judgment being good. The agent proposed CPA-first and Tan overrode it. That override was probably correct, but the whole system assumes a user who can tell a good push from a bad one. A first-time founder running /office-hours gets the pushback without the ability to evaluate it, which could just as easily talk them out of a good idea as into one.

Parallel sessions move the bottleneck rather than removing it. Fifteen concurrent sessions and 400 open PRs means the constraint is now review capacity, which is exactly why Tan built /review, /qa, and Codex second opinions. That's a coherent answer, but it's an arms race with your own throughput, and his own supply-chain-attack worry is what it looks like when it goes wrong.

None of that undercuts the core idea. Roles, process, and review are the right abstraction, and 127,781 stars in five months suggests a lot of people agree. The adoption numbers Tan showed at Stanford CS153 hold up better than the star count anyway: 14,965 opt-in installations, 305,309 skill invocations, and a 95.2% success rate across all skill runs.

Tan closes the way he closes most YC talks, which after 22 minutes of process discipline is a reasonable place to land.

Frequently Asked Questions

What is gstack?

gstack is a free, MIT-licensed open source repository from Garry Tan, President and CEO of Y Combinator, that turns Claude Code into a role-based engineering team. It ships 28 slash commands covering product interrogation, planning, design, code review, browser QA, and release. As of August 2026 it has 127,781 GitHub stars and 19,239 forks.

How do I install gstack?

Clone it into your Claude Code skills directory and run the setup script: git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup. Setup auto-detects which AI coding agents you have installed. It also works with OpenAI Codex CLI, Cursor, OpenCode, and several other hosts via a --host flag.

Which gstack command should I start with?

/office-hours. Tan reports that users spend 80 to 90% of their Claude Code time in /office-hours, /plan-ceo-review, and /autoplan, all of them planning commands. /office-hours asks six forcing questions modeled on real YC partner sessions and writes a design doc that every downstream skill reads.

Does gstack only work with Claude Code?

No. The skills are markdown instruction files, not Claude-specific code, so gstack's setup script installs to OpenAI Codex CLI, Cursor, OpenCode, Factory Droid, and other agents. Tan also uses Codex inside the workflow as a second-opinion reviewer, so the system is deliberately multi-model.

How much of Garry Tan's productivity claim is real?

His slide claims 17,000 lines of code per day and 600,000+ lines in 60 days part-time, alongside 15 concurrent sessions and 35% test coverage in shipped code. Lines of code inflate significantly with AI-generated output, and Tan applies a verbosity discount to his own figures in other talks. The 35% test ratio and the 400 open PRs are more informative than the raw line counts.

What is the "thin harness, fat skills" approach?

It's Tan's design principle for agent tooling: keep the orchestration code minimal and put the sophistication into readable markdown skill files. His argument is that the model is already smart enough, so heavy scaffolding is backwards, because what agents lack is process, roles, and review, all of which can be written in English.

Why did Garry Tan build his own browser automation?

He found Claude in Chrome MCP too slow for an automated QA loop, citing 2 to 3 second latency per action and heavy context bloat. He wrapped Playwright and Chromium at the CLI level instead, producing the /browse and /qa commands that can screenshot, click, fill forms, download media, and run regression tests.

What does adversarial review actually catch?

In the demo it caught 16 issues across two rounds and lifted the design doc from 6/10 to 8/10, flagging missing failure handling, an absent privacy section, and an unsolved 2FA handoff. On a separate telemetry sprint, running /plan-ceo-review, /plan-eng-review, and a Codex review before coding caught 19 bugs including a migration column conflict that would have crashed production.

Key Takeaways

• The bottleneck is process, not model intelligence. Tan's claim is that frontier models are already capable enough for extraordinary work on your codebase, and what's missing is roles, sequence, and review. gstack encodes that as 28 markdown slash commands rather than as orchestration code.
• Planning commands get 80-90% of real usage. Users spend the overwhelming majority of their gstack time in /office-hours, /plan-ceo-review, and /autoplan, none of which write code. The value is concentrated before implementation, not during it.
• Adversarial review has the hardest evidence in the demo. 16 issues caught and fixed across two rounds, design doc quality from 6/10 to 8/10, and 19 bugs caught pre-code on a separate telemetry sprint. Tests verify you built what you planned; reviews verify you planned the right thing.
• Parallel design generation costs the same as serial. /design-shotgun produces three visual directions in roughly 60 seconds total by running them concurrently through OpenAI Codex image generation. The human rates and picks; the machine produces.
• One in three office hours sessions kills the idea. Tan volunteers this failure rate, and it's the strongest signal that the tool is doing real evaluation rather than agreeable expansion.
• The worktree is the to-do item. Tan abandoned task lists entirely. Every idea or bug report becomes a new Conductor worktree, collapsing the queue and the workspace into one object. He runs 10-15 concurrent sessions and lands 10 to 50 PRs a day.
• A CLI can beat an MCP server for agent tooling. Tan rewrote browser automation around Playwright at the CLI level after measuring 2-3 second per-action latency and context bloat in Claude in Chrome MCP. Lower token cost, lower latency, same capability.
• He rates it level 7, not level 8. gstack gets parallel branches landing simultaneously but keeps a human on taste decisions and PR review. Tan also names supply chain attacks as his genuine fear given the volume of community code he merges.

This post is based on How to Make Claude Code Your AI Engineering Team (21:49) by Y Combinator, published April 23, 2026. gstack is available free at github.com/garrytan/gstack.