I read through it expecting to roll my eyes. Instead I sat there nodding, because I’d accidentally built a tiny version of the same thing for this blog.

The pitch

gstack’s whole argument is that solo builders don’t lose to big teams because they’re worse engineers. They lose because they skip process. One person at a keyboard, prompting Claude into existence one vibe at a time, eventually ships something that works. Until it doesn’t. No review. No second opinion. No one asking “wait, should we even build this?”

So gstack bakes the process in. Every skill is a slash command, and each command plays a role in a pipeline:

Think → Plan → Build → Review → Test → Ship → Reflect

You start a project with /office-hours, which hits you with six forcing questions before you write a line of code. Then /plan-ceo-review challenges your scope. /plan-eng-review draws the data-flow diagrams and enumerates the edge cases. You build. /review does a staff-engineer pass and auto-fixes the obvious stuff. /qa opens an actual Chromium browser, clicks through your app, finds bugs, and writes a regression test for each one it fixes. /ship runs the suite and opens the PR.

Each stage feeds the next. The CEO’s decisions constrain the engineer. The engineer’s plan constrains the build. Nothing happens in a vacuum. That’s exactly the part solo work gets wrong.

There’s a whole security wing too. A /cso skill that runs OWASP Top 10 and STRIDE threat modeling. A sidebar Claude that watches for prompt injection. A /careful mode that warns you before rm -rf ruins your afternoon. It’s a lot. The point isn’t that you use all of it. The point is that the roles exist, named and on call.

Why this looked familiar

Here’s the thing. I don’t ship code through a blog. I ship words. But the moment I saw that pipeline I recognized it, because the posts you’re reading go through the same kind of relay.

When I write here, an idea doesn’t go straight from my head to WordPress. It moves through stages, and each stage has one job:

• Research does the digging and writes up a structured report. Pitch, key facts, angle, the competition check.
• Refine tightens the structure and pacing without touching the voice.
• De-slop strips out the AI tells. The em-dashes, the “it’s not just X, it’s Y,” the forced enthusiasm, the closer that tries to sound profound.
• Voice rewrites it to sound like me. Short sentences. Plain words. No throat-clearing.
• Format turns it into clean WordPress blocks.

Each one hands off to the next. Same shape as gstack. A CEO who reframes the product is doing what my research stage does for a post. A designer who catches AI slop is, almost word for word, my de-slop pass. Garry Tan built an org chart for shipping software. I built a smaller one for shipping writing, and I didn’t even notice the resemblance until his showed up.

I’m not claiming I invented anything. The idea is in the water. Once you spend enough time working alongside an agent, you stop treating it like one genius who does everything and start treating it like a team you have to manage. You give each role a narrow job and a clean handoff. That’s not a trick. It’s just how good teams have always worked, now running in a terminal.

The number everyone’s going to argue about

gstack ships with a doc making a bold claim: Garry measured his own output and found he’s writing about 810 times more code per day than he did back in 2013 when he was coding part-time around a day job. Eleven thousand logical lines a day across his first 108 days.

Your skepticism alarm should be going off. So was his. He concedes up front that lines of code is a garbage quality metric. His own line: measuring programming progress by lines of code is like measuring aircraft-building progress by weight. So he deflates the number hard. Strips comments and blanks, applies a 2x penalty for AI being verbose and defensive, and lands at something like 5,700 lines a day. Still a wild figure. Still self-reported, so take it with salt.

But the interesting claim isn’t the speed. It’s the quality holding steady while the speed goes up. A 2 percent revert rate, right in line with the open-source baseline. Two thousand-plus automated tests with CI. A 95 percent success rate across 305,000 skill runs. His actual thesis is buried under the headline number:

“Testing at multiple levels is what makes AI-assisted coding actually work.”

That one I believe without reservation, because it’s the same thing the pipeline is really about. The process isn’t there to make the agent faster. It’s there to catch the agent when it’s confidently wrong, which it will be, several times a day. Every stage is a checkpoint, a chance for something to get caught before it ships. The payoff isn’t speed, it’s fewer mistakes reaching the end.

What I did with it

I’m not installing the whole thing. gstack is TypeScript and Bun and Playwright, built for shipping web apps, and Windows is a second-class citizen in it. Not my stack. Not my use case.

So I stole the front of it instead. The skill I keep coming back to is /office-hours: six forcing questions you have to answer before you’re allowed to build anything. Who is this for. What’s the sharpest version of it. What are you quietly avoiding. It’s a CEO review for an idea that doesn’t exist yet.

That maps straight onto the worst part of blogging, which is deciding what’s even worth writing. So I pointed it at this blog. Before a topic earns a draft, I run it through the same kind of interrogation in Claude Code. What’s the one sentence. Who already wrote it better. What’s the angle only I have. Why now. Most ideas die right there, which is the point. The ones that live show up to the draft stage already knowing what they are.

This post is one of them. gstack was the raw idea. The forcing questions are what turned “gstack exists, that’s neat” into something with an angle worth your time. The tool I borrowed from is the tool that helped me write about borrowing from it.

So here’s what you should know today. gstack is out there, it’s free, and even if you never run a line of it, the shape is worth stealing. Garry Tan built that discipline for code. I run a lighter version of it on words. You can point it at whatever you make. The pipeline is the product. The agent’s just the labor.