gstack Explained: The Discipline Taught by a Bunch of Markdown Files Behind 110K Stars

> "When I first opened the gstack repository, my reaction was the same as yours: 'How can this possibly be worth 110K stars?'"

I opened the repo and saw a bunch of Markdown files. No compiler, no runtime, no Docker containers. Just text files.

I thought maybe I'd missed something — a hidden Python script, some framework I couldn't see. I checked every directory. Nothing. It really is just a bunch of text.

Then I started reading them. Then I understood.

Let me tell you what happened.

---

1. First, Forget "37K Lines a Day"

Garry Tan said he writes 37,000 lines of code a day. Hacker News exploded. Some said it's impossible, some said it's all config files, some credited AI.

All of those arguments miss the point.

The 37K number is like Feynman saying "the safe's code is three digits" — interesting, but irrelevant to the essence. The real question is: how did he do it?

The answer isn't a magic tool. The answer is: he turned his workflow into discipline, then wrote the discipline into roles.

A Feynman-style analogy: imagine you're a chef making the same dishes daily. Most chefs rely on muscle memory for ten years. But one chef asks before cooking: "What role am I playing today — creative head chef, or quality inspector?" As head chef, he freely experiments. As inspector, he rigorously checks every step.

gstack does exactly this: it gives Claude a role switcher.

---

2. 35 Slash Commands, Each a Door

• /qa → switch to QA mode
• /office-hours → switch to startup-mentor mode
• /review → switch to code-review mode

Each command is a role switcher. It tells Claude: "Right now you're not a general assistant — you're the person who does this one thing."

Why is this more powerful than it sounds? Because when you ask Claude to write code, then check for bugs, then write docs, the results are shallow — you never gave it a role. It doesn't know how deep a "check" should go, or whose style the docs should follow.

gstack's cleverness: it doesn't expect Claude to know what to do — it explicitly tells it who it is.

The /qa skill file is full of instructions like:

• "You are a QA engineer"
• "Your task is to systematically find bugs, not give advice"
• "After finding a bug: record it, fix it, verify it, then write a report"
• "Don't rush — make sure every fix is verified"

---

3. Three Things Worth Stealing

Most of the 35 skills are situational (/i18n for localization, /sql-migrate for database migrations). You may not need them. But three things anyone can take away:

1. QA's closed-loop thinking

gstack's /qa isn't "test this for me" — it's a complete cycle of discover → record → fix → verify → report.

Key insight: don't let Claude play both "finder" and "fixer" at once. Let it find everything first, then you decide the fix order, then it fixes, verifies, and reports.

This solves AI coding's biggest trap: fixing one bug while introducing two new ones, then assuming "it's about done."

2. Refactor requirements before writing code

The README has a classic example: instead of "write me a login feature," first say "restructure the requirements clearly."

Concretely: 1. Give Claude a vague requirements document 2. Have it ask 5 clarifying questions 3. Have it rewrite the requirements as user stories 4. Only then start coding

This saves ten times more time than it costs. AI writes code fast, but rewriting code that went the wrong direction is slower than a human writing it from scratch.

3. Role separation as meta-cognition

The most important and most abstract one. gstack's core idea: don't be creator, reviewer, and decision-maker simultaneously. Do one role at a time.

With /plan you're a strategist. With /code an engineer. With /review an inspector. With /qa a tester. With /office-hours a founder.

Why it works: human cognitive resources are limited. You can't hold "creative divergence" and "strict review" at the same time. Neither can AI.

---

4. Why This Is a "Feynman-Style" Solution

Feynman once told a story: someone asked how he solved a very hard physics problem. He said: "I didn't solve it. I just broke it into pieces small enough that each one was too simple to get wrong."

That's exactly what gstack does. No new language, no new framework, no new model. It just splits "software development" — too complex to get right in one pass — into 35 roles, each responsible for a small piece that's too simple to fail.

This isn't a technical breakthrough. It's a cognitive breakthrough.

---

5. Are Those 110K Stars Deserved?

My judgment: 100K are star-gazers; 10K are actually practicing it.

If you're in the latter group — already using Claude Code, wanting more discipline, wanting fewer "close enough" hallucinations — gstack is worth a look.

But don't copy everything. Of the 35 skills, you probably need 3-5. Steal the spirit and write your own CLAUDE.md.

If you're in the former group — just curious how YC's CEO writes 37K lines a day — you already know the answer: it's not that he's faster; it's that he spends on execution the time others spend deliberating.

---

6. Back to the Question

So why is a pile of Markdown files worth 110K stars?

Because it proves one thing: in the AI era, the most valuable thing isn't a new framework — it's the ability to turn old processes into new discipline.

Garry Tan didn't write a single line of Python to make Claude better. He wrote 35 "job descriptions" telling Claude who to be in different situations.

This is something anyone can do. Most people just don't.

That's why it's worth 110K stars — not because the technology is hard, but because doing it requires more than technology: discipline, taste, and the patience to write processes as roles.

And that's the scarcest thing in the AI era.

---

> "I have no special talent. I am only passionately curious." > — Richard Feynman (probably)

The next step after curiosity is always action.

If you want to try one thing now, don't install all of gstack. Do just this: next time before asking Claude to write code, tell it: "You are now a requirements analyst. Before writing code, ask me 5 clarifying questions, then rewrite the requirements as user stories."

See what happens. I bet you'll be surprised.