A Bunch of Markdown Files — Why Is That Worth 110K Stars?
> "You know, when I first saw the gstack project, my reaction was the same as yours: 'How can this possibly be worth 110K stars?'"
I opened the repository and saw a bunch of Markdown files. No compiler, no runtime, no Docker containers. Just — a bunch of text files.
I thought maybe I'd missed something. Maybe there was a hidden Python script, or some kind of framework I couldn't see. I checked every directory carefully. Nothing. It really was just a bunch of text.
Then I started reading them. Then I started understanding.
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 was impossible, some said it was all config files, some credited AI.
All of those arguments are wrong.
The 37K number is like Feynman saying "the safe's combination is three digits" — interesting, but irrelevant to the essence. The real question is: how did he do it?
The answer isn't "he used some magic tool." The answer is: he turned his workflow into discipline, and then wrote that discipline into roles.
Let me explain the Feynman way: imagine you're a chef. You make the same few dishes every day. Some people rely on muscle memory and, ten years later, are still making those same dishes. But one chef is different — before cooking, he asks himself: "What role am I playing today? The 'creative head chef' or the 'quality inspector'?"
If he's the "creative head chef," he freely experiments with new ingredients. If he's the "quality inspector," he rigorously checks every step.
That's exactly what gstack does: it gives Claude a set of "role switchers."
---
2. 35 Slash Commands, Each One a Door
/qa→ switch to QA mode/office-hours→ switch to startup-mentor mode/review→ switch to code-review mode- "You are a QA engineer"
- "Your task is to systematically find bugs, not offer suggestions"
- "After finding a bug: record first, then fix, then verify, then write a report"
- "Don't rush to finish fixes; make sure every fix is verified"
Each command is essentially a role switcher. It tells Claude: "Right now you're not a general-purpose assistant; you're a specialist at this one thing."
It sounds simple. But let me tell you why it's more powerful than you think.
Have you ever had this experience: you ask Claude to write code, and it does fine. Then you say "check it for bugs," and the review is perfunctory. Then you say "write documentation," and it's formulaic.
Why? Because you never gave it a role. It doesn't know how thorough a "check" should be, or whose style the documentation should follow.
gstack's cleverness: it doesn't expect Claude to figure out how to behave on its own — it explicitly tells it "here's who you are right now."
The /qa Skill file is full of instructions like:
---
3. The Three Things Truly Worth Stealing
I went through all 35 Skills. Most are for specific scenarios — /i18n for internationalization, /sql-migrate for database migrations. You may not need these.
But three things can be taken away by anyone:
1. QA's Closed-Loop Thinking
gstack's /qa isn't "help me test this" — it's the complete cycle of "discover → record → fix → verify → report."
Key insight: never let Claude play both "discoverer" and "fixer" at the same time. Let it discover with full force first, then you decide the fix order, then it fixes, then it verifies, then it writes the report.
This solves AI coding's biggest trap: fixing one bug introduces two new ones, and you assume it's "good enough."
2. Refactor Requirements Before Writing Code
gstack's README has a classic example: don't say "build me a login feature" directly — first say "refactor the requirements document until it's clear."
The concrete workflow:
1. Give Claude the vague requirements document 2. Have it ask 5 clarifying questions 3. Have it rewrite the requirements in user-story format 4. Then start writing code
The time this saves is ten times more than the time it costs. Because AI writes code fast, but rewriting code written in the wrong direction is slower than writing it by hand.
3. Role Separation as Meta-Cognition
This is the most important, and the most abstract.
gstack's core philosophy: don't let yourself be creator, reviewer, and decision-maker simultaneously. Play only one role at a time.
During /plan you're the strategist. During /code you're the engineer. During /review you're the reviewer. During /qa you're the tester. During /office-hours you're the founder.
Why does this work? Because human cognitive resources are limited. You can't hold "creative divergence" and "rigorous review" in mind at the same time. Neither can AI.
---
4. An Analogy: Why This Is a "Feynman-Style" Solution
Feynman once told a story: someone asked how he solved that really hard physics problem.
He said: "I didn't solve it. I just broke it into parts small enough that each one was too simple to get wrong."
That's exactly what gstack does.
It invented no new programming language. Built no new framework. Trained no new model. It simply took "software development" — something too complex to get right in one pass — and split it into 35 roles, each responsible for one small piece, each simple enough that it's nearly impossible to get wrong.
This is not a technical breakthrough. It's a cognitive breakthrough.
---
5. Are Those 110K Stars Worth It?
My verdict: 100K of them are star-chasing; 10K are actually practicing.
If you're in that 10K — you're already using Claude Code, you want it to be more "disciplined," you want to reduce the "close enough" hallucinations — then gstack is worth a look.
But don't copy it wholesale. Of the 35 Skills, you probably need 3–5. Take their spirit and write your own CLAUDE.md.
If you're in the 100K — just curious "how does the YC CEO write 37K lines a day" — then you already know the answer: it's not that he's faster than others; it's that he spends on execution the time others spend agonizing.
---
6. Back to the Original Question
So — a bunch of Markdown files. Why worth 110K stars?
Because they prove 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 just wrote 35 "job descriptions," telling Claude who to be in different situations.
This is something everyone can do. But most people don't.
That's why it's worth 110K stars. Not because the technology is hard, but because doing this takes more than technology — it takes discipline, taste, and the patience to write processes as roles.
And that is 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 right now, don't install all of gstack. Just do this: before asking Claude to write code next time, tell it: "You are now a requirements analyst. Before writing any code, ask me 5 clarifying questions, then rewrite the requirements in user-story format."
See what happens. I bet you'll be surprised.
---
*Tags from the original post: AI coding, Claude Code, gstack, developer productivity, prompt engineering, YC, AI workflows, role switching.*