The gstack workflow, from plan to retro

Verified against Claude Code 2.1.311 · Updated

Garry Tan, CEO of Y Combinator, open-sourced his personal Claude Code setup. The sprint table I counted today has 35 specialist rows, and the power-tools table has 14. The eight we originally ran (plan-ceo-review, plan-eng-review, review, ship, qa, retro, browse, setup-browser-cookies) are still in that sprint table. The walkthrough below is that original loop.

We installed those skills and ran through a real feature build to see how they work in practice. Spoiler alert: it’s awesome. Here’s how it went.

Installing gstack

In Claude Code

The README no longer documents npx skills add garrytan/gstack. The install it prints today is a clone into Claude’s skills directory, then ./setup. Bun is required. The README’s tested version is v1.4.2+, and setup refuses Bun older than 1.3.3. Node.js is listed as a Windows-only extra.

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

./setup builds the bundled browser when you don’t have Aside (macOS 15+). /browse drives Aside first, and falls back to that bundled Chromium when Aside is missing or not running. /setup-browser-cookies copies cookies into the fallback browser. If the Aside probe is already READY, that skill stops and tells you to use Aside.

In Codex

./setup --host codex installs into ${CODEX_HOME:-~/.codex}/skills/gstack-*/.

In Cursor

./setup --host cursor installs into ~/.cursor/skills/gstack-*/.

The skills CLI is a different installer. Its README lists OpenCode, Claude Code, Codex, Cursor, and 75 more (79 agents in docs/agents.md) and the flags npx skills add <owner>/<repo>, -s/--skill, -a/--agent, and -y. gstack’s own README does not use that command, so I did not keep it as the gstack install.

The workflow

gstack maps to a natural development cycle. Here’s the order we used:

  1. plan-ceo-review - Challenge the idea itself
  2. plan-eng-review - Lock in the technical approach
  3. (your agent writes code based on the plans)
  4. review - Pre-landing code review
  5. ship - Automated PR creation
  6. qa - Systematic testing
  7. retro - Weekly retrospective

You don’t have to use all of them, and they work fine individually. But the real value is in the full loop.

What we built

We used gstack to add an email newsletter signup form to the footer of this site (agent-config.com). Small feature, touches a few files, real enough to exercise each skill. We wrote a short plan document describing the goal and let gstack tear it apart.

Step 1: plan-ceo-review

This is the “should we even build this?” check. You give it a plan or feature idea, and it pressure-tests the concept with four modes:

  • Expansion: Dream bigger. What would make this 10x better?
  • Selective Expansion: Grow only the parts that pay off.
  • Hold Scope: The plan is accepted. Make it bulletproof.
  • Reduction: Cut everything that isn’t essential.

You pick the mode and the skill commits to it. It won’t silently drift toward a different posture mid-review.

What we saw: We ran it in HOLD SCOPE mode. The skill immediately caught that our plan referenced a component that didn’t exist. We’d written “move EmailCapture from the hero section to the footer” but the component was actually called NewsletterSignup.astro and it wasn’t in the hero at all. It was an orphan component not imported anywhere. That kind of error in a plan would have confused any agent trying to implement it.

The review produced a 10-section report covering architecture, error handling, security, data flow, performance, observability, deployment, and long-term trajectory. It mapped 10 error paths (network failure, API timeout, duplicate email, rate limiting, CORS errors), identified that none of them were handled in our plan, and flagged 8 specific corrections needed before implementation could start.

The completion summary table at the end is genuinely useful. Zero critical gaps, 6 diagrams produced, all decisions resolved. It reads like a real engineering review, not just a checklist.

Step 2: plan-eng-review

Once the concept is solid, this skill locks in the execution plan. It focuses on architecture, data flow, edge cases, and test coverage.

The first thing it does is a scope challenge: “What already solves each sub-problem? What minimum changes achieve the goal?” Good starting questions that prevent over-engineering.

This skill is designed for interactive sessions. It presents issues one by one, gives you opinionated recommendations with concrete tradeoffs, and asks for your input before moving on. Under 8 files and under 2 new classes or services, it skips the complexity questions and goes to the findings. At 8 or more files, or 2 or more new classes or services, it stops and asks which proposed features to cut or defer, then whether to keep the original arrangement or a smaller one with the same feature list.

It produces ASCII diagrams for flows, states, and pipelines, plus a coverage diagram that marks unit tests, E2E or integration tests, and evals.

Step 3: Implement

This is where your AI agent builds the feature. The plans from steps 1 and 2 give it a detailed spec to implement against, and that’s the whole point of the planning skills: by the time you get here, the agent has a clear, reviewed plan with architecture diagrams, edge cases mapped, and test coverage defined.

In the gstack demo, this is where Claude Code takes the approved plan and writes the actual code.

We implemented the email capture based on the CEO review’s findings: inline form in the footer, honeypot bot protection, AbortController with 10-second timeout, distinct UI states for success/error/duplicate, and button disabling during submission.

Step 4: review

The pre-landing review skill analyzes your branch’s diff against the detected base branch: the open PR’s base, otherwise the repo default, with main as the last fallback. It reads ~/.claude/skills/gstack/review/checklist.md and checks for:

  • SQL safety issues
  • LLM trust boundary violations
  • Race conditions and concurrency (read-check-write, find-or-create, status transitions)
  • Other structural problems that tests don’t catch

What we saw: The review found 5 issues in our 3-file diff. Most were low severity or informational, but one was a real bug: we were sending Content-Type: application/json to an API endpoint that expects form-encoded data. That would have silently failed in production. The skill caught it and recommended switching to URLSearchParams.

It also flagged that our honeypot used class="hidden" (easy for bots to detect) and suggested inline positioning instead. And it noted our form had no action attribute for progressive enhancement when JavaScript is unavailable.

We fixed all three issues before moving on. The review paid for itself with the Content-Type catch alone.

Step 5: ship

This is the most automated skill. Type /ship and it merges the detected base branch, runs tests, reviews the diff, commits, pushes, and creates the PR. When a VERSION file exists it bumps that version and updates CHANGELOG.md. In-branch test failures stop the run. Complex merge conflicts stop until you pick a resolution. Simple conflicts in VERSION, schema.rb, or changelog ordering it tries to resolve itself. A version file that is configured but missing, empty, or malformed stops the run.

What we saw: We ran it as a dry run. The skill checked our branch, counted 120 lines changed across 3 files, auto-selected a PATCH version bump, and generated a changelog entry. It would have created a single squashed commit with a conventional commit message plus a Co-Authored-By attribution.

One thing to know: if the repo has no VERSION file, /ship prints a notice and continues. It skips the changelog entry, opens the PR with no version bump, and leaves VERSION uncreated.

The PR description it generates includes a summary, pre-landing review results, eval results (if any prompt-related files changed), and a test plan. Clean and standardized.

Step 6: qa

Four testing modes:

  • Diff-aware (automatic on a feature branch when you don’t pass a URL): maps the git diff to affected pages and tests those. It picks the pages for the pass you run. If the diff doesn’t map to pages, QA uses Quick plus whatever interactions it can find.
  • Full (default when you pass a URL): visit every reachable page, about 5 to 15 minutes
  • Quick (--quick): 3 minutes on the homepage and the top 5 navigation targets
  • Regression (--regression <baseline>): run Full, then record which issues are fixed or new against that baseline

QA drives Aside when it is ready, and gstack’s own browser otherwise. It navigates the app, takes screenshots, and scores the result with the health score rubric.

The QA skill is particularly powerful for web apps. It checks mobile layout at 375px wide, empty and invalid forms, and empty, loading, error, and overflow states. Diff-aware mode looks at the git diff, figures out which pages are affected, and focuses testing there.

Step 7: retro

Run /retro at the end of the week for a retrospective. It analyzes commit history, work patterns, and code quality metrics. If you’re on a team, it breaks down per-person contributions with praise and growth areas.

The retro supports multiple time windows (/retro 24h, /retro 14d, /retro 30d) and a comparison mode (/retro compare) that benchmarks the current period against the previous one. It saves JSON snapshots to .context/retros/ for trend tracking over time.

For solo developers, it’s a useful reflection tool. For team leads, the per-person breakdown with specific praise and growth areas could replace or supplement manual retro facilitation.

The browse and setup-browser-cookies skills

These two support the QA workflow. Browse drives Aside first, on macOS 15+, through aside repl scripts. Each Aside script is a fresh session. Without Aside, browse falls back to gstack’s own headless Chromium: ~100ms per command, and state persists between calls. Setup-browser-cookies copies cookies from a Chromium-family browser into that fallback session. If Aside is already ready, the cookie skill stops and tells you to sign in there instead.

Browse is a compiled binary, and the cookie skill uses that same browser. The README also names find-browse, design, pdf, and gstack-global-discover as binaries compiled on your machine. /cso needs a native toolchain, and setup leaves that skill unavailable when the toolchain is absent. They’re worth the setup if you do any web development.

What works well

The planning skills are the standout. Plan-ceo-review caught an error in our plan that would have derailed implementation. That alone justified installing the stack. The structured review format (11 sections, with the design section skipped when the plan has no UI, plus a completion summary and an error registry) forces thoroughness that most developers skip.

The review skill catches real bugs. Our Content-Type mismatch would have shipped to production and silently failed. The review also suggested honeypot and progressive enhancement improvements that made the final implementation more robust.

The ship skill standardizes releases. If you use version files and changelogs, the automated version bumping, changelog generation, and PR creation removes friction from the release process.

Skills are designed for interactive sessions. These work best when you invoke them inside Claude Code and have a conversation. The planning skills especially benefit from back-and-forth: the agent presents an issue, you weigh in, it adjusts.

What to watch for

/ship continues when VERSION is absent. It prints a notice, skips the changelog entry, and opens the PR with no version bump. It leaves VERSION uncreated. A version file that is configured but missing, empty, or malformed stops the run until you fix it.

The browse path requires Bun. If your team doesn’t use Bun, ./setup adds a dependency you might not want. The non-browser skills still run. Aside on macOS 15+ can replace the bundled browser.

Interactive skills need interactive sessions. Running these through claude -p (non-interactive mode) works but you lose the back-and-forth dialogue that makes the planning skills most valuable. Use them in a live Claude Code session for the best experience.

The skills are opinionated. They encode Garry Tan’s engineering preferences: DRY code, aggressive testing, ASCII diagrams, explicit over clever. If those preferences don’t match yours, the recommendations might feel off. But opinionated is better than generic.

Get gstack

The official repo: github.com/garrytan/gstack

Each skill is also available on agent-config.com with individual descriptions and install notes:

Install the full stack:

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

Sources