Founder OS — gstack: How YC’s CEO Engineers with Claude Code

Each mode is a separate skill file living in .claude/skills/gstack/. One job per file. One persona per session. No blending. No confusion.

You already use Claude Code heavily and want consistent, high-rigor workflows instead of one mushy generic mode. You have felt the pain of the AI trying to plan and code simultaneously, or reviewing its own work while writing it. gstack solves that by giving each cognitive job its own isolated persona, like hiring specialists instead of asking one generalist to do everything.

Most people dump everything into one prompt. Garry treats each mode as a separate cognitive stance, like switching between CEO, staff engineer, release engineer, and QA lead. The AI performs dramatically better because it knows exactly what job it has right now. Not “help me with my project.” Instead: “you are a paranoid staff engineer hunting for production incidents before they happen.”

CEO review does not build what was asked. It rethinks the problem from first principles and finds the dream version, the “10-star product,” then works backwards to what is shippable.

The core question: “If we could give the user a magical experience with zero constraints, what would that look like?” Then: “What is the 8-star version we can actually build?”

Every CEO review ends with one of three explicit stances:

EXPANSION: Dream ambitious. The feature request is actually too small. Expand scope because the opportunity is bigger than what was asked.

HOLD SCOPE: Bulletproof the current plan. The scope is right, now make it airtight. Fill gaps, tighten edges, add safety nets.

REDUCTION: Surgical minimum. Cut everything that is not essential to the core value proposition. Ship the smallest thing that proves the idea.

Every plan produced by CEO review must satisfy all nine. These are non-negotiable architectural constraints:

Engineering review takes the CEO-approved plan and turns it into a buildable architecture. The key insight: “LLMs get way more complete when you force them to draw the system.” Diagramming is not optional, it is the mechanism that prevents architectural drift.

This mode outputs architecture diagrams, sequence diagrams, state machines, and test matrices. It forces the model to think about system boundaries, data flow, failure modes, and trust boundaries, all before a single line of implementation.

gstack integrates with Greptile for automated PR comment triage. Every comment is classified as either a valid issue or a false positive. The system learns over time:

Auto-triage: Greptile scans the PR, generates comments, then gstack's review mode distinguishes valid issues from noise.

False positive learning: When a comment is marked as a false positive, it gets stored in .gstack/greptile-history.md. Future reviews auto-skip similar patterns. The system gets less noisy over time instead of more.

The key rule: “User's /ship command means proceed automatically without confirmation.” Every step runs sequentially. If any step fails, the entire process halts with a clear error.

The browser tool is a compiled binary (~58MB) built on Playwright and Bun. It runs a persistent Chromium daemon, not a headless screenshot tool that launches and dies on every command.

100-200ms response time on hot commands vs 3-5 seconds cold start on every action with typical browser MCP tools.

Session state carries across commands: cookies, localStorage, sessionStorage, and authentication all persist. Navigate to /dashboard, click a button, check the result, all without re-authenticating.

gstack does not use CSS selectors or XPath to target elements. Instead, it assigns stable refs like @e1, @e2 to interactive elements on the page. Three reasons CSS selectors fail in practice:

CSP blocks DOM injection: many production apps have Content Security Policies that prevent injecting attributes or scripts into the page. Refs are assigned server-side by the daemon, not injected into the DOM.

Framework hydration strips attributes: React, Next.js, and similar frameworks hydrate the DOM on load, stripping any custom attributes added before hydration completes. Refs are stable because they live in the daemon's element map, not the DOM.

Shadow DOM is unreachable: CSS selectors cannot pierce shadow DOM boundaries. The ref system can, because it uses Playwright's internal element handles which work regardless of DOM encapsulation.

Diff-aware (2-5 min): Reads the git diff, maps changed files to affected features, tests only what was touched. The default mode for active development.

Full (5-15 min): Complete test suite across all categories. Run before major releases or after large refactors.

Quick (30 sec): Smoke test. Hit the critical paths only: homepage loads, auth works, main feature functions. Useful for rapid iteration.

Regression (baseline comparison): Compares current state against a stored baseline. Detects visual regressions, broken links, new console errors, and performance degradation that were not present in the baseline.

Every QA run produces a single health score (0-10) computed from weighted category scores:

Before you can /browse an authenticated app, you need session state. The /setup-browser-cookies mode handles this: it logs in through the real login flow, captures the resulting cookies and localStorage, and stores them encrypted for reuse across future /browse and /qa sessions.

This means you run /setup-browser-cookies once per environment, and every subsequent /browse session starts already authenticated. No re-entering credentials. No token expiry surprises mid-QA.

Your Week: Deep-dive into the current period. What shipped, what slipped, what patterns emerged. Commits, LOC, test ratio, and fix ratio for the period.

Per-teammate breakdown: For each contributor: what they shipped, one specific praise (tied to a real commit), and one growth opportunity (tied to a real pattern). Not generic “great job”, specific “the retry logic in commit abc1234 was excellent because it handles partial failures.”

Team wins: Aggregate wins for the team. Shipping streaks, test coverage improvements, zero-downtime deployments.

Top 3 habits: The three patterns that had the most positive impact this period. These become priorities to reinforce in the next cycle.

gstack's browser tool is a compiled Bun binary (~58MB). Four reasons Bun was chosen over Node.js:

Compiled binaries: bun build --compile produces a single executable. No node_modules, no runtime dependency, no version conflicts. Copy the binary and it works.

Native SQLite: Bun includes SQLite as a first-class built-in. The browser daemon uses it for session state, cookie storage, and ref persistence. No external database process needed.

Native TypeScript: No transpilation step. Write TypeScript, run TypeScript. Faster iteration during development, simpler build pipeline.

Lightweight HTTP: Bun's HTTP server is significantly faster than Express or Fastify for the simple request/response pattern the daemon uses.

The browser daemon starts when the first /browse command runs and stays alive across commands. This is fundamentally different from tools that launch a browser per command.

Persistent state: Cookies, localStorage, sessionStorage, DOM state, scroll position, all survive between commands. You navigate to a page, fill a form, click submit, and verify the result page, all as separate commands with shared state.

Lifecycle management: The daemon tracks its own PID. If Claude Code exits, the daemon cleans up. If the daemon crashes, the CLI detects it and restarts on next command.

Multi-workspace safety: Each workspace gets its own daemon instance on a unique port. Running 10 Claude Code sessions via Conductor means 10 isolated Chromium instances with zero cross-contamination.

Most browser automation tools for Claude Code use MCP (Model Context Protocol). gstack deliberately chose plain text CLI instead. The reason is token efficiency.

The insight: every MCP call includes full JSON schemas, tool definitions, and structured responses. When you just need the text content of a page, all that structure is pure overhead. gstack's approach is simpler: plain text in, plain text out, piped through Bash tool calls.

Chromium crashes are inevitable. gstack handles them gracefully:

Server-side: If Chromium crashes, the daemon server exits cleanly (exit code 1). It does not hang or zombie.

Client-side: The CLI detects the dead daemon on the next command and automatically restarts it. The user sees a “daemon restarted” message and the command retries.

State recovery: Session cookies are persisted to SQLite, so re-authentication is automatic after a crash. The user loses in-page state (form inputs, scroll position) but not session state (auth, preferences).

The complete gstack layout inside a Claude Code project:

gstack is designed to work with Conductor (Claude Code's parallel execution mode). You can run 10 simultaneous Claude Code sessions, each with its own gstack mode active:

Session 1: /plan-ceo-review on feature A
Session 2: /review on PR #140
Session 3: /browse on staging environment
Session 4: /qa on feature B
...

Each session gets its own isolated Chromium instance (unique port, unique PID, unique session state). There is zero cross-contamination between sessions. The daemon model makes this possible, each workspace tracks its own browser lifecycle independently.

Clone the repo and the skills are ready to use immediately:

Here is how a single feature flows through gstack from idea to shipped: