GStack in Practice: How AI Tooling Built This Blog From Scratch
What is GStack
GStack is a Claude Code skill system built by Garry Tan, CEO of Y Combinator. It provides over a dozen / commands covering the complete software development lifecycle:
| Stage | Command | What it does |
|---|---|---|
| Product Design | /office-hours | YC-style startup diagnostic or creative brainstorming |
| Spec Writing | /spec | Turns vague requirements into executable GitHub issues |
| Architecture Review | /plan-eng-review | Checks architecture, edge cases, test coverage |
| Full Pipeline Review | /autoplan | Runs CEO → Design → Eng → DX auto-review phases |
| Code Review | /review | Checks correctness, simplicity, and DRY violations |
| QA Testing | /qa | End-to-end verification of feature behavior |
| Shipping | /ship | Creates PRs and auto-links related issues |
These aren't simple prompt templates — each skill file contains hundreds of lines of instructions defining strict decision frameworks, output formats, and checklists.
Core Philosophy
GStack's design philosophy runs through every skill:
"Boil the Ocean" — do the complete thing, once. AI makes completeness nearly free. Why iterate 5 times when you can cover every edge case, error path, and test in one pass? This isn't waste — it's efficiency.
Dual-model review. /autoplan and /review invoke both Claude and Codex (OpenAI's CLI tool) as independent reviewers, then cross-reference their outputs. Agreement between both models is a high-confidence signal. Disagreement gets surfaced as a "taste decision" for human judgment.
Decision audit trail. Every auto-decision is logged: which principle applied, which alternative was rejected, why. Not a black box — traceable engineering decisions.
Founder mindset. GStack's voice is Garry Tan's own — direct, no fluff, zero tolerance for ambiguity. It isn't your AI assistant. It's your YC partner.
How I Built This Blog with GStack
1. /office-hours — Think before you build
I started with a simple goal: "I need a personal tech blog to attract consulting clients."
GStack didn't jump into code. It asked six YC-style diagnostic questions:
- Demand reality: Does anyone actually want this? I admitted I'm "building ahead of demand" — no client has asked for a portfolio yet.
- Status quo: Zero online brand presence. The blog scaffold is my only asset.
- Target user: I started with "anyone." GStack pushed back twice until I committed to "AI + automation tooling" as my content niche.
This process turned a vague "build a blog" into a clear proposition: Use AI automation content to attract potential clients through search.
Then GStack challenged three premises:
- A blog is the right channel for client acquisition ✓
- A full-featured blog builds trust better than a minimal one ✓
- Bilingual (Chinese + English) is necessary from day one ✓
Three implementation approaches emerged. I chose the complete version over the recommended incremental approach — a founder signal, as GStack noted.
2. Design doc survived 3 review rounds
GStack produced a design document, then launched an independent Claude sub-agent to review it. First round: 5/10 — missing data model, vague Pagefind integration, a factual error in the Giscus workflow.
Fixed and re-reviewed: 6/10 — a fundamental Pagefind + SSR incompatibility was discovered. Pagefind indexes static HTML; Next.js SSR outputs RSC payloads.
Third round: 7/10. Switched to output: 'export' (full static), corrected the Giscus discussion lifecycle. Passed.
This write → review → fix → re-review cycle would take two senior engineers half a day. With AI, it took 10 minutes.
3. Implementation: 5 phases, 15 tests
After plan approval, I implemented in 5 phases:
- Phase 1: Replaced hardcoded placeholder data with real MDX rendering + syntax highlighting
- Phase 2: Static export, SEO (OG/hreflang), RSS, Sitemap generation
- Phase 3: Giscus comments, Pagefind search with debounced search UI
- Phase 4: Dark mode (next-themes), 404 page, mobile hamburger menu
- Phase 5: 15 component tests (vitest + testing-library)
bun run build passed on the first try. 16 static pages, 14 indexed by Pagefind.
What I Learned
AI-powered review is undervalued. Most people use AI to write code. Few use it to review design documents. /office-hours 3-round design review caught 2 factual errors and 1 architecture conflict (Pagefind + SSR) — issues that manual review would almost certainly miss.
GStack's complete loop compounds. Running /office-hours or /spec alone has value. But the full plan → design → review → ship loop is where GStack shines. Each phase's output (design docs, audit trails, review reports) is automatically discovered and used by subsequent phases.
"Boil the Ocean" is real efficiency. Writing all tests, handling all edge cases, and setting up complete CI/CD in one pass feels like "doing too much." But because AI's marginal cost is near zero, completeness is actually cheaper than incremental iteration.
Closing
This blog is the best proof of GStack's capabilities. The site you're reading right now — from product design to code implementation — was built entirely through GStack-driven AI workflows.
If you're using Claude Code for development, give GStack a try.
Coming next: Automating content publishing workflows with n8n + Claude API.