Skip to content
BSWEN
Blog

What is gstack? Garry Tan's Claude Code Skill Pack Explained

Cowrie
Cowrie
Dev @ Bswen

Purpose

I saw a Reddit thread about Garry Tan’s Claude Code configuration. The post claimed he ships 10k-20k lines of production code per day with a “structured virtual team” approach. The comments were polarized - some called it revolutionary, others mocked the “5M+ lines per year” math. I wanted to understand what gstack actually does and whether the role-based prompting approach has merit.

What is gstack?

gstack is an open-source skill pack for Claude Code created by Y Combinator CEO Garry Tan. It transforms Claude Code from a generic AI assistant into a structured virtual development team by assigning distinct roles through custom slash commands.

The core idea: instead of one monolithic prompt, gstack gives Claude specific personas for each task. Each role operates within a defined workflow phase.

gstack-role-structure
Role Assignment via Slash Commands:


/ceo        - Strategic decisions, priorities, trade-offs
/pm         - Product requirements, user stories, acceptance criteria
/designer   - UI/UX decisions, component structure, user flows
/em         - Engineering management, task breakdown, sprint planning
/qalead     - Testing strategy, quality gates, bug triage
/security   - Security review, vulnerability assessment, compliance
/release    - Deployment, versioning, release notes
/reflect    - Retrospective, lessons learned, process improvement

The Workflow Phases

gstack groups software delivery into distinct modes rather than one continuous session:

workflow-phases
Think → Plan → Build → Review → Test → Ship → Reflect


Each phase has a dedicated role:
- Think: /ceo (strategic direction)
- Plan: /pm + /em (requirements + breakdown)
- Build: /em (implementation oversight)
- Review: /qalead (quality check)
- Test: /qalead (automated testing)
- Ship: /release (deployment)
- Reflect: /reflect (process improvement)

This structure prevents the context dilution problem I discussed in my previous post about Claude Code workflows. By switching roles, Claude gets fresh context for each phase.

The Browser Automation Component

What makes gstack different from other skill packs is the persistent browser runtime. The /qatest skill uses Playwright to run real browser tests:

browser-testing-flow
/qatest command:


1. Launches Playwright browser session
2. Executes test scenarios against running app
3. Captures screenshots and console logs
4. Reports failures with detailed context
5. Suggests fixes based on observed behavior


This is actual E2E testing, not simulated tests.

I tried similar browser automation with other Claude Code setups. The difference here is the persistent runtime - the browser stays alive across multiple test runs, reducing startup overhead.

How Role-Based Prompting Works

The key innovation in gstack is role assignment. Let me explain what this means technically.

Each slash command injects a specific persona into Claude’s context:

role-prompt-example
When you type /ceo:


Context injection:
"You are the CEO making strategic decisions. Your priorities:
- User value over technical elegance
- Speed over perfection
- Clear communication over comprehensive documentation
- Ship fast, iterate faster


Current decision needed: [user's request]"


Claude responds with CEO-level thinking, not engineer-level implementation details.

This is different from giving Claude a single comprehensive instruction. The role switch forces Claude to adopt a specific perspective for each phase.

I tested this approach in my own workflow. When I use /pm, Claude asks about user stories and acceptance criteria. When I use /em, Claude focuses on task breakdown and technical feasibility. Same model, different output because of different context framing.

The Claims vs Reality

The Reddit thread sparked debate about gstack’s claims. Let me break down what’s real and what’s hype:

claims-analysis
CLAIMED: 10k-20k lines of production code per day
REALITY: This depends entirely on project complexity and Claude's token limits


CLAIMED: Structured virtual team
REALITY: It's role-based prompting, not actual team collaboration


CLAIMED: MIT licensed, fully open-source
REALITY: Yes, available on GitHub


CLAIMED: Sprint-as-a-process
REALITY: Useful framing for workflow organization

The top Reddit comment pointed out:

“So 5M+ lines of code per year! As we all know, more code is always better so it must be really good.”

This sarcasm highlights a valid concern. Code volume isn’t a success metric. The real question is whether role-based prompting improves code quality and workflow efficiency.

What I Found Useful

After examining the approach, I identified three aspects worth adopting:

1. Role Switching Prevents Context Dilution

When I use Claude Code for a long session, it forgets earlier decisions. By switching roles with slash commands, each phase starts fresh with focused context. This addresses the context dilution problem I described in my workflow guide.

2. Browser Testing Integration

The Playwright integration for /qatest provides actual E2E testing. This is more reliable than asking Claude to “think about test scenarios.” Real browser execution catches real bugs.

3. Explicit Phase Separation

The Think → Plan → Build → Review → Test → Ship → Reflect flow matches what I already recommend for Claude Code workflows. gstack just makes it explicit with dedicated commands.

What I Question

Three aspects concern me:

1. Role Overhead

Switching between 8 roles adds friction. For small tasks, this overhead might slow development more than it helps. I would use this for complex multi-day projects, not quick fixes.

2. “CEO” Role in Software Development

The /ceo role makes strategic decisions. But I’m the CEO of my own projects. Having Claude pretend to be CEO feels like unnecessary theater. I would skip this role and make decisions myself.

3. Line Count Metrics

The focus on “lines of code shipped” is counterproductive. Good software minimizes code, not maximizes it. I judge success by functionality, not volume.

How to Try gstack

If you want to test this approach:

installation
# Clone the repository
git clone https://github.com/garrytan/gstack.git


# Copy skills to your Claude configuration
cp -r gstack/skills ~/.claude/skills/


# Restart Claude Code
claude

Then use slash commands during your workflow:

example-usage
# Strategic decision
/ceo Should we use PostgreSQL or MongoDB for this project?


# Requirements
/pm Define user stories for the authentication feature


# Implementation
/em Break down the auth implementation into tasks


# Testing
/qatest Run browser tests on the login flow


# Deployment
/release Prepare version 1.0.0 release notes


# Reflection
/reflect What went wrong in this sprint?

When This Approach Fits

gstack-style role prompting works best for:

use-case-matrix
GOOD FIT:
- Complex projects spanning multiple days
- Team-sized complexity (many moving parts)
- Projects needing formal QA process
- Teams with defined roles (mirrors real structure)


POOR FIT:
- Quick fixes and small tasks
- Single-feature additions
- Prototypes and experiments
- Solo developers on simple projects

For solo developers, I recommend a simplified version: use /plan, /build, /review phases without all eight roles. The overhead reduction makes the workflow more practical.

The Broader Context

TechCrunch reported that Garry Tan described having “cyber psychosis” from AI agent excitement, sleeping only 4 hours a night. This suggests the claims come from genuine enthusiasm, not calculated marketing.

The thousands of developers trying gstack reflect a real demand: developers want structured workflows for AI coding assistants. The role-based approach addresses the “magic genie” problem where Claude generates code without clear direction.

MarkTechPost noted gstack packages Claude Code into “8 opinionated workflow skills” backed by a persistent browser runtime. The opinionated nature means some decisions are pre-made for you - both a benefit (less thinking) and a drawback (less flexibility).

Summary

In this post, I explained what gstack is and how it works with Claude Code. The key points:

  1. Role-based prompting: Slash commands assign specific personas (CEO, PM, EM, QA Lead, etc.) for each workflow phase
  2. Workflow phases: Think → Plan → Build → Review → Test → Ship → Reflect provides structured progression
  3. Browser automation: Playwright integration enables real E2E testing
  4. MIT licensed: Open-source and available on GitHub
  5. Practical value: Role switching addresses context dilution; explicit phases prevent ad-hoc development

The approach has merit for complex projects. For simple tasks, the overhead may outweigh benefits. I recommend a simplified version: adopt the phase structure without all eight roles.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments

Tags: