You’ve lived it. You open Claude Code, stare at a blank prompt, and start typing some version of “build me this feature”. It works… sort of. The architecture is whatever Claude felt like doing that day. No one reviewed the plan. You’re the QA, clicking around everywhere and praying nothing breaks. And shipping is crossing your fingers with the PR.
Now imagine that, before a single line gets written, a CEO questions the scope, an eng manager locks in the architecture, a designer catches the AI slop, a reviewer hunts down the bugs that pass CI but blow up in production, a QA lead opens a real browser and clicks through all your flows, and a release engineer ships the PR — all available, all fired up with slash commands.
That’s gstack. And it’s the setup Garry Tan — president and CEO of Y Combinator — uses to build every day. He open-sourced it. MIT license. Free, no premium tier, no waitlist.
What it really is
gstack turns Claude Code into a virtual engineering team. Twenty-three specialists plus eight power tools, all in Markdown, all slash commands. Each one fills a role you’d normally need an entire team to cover:
/office-hours— the YC office hours treatment. Six questions that force you to rethink your product before you write code. It challenges your approach and questions your assumptions./plan-ceo-review— rethinks the problem and hunts for the 10-star product hiding inside your request./plan-eng-review— locks in architecture, data flow, edge cases, and tests. Surfaces hidden assumptions./review— the staff engineer who finds the bugs that pass CI but blow up in prod. Auto-fixes the obvious ones./qa— opens a real browser, clicks through your flows, finds bugs, fixes them, and generates regression tests for each fix./cso— a chief security officer who runs an OWASP Top 10 + STRIDE threat model, with a concrete exploit scenario for each finding./ship— syncs main, runs the tests, audits coverage, and opens the PR. Builds a test framework from scratch if you don’t have one.
That’s just a slice. There’s also /investigate for systematic root-cause debugging, /design-shotgun for generating mockup variants, /document-release so your docs don’t fall behind, and more.
The underlying idea: it’s a process, not a stack of tools
This is the part that matters. gstack isn’t 23 loose commands — it’s a sprint. The skills run in the order a real sprint runs:
Think → Plan → Build → Review → Test → Ship → Reflect
And each step feeds into the next. /office-hours writes a design doc that /plan-ceo-review reads. /plan-eng-review writes a test plan that /qa picks up. /review catches bugs that /ship verifies are actually fixed. Nothing falls through the cracks, because each step knows what came before.
And if you don’t want to run them one by one, /autoplan chains the CEO, design, and engineering reviews together automatically and only brings you the judgment calls that actually need your input.
What a session looks like
You say “I want to build a daily briefing app for my calendar”. You run /office-hours. Instead of just saying yes, the agent pushes back: you said ‘daily briefing app’, but what you described is an AI chief-of-staff type agent. It extracts capabilities you didn’t realize you were describing, challenges your assumptions, and delivers three implementation approaches with effort estimates.
Then /plan-eng-review sketches out the data flow and maps failure modes. You approve the plan. Claude writes the code. /review auto-fixes two issues and flags a race condition for you to approve. /qa opens a browser against staging, finds a bug, fixes it. /ship opens the PR with new tests included.
Eight commands, end to end. That’s not a copilot. That’s a team.
It’s not just for Claude Code
Although it’s built around Claude Code, the setup automatically detects which agents you have installed and works with ten of them — Codex CLI, OpenCode, Cursor, Factory Droid, and others. There’s also a power tool /codex that brings an independent second opinion from OpenAI’s Codex CLI, so you have a different model looking at the same diff and a cross-model comparison of what each one flagged.
How to install it
Open Claude Code and paste the install instruction — clone the repo to ~/.claude/skills/gstack, run the setup script, and add a gstack section to your CLAUDE.md with the list of available skills. Thirty seconds, and Claude handles the rest.
Once you have it, the recommended first walkthrough is straightforward:
/office-hours— describe what you’re building/plan-ceo-reviewon any feature idea/reviewon any branch with changes/qaon your staging URL
Stop there. Pretty quickly you’ll know if it’s for you.
Why it matters for our workflow
The interesting claim behind gstack isn’t a number — it’s a shift in how a single person can work. Tan’s whole argument is that a builder with the right tooling moves faster than a traditional team, and he’s shipping the output of an entire team to prove it. For development teams across Latin America, that’s the same lever, aimed at efficiency: structured roles and a forced review pipeline mean a small team can ship with the rigor of a much larger one, without having to add headcount to pull it off.
And because it’s a process — not a clever prompt you copy once and forget — it holds up throughout an entire sprint instead of evaporating after the first response.
Everything’s on GitHub, MIT license, free forever.
How are you using Claude Code today — blank prompt or have you built your own skills workflow? Let us know in the comments.