awesome-skills

A Deep Dive into gstack

Table of Contents


1. Project Overview

gstack is an open-source AI coding factory and virtual engineering team workflow created by Garry Tan, current President and CEO of Y Combinator. The project is built on a core philosophy: AI should not work in a single generic cognitive mode — it needs clearly defined role specialization.

By encapsulating structured software engineering roles (CEO, Engineering Manager, Designer, QA, Release Engineer, etc.) as specific AI skills (Skills), gstack successfully transforms AI coding assistants such as Claude Code into a disciplined virtual engineering team where every member has a well-defined job. Garry Tan himself has publicly stated that with this workflow, while serving as YC CEO, he wrote over 600,000 lines of production-grade code in 60 days on a part-time schedule (10,000–20,000 lines per day). The community has hailed this as “one person with the productivity of a twenty-person engineering team.”

Core features of the project include:


2. System Architecture Analysis

gstack’s system architecture is primarily divided into two dimensions: the AI skill dispatch layer and the headless browser interaction layer. To solve the cold-start latency (~2–3 seconds) and state loss (e.g., Cookies, login state) that AI agents encounter when frequently invoking the browser, gstack innovatively introduces a C/S (client/server) daemon model.

We can think of this architecture as a virtual test engineer:

2.1 System Architecture Diagram

The entire system achieves strict decoupling from top to bottom: the AI agent at the top issues commands by invoking a locally compiled CLI tool; the CLI acts as a lightweight client communicating with a resident Bun Server over HTTP; the Server drives the underlying Playwright Chromium instance directly via CDP (Chrome DevTools Protocol) and asynchronously flushes logs to disk.

graph TD
    subgraph AI Agent Layer
        A[Claude Code / Codex] -->|Invoke Skill| B[SKILL.md Prompts]
        B -->|Tool Call: $B command| C(CLI - Compiled Binary)
    end

    subgraph gstack Browse Daemon
        C -->|1. Read .gstack/browse.json| C
        C -->|2. HTTP POST| D[Server - Bun.serve]
        D -->|Dispatch| E[Browser Manager]
    end

    subgraph Headless Browser
        E -->|CDP| F[Chromium - Playwright]
        F -->|Render| G[Web Page]
        F -.->|Log/Network/Dialog| H[(In-Memory Buffers)]
        H -.->|Async Flush| I[Disk Logs]
    end

2.2 Key Architecture Design Decisions

This section details several key design decisions in the system architecture, including the use of the Bun runtime, the state persistence scheme, and security isolation strategies.

  1. Extreme use of Bun:
    • Uses bun build --compile to package the CLI into a single executable, eliminating runtime node_modules dependencies, ~58MB in size.
    • Uses Bun’s native SQLite support for Cookie decryption, avoiding the need to compile C++ extensions such as better-sqlite3, greatly improving cross-platform compatibility.
    • Uses the built-in Bun.serve() to provide a minimal HTTP service handling 20+ core routes, avoiding the overhead of redundant Express/Fastify frameworks.
    • Native TypeScript support: during development you can run bun run server.ts directly without precompilation.
  2. Daemon and state persistence:
    • The server runs as a resident background process; the CLI is just a lightweight wrapper.
    • Maintains login state, LocalStorage, and open tabs, making continuous QA interactions possible for the AI.
    • Dynamic port allocation: randomly assigns a port between 10000 and 60000, allowing multiple Workspaces to run concurrently on the same machine without conflicts.
  3. Security isolation:
    • The HTTP server binds only to localhost, forbidding external network access.
    • A random UUID Token is generated per session (based on Bearer Auth) to prevent unauthorized cross-process calls.
    • Cookie import requires system-level Keychain authorization; data is decrypted in memory (PBKDF2 + AES-128-CBC), never written to disk in plaintext, and never appears in any logs.
  4. Accessibility-tree Ref system:
    • Calls page.accessibility.snapshot() to obtain the ARIA (Accessible Rich Internet Applications) tree and assigns sequential numbers to each element (e.g., @e1, @e2).
    • Builds a Locator for each element and detects whether the element is stale before operations (count() === 0 throws an exception), solving the frequent failures of traditional CSS selectors with Shadow DOM and framework hydration.
    • Ref lifecycle and cleanup: On page navigation (the framenavigated event), all Refs are automatically cleaned up. This is a defensive design that requires the agent to re-run snapshot after navigation to obtain fresh references, avoiding clicks on wrong or stale elements.
    • Introduces cursor-clickable references (@c1, @c2), captured via the -C flag for elements not present in the ARIA tree but actually clickable by cursor (e.g., divs with cursor: pointer or custom onclick).
  5. Logging architecture:
    • Uses three ring buffers, each with a capacity of 50,000 records, storing Console, Network, and Dialog events respectively.
    • O(1) in-memory writes, asynchronously flushed to disk files (every second), ensuring HTTP requests are never blocked by disk I/O.

3. Core Low-Level Modules

This chapter analyzes the low-level infrastructure modules in the gstack project. Unlike the Markdown-based skill definitions, these modules are developed in TypeScript and are primarily responsible for system-level interactions and automation tasks. Among them, the Headless Browser Engine provides AI agents with the ability to parse and interact with page DOM elements; the Skill Template Compiler is responsible for managing and generating the final skill documents, ensuring configuration consistency across environments.

3.1 Headless Browser Engine (browse)

This module lives in the browse/src/ directory and is built on Playwright to run automated browser tasks in the background and expose standard interaction interfaces.

3.2 Skill Template Compiler (gen-skill-docs)

This module lives at scripts/gen-skill-docs.ts and mainly implements automated building and rendering of skill documents (SKILL.md).


4. Overview of the AI Virtual Engineering Team Skills

This chapter details all the core skills stored in the .agents/skills/ directory. By defining specific system prompts, allowed tools, and execution hooks, these skills grant AI agents different professional roles. Based on where they apply in the software development lifecycle, these skills can be divided into four core layers: the product planning layer, the quality assurance layer, the release & operations layer, and the infrastructure layer.

4.1 Product Planning Layer

Skills in this layer are mainly used in the requirements analysis and architecture design phase before code is written, ensuring clear product goals, sound technical architecture, and consistent design standards.

4.2 Quality Assurance Layer

Skills in this layer run through the code development and testing phases, with the core goals of discovering latent defects, ensuring the robustness of code logic, and precise visual fidelity.

4.3 Release & Operations Layer

Skills in this layer are mainly used for automated management of the version release process and retrospective summaries of project cycles, ensuring efficient and transparent delivery.

4.4 Infrastructure Layer

Skills in this layer provide the underlying tools, system configuration entry points, and core security protection mechanisms that support higher-level business logic.


5. Teardown of Representative Skills and Prompt Engineering Best Practices

This chapter analyzes three representative .tmpl skill templates (/qa, /review, /plan-eng-review) in depth to show how gstack uses advanced prompt engineering techniques to transform AI from a “passive Q&A bot” into a “proactive engineering partner.” Building on this, we summarize reusable prompt design patterns.

5.1 Source-Level Teardown of Representative Skills

The following is a detailed analysis of the underlying workflows and prompt designs of gstack’s core skills, with excerpts of real template source code (prompt snippets).

5.1.1 /qa: End-to-End Testing and Fix Loop

This skill demonstrates how to orchestrate an extremely complex “test-fix-regress” multi-step state machine.

5.1.2 /review: Architecture-Level Review Beyond Syntax

This skill demonstrates how to get AI out of the “code formatter” mindset and perform deep business-logic review.

5.1.3 /plan-eng-review: Injecting Expert-Level Mental Models

This skill demonstrates how to inject the intuition and values of a senior human engineer into AI.

5.2 Summary of Prompt Engineering Best Practices

From the teardown above, we can extract four core design patterns for building advanced AI skills:

5.2.1 Structured Input Parsing and Defensive Design

5.2.2 Cross-Phase Context Inheritance

5.2.3 Injecting Expert-Level “Mental Models”

5.2.4 Dynamic Orchestration and Human-in-the-Loop Interaction


6. Core Execution Flow Analysis

This chapter walks through different types of skill commands to show how system components collaborate to fulfill AI agent requests. gstack’s execution flows fall roughly into two categories: plain-text planning (Markdown-driven) and system operations (code/browser-driven).

6.1 Plain-Text Planning Flows (e.g., /plan-eng-review)

The core of such skills lies in context reading and mental model injection. The execution flow is as follows:

  1. Environment exploration: The AI first runs bash scripts to read the current branch state and the project directory structure.
  2. Context mounting: The AI automatically searches for and reads *-design-*.md (design docs) generated by upstream phases.
  3. Intent review: Compares the current code changes against the design doc’s intent; if “scope creep” or an excessive number of changed files is detected, triggers AskUserQuestion to ask the user whether to reduce the scope.
  4. Output report: Generates a Markdown report in the format mandated by the prompt, including ASCII architecture diagrams, a test matrix, and security concerns.

6.2 System-Operation Flows (e.g., /qa with Browser Operations)

Taking the AI agent invoking the /qa skill and performing a click on a web page (executing the $B click @e1 command) as an example, the end-to-end flow involves calls to external processes:

sequenceDiagram
    participant Agent as AI Agent
    participant CLI as browse CLI
    participant Server as Bun Server
    participant Manager as BrowserManager
    participant Playwright as Chromium

    Agent->>CLI: Execute command $B click @e1
    CLI->>CLI: Check state file
    alt Server not started or stale
        CLI->>Server: spawn background process
        Server-->>CLI: Write new process info
    end
    CLI->>Server: Send HTTP POST request (with Token)
    Server->>Server: Authenticate and route command
    Server->>Manager: Call handler function
    Manager->>Manager: Parse @e1 to resolve node reference
    Manager->>Playwright: Execute click action
    Playwright-->>Manager: Page response events
    Manager-->>Server: Return operation result
    Server-->>CLI: Return HTTP status code
    CLI-->>Agent: Output result to console

In this flow, thanks to the daemon architecture, only the first call triggers a cold start; subsequent HTTP POST interactions are compressed to 100–200 ms of latency.


7. Quality and Performance Assessment (Including AI Skill Testing Methodology)

This chapter assesses the project’s engineering quality across multiple dimensions, including system performance and automated test coverage, and distills best practices for testing AI skills.

7.1 System Performance

Thanks to the resident-in-memory daemon architecture, the browser’s initial startup takes about 2–3 seconds, but all subsequent commands — DOM interactions, snapshot captures, network requests, and more — are compressed to 100–200 ms of latency. This lets AI agents “browse” pages as fluidly as humans, dramatically improving the execution efficiency of the /qa and /design-review skills.

7.2 AI Skill Testing Methodology (Automated Test Coverage)

Testing an AI agent with “autonomous thinking and operation capabilities” is a highly challenging engineering problem. gstack provides a textbook-worthy three-tier test architecture (see the test/ directory):

7.2.1 Tier 1 - Static Validation (Free and Extremely Fast)

This tier validates the basic logic and stability of the underlying core toolchain without depending on external LLM APIs.

7.2.2 Tier 2 - Real End-to-End Testing (Paid E2E)

This tier validates the AI agent’s actual ability to orchestrate external tools (e.g., the headless browser) and fix issues by simulating a human-AI conversation in a real sandbox environment.

7.2.3 Tier 3 - LLM-as-Judge Evaluation

Because AI agent output is non-deterministic, this tier introduces a high-intelligence third-party model to quantitatively evaluate the quality and accuracy of the results.

7.3 Stability and Isolation Design

Beyond performance and test coverage, gstack also introduces several mechanisms to ensure process management safety and pure isolation of the test environment.


8. Build and Deployment

This chapter details the project’s dependency management, build process, and deployment mechanisms. gstack provides a highly automated build script (setup) that greatly reduces configuration costs for users.

8.1 Dependency Management and Build Tools

The project uses Bun as its core package manager and build tool, greatly simplifying toolchain complexity in the Node.js ecosystem:

8.2 Core Build Pipeline (bun run build)

Running bun run build triggers a chain of automated build actions, including:

  1. Regenerate skill documents: Runs gen-skill-docs.ts to render all .tmpl template files into standard SKILL.md files, adapting paths to the host environment (Claude or Codex).
  2. Compile binaries: Compiles entry files such as browse/src/cli.ts into browse/dist/browse.
  3. Write version marker: Automatically obtains the current Git commit hash (git rev-parse HEAD) and writes it to the .version file, for later validation by the zombie process prevention mechanism.

8.3 Automated Install and Deploy Script (setup)

gstack provides a powerful setup bash script that handles complex environment detection and deployment logic:


9. Quick Start

This chapter is a guide for users who want to quickly experience the gstack workflow in their own Vibe Coding IDEs (e.g., Cursor, Trae).

9.1 Environment Requirements

Before getting started, ensure the current system meets the following baseline environment:

9.2 Global Installation

To let the AI assistant invoke gstack’s 23 core skills in any project, we recommend installing it into the global ~/.claude/skills directory.

Open a terminal and run the following commands:

# Clone the gstack repository to a local directory
git clone https://github.com/garrytan/gstack.git ~/gstack

# Enter the directory and run the automated install script
cd ~/gstack && ./setup --host auto

[!NOTE] The setup script automatically detects the AI tools installed on the system (e.g., Claude or Codex) and symlinks the compiled binaries and skill templates to the corresponding ~/.claude/skills/gstack or ~/.codex/skills/gstack directories.

9.3 Project-Level Configuration (Optional)

If you want other team members to have the same AI skill environment right after cloning the repository, you can pin gstack into the current project.

In the project root directory, run:

# Copy the globally installed gstack into the project's hidden directory
cp -Rf ~/.claude/skills/gstack .claude/skills/gstack

# Remove git history to avoid nested repository issues
rm -rf .claude/skills/gstack/.git

# Rebuild and register the skills inside the project
cd .claude/skills/gstack && ./setup

After that, we recommend creating a CLAUDE.md (or the IDE’s corresponding custom system prompt file) in the project root with the following content, guiding the AI on how to use these skills:

# AI Workflow Guide

Please use the skills provided under `.claude/skills/gstack` in this project.

- Use `/office-hours` and `/plan-ceo-review` during the planning phase
- Use `/review` for code review
- Use `/qa` and `/browse` for feature testing, and **never** use the built-in `mcp__claude-in-chrome__*` tools.

9.4 Your First Vibe Coding Sprint

After installation, open the IDE chat window and try the following “conversation flow” to experience the full gstack closed loop:

  1. Ideation: Tell the AI I want to add a user feedback collection popup to the current project, /office-hours.
  2. Architecture lock: After reading the design doc, tell the AI /plan-eng-review.
  3. Start coding: Once you agree with the architecture proposal, let the AI write code directly according to the plan.
  4. Test and fix: After the code is written, tell the AI /qa http://localhost:3000 (replace with your local dev address) and let it click the popup itself, discover bugs, and fix them.
  5. Prepare to merge: Tell the AI /ship — it will automatically run tests, generate commits, and push to the repository.

This article was written based on a snapshot of the gstack repository from July 2026. The repository is continuously and rapidly evolving, so some data may be outdated.