If you have been using Claude Code for any serious development work, you have probably noticed a recurring frustration: the AI tries to be everything at once. Ask it to review your code and it will simultaneously comment on business strategy, code style, test coverage, and deployment concerns — all in one sprawling response that lacks the focused depth you actually need. gstack was built to solve exactly that problem.
gstack is an open-source collection of 13 Claude Code slash commands created by Garry Tan, CEO of Y Combinator. Hosted at garrytan/gstack on GitHub, it introduces a structured system of role-specific AI personas — called “gears” — that you can switch between deliberately, depending on what kind of thinking your current task demands. The result is sharper, more actionable AI output at every stage of a software project.
What Is gstack?
gstack is a Claude Code skills package. It installs directly into your ~/.claude/skills/ directory and surfaces as a set of slash commands inside any Claude Code session. Once installed, you can invoke commands like /plan, /code-review, /qa, or /ship to engage a specific AI persona optimized for that exact type of task.
The project was created by Garry Tan, a well-known figure in the tech startup world who served as a partner at Khosla Ventures and Initialized Capital before becoming CEO of Y Combinator, the world’s most influential startup accelerator. YC has funded companies like Airbnb, Stripe, Dropbox, and Reddit, and Tan has a reputation for thinking rigorously about how developers and founders work. gstack reflects that background — it is not just a prompt library, it is an opinionated framework for structuring human-AI collaboration across the entire software development lifecycle.
The repository is fully open-source under a permissive license. There are no paid tiers, no API keys beyond your existing Claude Code subscription, and no external services required. The entire system runs locally through Claude Code’s native skills infrastructure.
What makes gstack different from simply writing better prompts is persistence and structure. Each gear is a pre-defined behavioral context that activates the moment you invoke a slash command, giving you consistent, repeatable interactions rather than one-off prompts that vary in quality depending on how carefully you phrased them. For teams or solo developers who ship frequently, that consistency compounds into a significant workflow advantage.
The Gears Concept
The philosophical core of gstack is a concept Garry Tan calls the “mushy blend” problem. When you give a general-purpose AI assistant a complex development task, it naturally tries to optimize for everything simultaneously. You get feedback that is part strategic, part tactical, part quality-focused, and part exploratory — all blended together in a way that satisfies none of those needs particularly well.
Think about how this plays out in practice. You ask Claude to review a pull request and you get a comment about the variable naming, followed by a suggestion to reconsider the entire architecture, followed by a note about missing tests, followed by a thought about whether this feature is the right business priority. Each individual observation might be valid, but the mixture is cognitively expensive to parse and rarely produces the depth of insight you would get from someone who is purely focused on one domain.
gstack solves this by borrowing a mental model from organizational design: specialized roles produce better outputs than generalists when the task is well-defined. The “gears” are discrete AI personas, each trained through a focused system prompt to think from a specific professional perspective:
Founder Gear — This persona thinks like an early-stage startup founder or product visionary. It prioritizes product-market fit, user impact, strategic trade-offs, and business judgment. When you invoke a Founder-gear command, you get feedback oriented around “does this solve the right problem?” and “what is the opportunity cost of building this?” rather than implementation details.
Engineering Manager Gear — This persona thinks like a senior engineering leader who cares deeply about code quality, system architecture, maintainability, and team velocity. It evaluates code through the lens of long-term consequences: technical debt, scalability, readability, and consistency with established patterns. It is the gear you activate when you need a rigorous technical review that goes beyond surface-level style issues.
QA Engineer Gear — This persona thinks like a dedicated quality assurance professional whose entire job is to find things that break. It actively looks for edge cases, race conditions, missing validations, error paths that were not considered, and scenarios where user behavior diverges from developer assumptions. It generates test plans, flags risk areas, and produces structured QA reports.
The insight behind gears is that switching between these perspectives deliberately — rather than having them all blend together — produces outputs that are more useful, more focused, and easier to act on. You choose the lens, and the AI applies that lens with discipline.
All 13 Slash Commands
gstack ships with 13 slash commands spanning the full development workflow from initial planning through post-ship documentation.
| Command | Gear / Persona | What It Does |
|---|---|---|
/plan | Founder | Generates a structured product plan with goals, scope, and trade-offs before any code is written |
/design-review | Founder + EM | Reviews a proposed design or architecture from both product strategy and technical quality perspectives |
/code-review | Engineering Manager | Performs a thorough code review focused on architecture, maintainability, and engineering best practices |
/qa | QA Engineer | Runs automated QA checks on a web app, computes a health score, and saves a report to .gstack/qa-reports/ |
/ship | Engineering Manager | Pre-ship checklist verification — confirms the feature is ready to deploy without regressions |
/browser | QA Engineer | Launches a headless browser session to test web UI interactions and user flows |
/retrospective | Founder | Facilitates a structured retrospective on a completed sprint or feature, surfacing lessons learned |
/post-ship-docs | Engineering Manager | Auto-generates post-ship documentation from code and commit history |
/standup | Engineering Manager | Produces a concise standup summary from recent activity and open tasks |
/rfc | Founder + EM | Drafts a Request for Comments document for a proposed change or feature |
/incident | QA + EM | Guides structured incident response when production issues occur |
/metrics | Founder | Defines success metrics and instrumentation requirements for a new feature |
/changelog | Engineering Manager | Generates a user-facing changelog from commit messages and PR descriptions |
The /qa command deserves special attention. It is one of the most technically sophisticated commands in the suite. When invoked, it launches a browser automation session against your running web application, executes a predefined test protocol, and calculates a health_score — a numerical quality indicator covering functionality, performance, and error rates. The full report is saved to .gstack/qa-reports/ in your project directory, giving you a persistent audit trail of quality checks over time.
How gstack Fits into Claude Code
To understand gstack’s architecture, you need to understand Claude Code’s skills system. Claude Code supports a ~/.claude/skills/ directory where you can install collections of slash commands, prompts, and automation scripts. When you start a Claude Code session, it automatically discovers all skills in that directory and makes their commands available in the slash command palette.
This is the same system that powers Claude Code’s built-in commands — gstack simply plugs into it as a first-class citizen. The installation process is a single git clone into the correct directory:
# Install gstack into your Claude Code skills directory
git clone https://github.com/garrytan/gstack ~/.claude/skills/gstack
# Verify installation — you should see the gstack directory
ls ~/.claude/skills/
# Open a new Claude Code session and test the installation
# Inside Claude Code, type:
# /planAfter installation, all 13 gstack commands are immediately available in any Claude Code session without any additional configuration. The commands appear alongside Claude Code’s native commands in autocomplete.
gstack also ships with a config.yaml file that controls optional behaviors. The auto_upgrade setting enables automatic updates when you pull changes from the gstack repository. The update_check setting controls whether gstack notifies you when a newer version is available. If you plan to contribute improvements back to the project, the gstack_contributor flag enables additional development utilities.
The ~/.claude/skills/ directory structure is designed for composability. You can install multiple skill packages alongside gstack, and they coexist without conflict as long as their command names do not overlap. This means gstack can be one layer of a larger personal toolkit built from multiple community skill packages.
Understanding how skills differ from simple prompt templates is important if you want to grasp why this approach scales better. A prompt template is something you copy and paste, often with manual editing, every time you want to use it. A skill command is a persistent, versioned, automatable behavior that you invoke with two keystrokes. As your workflow matures and you discover what works, skills let you encode that knowledge permanently rather than rediscovering it from scratch each session. For more on the underlying principles, see our guide to prompt engineering for AI agents.
gstack vs Ad-Hoc Prompting
Most Claude Code users start with ad-hoc prompting — typing natural language requests directly into the chat without any structured framework. This works fine for simple tasks, but it breaks down as project complexity grows. Here is how gstack compares across the dimensions that matter most for production development work:
| Aspect | gstack | Ad-Hoc Prompting |
|---|---|---|
| Consistency | Identical behavior every invocation — same persona, same evaluation criteria, same output structure | Varies significantly based on how the prompt was phrased, session context, and random sampling |
| Speed | Two-keystroke invocation with no prompt writing overhead | Requires crafting a prompt from scratch, often involving trial-and-error iteration |
| Quality | Focused single-persona output optimized for one type of task | Mixed-perspective output that tries to address all concerns simultaneously |
| Context Switching | Explicit gear selection makes the AI’s current role unambiguous | AI must infer what kind of feedback you want from context, often guessing wrong |
| Repeatability | Identical workflow steps can be reproduced across sessions and team members | Highly personal and session-dependent — hard to standardize across a team |
| Iteration | Improvements to a command benefit all future invocations automatically | Each session starts from zero; no accumulation of workflow improvements |
| Auditability | QA reports and generated docs are saved to structured directories | Outputs exist only in chat history, which resets between sessions |
The practical gap between these two approaches widens as project scale increases. On a small side project with a single developer, ad-hoc prompting is perfectly adequate. But on a product with multiple contributors, a CI/CD pipeline, regular releases, and stakeholder accountability, the consistency and repeatability that gstack provides become genuinely valuable workflow infrastructure.
One underappreciated advantage is team alignment. When every engineer on a team uses the same /code-review command, you get consistent review standards without writing and maintaining a style guide. The AI applies the same Engineering Manager lens to every piece of code, regardless of who wrote it or who is reviewing it.
Who Is gstack For?
gstack is designed for developers who use Claude Code as a serious professional tool rather than an occasional assistant. The ideal gstack user is shipping regularly, working on a non-trivial codebase, and spending enough time in Claude Code sessions that the overhead of ad-hoc prompting has become a noticeable friction point.
Solo founders and indie developers benefit most from the Founder gear commands. If you are simultaneously responsible for product direction, engineering, and quality, gstack helps you partition your thinking — spending time in each perspective deliberately rather than letting them blur together. The /plan and /retrospective commands in particular are valuable for solo operators who have no team to pressure-test their ideas.
Small engineering teams (2–15 engineers) get the most leverage from the Engineering Manager and QA gear commands. Standardizing /code-review across a team eliminates the inconsistency that comes from different reviewers prioritizing different things. The /qa command’s automated health reports create a shared quality baseline that everyone can reference.
Technical co-founders at YC-backed startups are arguably the target audience Garry Tan had in mind when building gstack. The workflow mirrors how high-performing early-stage teams actually operate: moving fast, wearing multiple hats, but doing so with deliberate role clarity at each decision point.
Individual contributors at larger companies can use gstack to self-improve their code review and planning habits, even if the broader team does not adopt it. The commands work entirely within your own Claude Code session — there is no team-wide infrastructure required.
gstack is probably not the right tool if you are primarily using Claude Code for one-off tasks, exploratory research, or domains outside software development. The 13 commands are tightly oriented around the build-review-ship cycle of product development, and that specificity is both their strength and their limitation.
For context on how gstack compares to other AI-powered development environments, see our overview of OpenDevin, which takes a different approach to autonomous AI coding agents.
Frequently Asked Questions
Do I need to pay for gstack itself?
No. gstack is completely free and open-source. The only cost is your existing Claude Code subscription, which you need to use Claude Code itself. gstack is simply a collection of configuration files and prompt templates that install into Claude Code’s skills directory — there is no separate service, no API, and no licensing fee.
Which version of Claude Code does gstack require?
gstack requires a version of Claude Code that supports the skills directory system (~/.claude/skills/). This feature was introduced in Claude Code’s skills architecture update. If your Claude Code installation supports slash commands loaded from the skills directory, gstack will work. If you are unsure, try the installation steps — Claude Code will surface an error if the skills system is not available in your version.
Can I customize the gears and commands?
Yes. Because gstack is installed as a local git clone, you can edit any of the command files directly. Each slash command corresponds to a file in the gstack directory, and the gear personas are defined in system prompt configuration files that you can modify. You can add new commands, adjust the persona definitions, or remove commands you do not use. If you develop improvements that would benefit other users, the project welcomes pull requests.
Who created gstack and why?
gstack was created by Garry Tan, the CEO of Y Combinator. Tan built gstack to solve a workflow problem he observed in his own Claude Code usage: the AI’s tendency to blend multiple perspectives together in a way that reduced the usefulness of each individual perspective. The “gears” model emerged from the insight that specialized roles — the kind of role clarity that makes high-performing human teams effective — could be replicated in AI-assisted workflows through structured persona switching. As someone who evaluates hundreds of startups per year and thinks deeply about how developers and founders work, Tan was well-positioned to design a framework that reflects real professional practice rather than theoretical best practices.
Next Steps
Now that you understand what gstack is and how its gear system works, the logical next step is getting it installed and running your first commands. Our next article walks through the complete installation process, including how to configure config.yaml for your workflow, verify that all 13 commands are available, and run your first /plan and /qa sessions on a real project.
If you want to go deeper on the conceptual foundations — particularly how structured prompting and role separation improve AI output quality — our guide to prompt engineering for AI agents covers the techniques that underpin gstack’s gear design.
For a broader picture of the AI coding agent landscape and how purpose-built tools like gstack differ from fully autonomous coding agents, the OpenDevin overview is a useful companion read.