Garry Tan Publishes His Claude Code Setup: 23 Role-Based Tools and 139K Stars

A familiar picture: you ask an AI agent to "build a feature," and in a single stream it invents the product, sketches the interface, writes the code, praises itself and forgets about the documentation. The result is usually mediocre across the board. The garrytan/gstack repository tries to fix exactly this, and today it is again in the daily top of GitHub Trending: 139,039 stars in total and 285 over the past day.

What this toolkit is

Garry Tan positions gstack as his fine-tuned setup for Claude Code. The project description says it consists of 23 "opinionated" tools that work as a CEO, designer, engineering manager, release manager, documentation engineer and QA. The project's language is TypeScript.

An important caveat: we rely on the repository description and its metrics. A line-by-line review of each of the 23 tools is not provided here, and you should do one yourself before adopting it.

Why roles work better than a general prompt

The logic is simple and familiar to anyone who has built a team. When one person is responsible for both the product decision and quality control, they tend to agree with themselves. The same goes for a language model: if it both writes the code and evaluates it in one context, the critique turns out soft.

Imagine a typical day. You want to add a settings screen to a service. In a role-based scheme, the order might look like this:

• the "CEO" checks whether the feature is needed at all and what matters most in it;
• the "designer" describes the screen states and edge cases;
• the "engineering manager" splits the task into steps;
• "QA" separately tries to break the result;
• the "release manager" and the "documentation editor" tie up loose ends: the version, the changelog, the README.

Each role gets its own instructions and its own success criteria. This isn't magic but process discipline built into the tools, so you don't have to keep it in your head and rewrite the prompt every time.

Why people are talking about it

The first reason is obvious: the author's name. When the head of a major startup accelerator shows exactly how he works with an agent, it is interesting as a working artifact, not as theory. The second reason runs deeper: the community is tired of abstract talk about agents and wants to see concrete configurations that can be copied and run.

Stars, however, should be read carefully. 139 thousand indicate attention and curiosity, but not proven productivity. A repository's popularity is no substitute for measurements on your own codebase.

Limitations

The description honestly says the tools are "opinionated." That means other people's tastes are baked in: what a good release should look like, what counts as sufficient documentation, how strict QA should be. For a team with a different stack, different conventions or regulatory requirements, some of the rules will have to be rewritten.

There is also a hidden cost: more roles mean more model calls, more tokens and more places where something can go wrong. If you have a small project, 23 tools may be excessive, and two or three will do.

What to do in practice

Don't install the whole set on a production repository on day one. Better to do this:

• clone the project and read the role instructions: it's a free textbook on how to structure an agent's work;
• try two roles with the clearest benefit, for example QA and documentation;
• run them on a small task and compare the result with your usual approach;
• keep what worked and throw out the rest.

Product people and founders should look at gstack from another angle: as a process template. Even if you don't use the code itself, the question "which roles in my agent-assisted development is nobody playing yet" is useful. Most often it is exactly quality control and release hygiene.

The main takeaway: the value of gstack isn't that it is the "best setup," but that it shows what mature work with a coding agent looks like: roles, rules and separation of responsibilities instead of one long prompt.