00 · Read this first
A gstack skill is a Markdown playbook Claude Code loads on demand. Getting value out of one is less about the command name and more about what you hand it and where it sits in the sprint. Ten rules that separate “it kind of worked” from senior-engineer output.
Every gstack skill has voice-friendly triggers. /cso and “run a security check” do the same thing; “test the website” fires /qa; “do an engineering review” fires /plan-eng-review. You never have to memorise names — describe the job.
Most skills take one argument that aims them: a URL (/qa https://staging…), a directory (/freeze src/payments/), an issue number (/spec 142), or a directive (/autoplan add team invites). A vague target gets a vague result.
For interrogation skills (/office-hours, /plan-devex-review) give concrete examples of what hurts and let the skill reframe it. Its whole job is to push back on your framing — front-loading a finished spec defeats it.
Review/audit skills operate on what already exists: /review and /cso read your diff, plan reviews read the design doc. Have a diff staged or the plan written before you call them, or they have nothing to chew on.
The pipeline is a relay: /office-hours writes a design doc that /plan-ceo-review reads; /plan-eng-review writes a test plan that /qa picks up; /review finds bugs that /ship verifies are fixed. Run them in one session so nothing falls through the cracks.
Design and DX reviews use one-decision-at-a-time prompts (AskUserQuestion). They’re calibrating taste — “I don’t know, you pick” wastes the pass. Treat it like a real design crit.
--execute (build the spec in an isolated worktree), --fix / --comment, /codex adversarial, /retro global, --dry-run. The same skill often has a “tell me” mode and a “do it” mode.
Planning skills propose before they touch code. When you’re happy, say “Approve plan. Exit plan mode.” Nothing is written until you do — this is your safety gate on big changes.
For Conductor, OpenClaw or claude -p sessions, lead with “Load gstack. Run /x.” e.g. “Load gstack. Run /autoplan, implement the plan, then run /ship.” Plan-only: “…Save the plan, don’t implement.”
gstack notices your stage (planning, reviewing, debugging, testing) and proactively suggests the next skill. Useful while learning the flow; say “stop suggesting” and it remembers across sessions.
01 · The happy path
The full sprint for a greenfield feature or project. Each box hands its output to the next. This is the sequence to run end-to-end in a single session.
02 · The real-world path
Brownfield is different — the danger isn't building the wrong thing, it's breaking the thing that already ships. The plan stage shifts toward integration points and regression risk, and you lean on isolation (worktrees, freeze, guard) and proof-of-no-regression (benchmark, full-flow QA).
03 · When something is on fire
The Iron Law: no fixes without investigation. Guard the blast radius first, find root cause before touching code, prove the fix with a regression test.
04 · Decision aids
Two lookups you'll use constantly: pick the right review for what you're building, and tune Claude Code's horsepower to the task.
| You're building for… | Plan stage (before code) | Live audit (after it works) |
|---|---|---|
| End users — UI, web app, mobile | /plan-design-review | /design-review |
| Developers — API, CLI, SDK, docs | /plan-devex-review | /devex-review |
| Architecture — data flow, perf, tests | /plan-eng-review | /review |
| Security-sensitive — auth, payments, user data | fold into eng review | /cso + /codex adversarial |
| All of the above | /autoplan — runs CEO → design → eng → DX and auto-detects which actually apply | |
| Setting | Use it for |
|---|---|
| /model opus | Planning, architecture, /cso, gnarly bugs — the thinking-heavy work. |
| /model sonnet | Implementation and /review. The default workhorse. |
| /model haiku | Renaming, formatting, quick mechanical edits where speed wins. |
| /effort low → medium | Typos, small features. medium is the everyday default. |
| /effort high → xhigh | Complex bugs, multi-file refactors. xhigh is the default for Opus plans. |
| /effort max · ultracode | Security passes and the hardest algorithmic problems. Slow, deep, expensive. |
05 · The substrate
These ship with Claude Code itself — they control the session, not the task, and they're what gstack runs on top of. There are 60+ built-ins plus a handful of bundled skills, and the exact set varies by version, plan and platform. Master the four in bold first: /diff, /compact, /clear, /context — they shape every other interaction. (Search and the filter above include these too.)
06 · Operator moves
The difference between using gstack and running it like Garry Tan does (10–15 parallel sprints, part-time, while running YC).
One sprint is useful; ten is transformative. Conductor runs many Claude Code sessions at once, each in an isolated worktree — one planning, one reviewing a PR, one implementing, one running /qa. The sprint structure is what makes this safe: with a process, ten agents each know exactly when to stop instead of being ten sources of chaos. ~10–15 is the practical max.
/learn stores per-project patterns and pitfalls that fire automatically next session. GBrain (/setup-gbrain) is a persistent cross-session, cross-machine knowledge base — and it can sit on a Supabase project you already run. The agent literally gets smarter on your codebase over time.
gstack-config set checkpoint_mode continuous auto-commits work with a WIP: prefix and a structured context body (decisions, remaining work, dead ends). /context-restore rebuilds session state after a crash; /ship squashes the WIP commits so history stays clean. Local-only by default.
/review is Claude's eyes; /codex brings OpenAI's. Run both and you get a cross-model report of which findings overlap and which are unique. gstack-model-benchmark runs the same prompt through Claude / GPT / Gemini to show the cheapest model that's good enough for a given job.
Wrong assumptions → /office-hours forces them into the open. Overcomplexity & drive-by edits → /review catches both. Imperative-over-declarative → /ship turns tasks into verifiable, test-first goals. If you already use Karpathy-style CLAUDE.md rules, gstack is the layer that makes them stick across a whole sprint, not just one prompt.
Every /qa fix auto-writes a regression test; every /ship produces a coverage audit and bootstraps a test framework if you don't have one. 100% coverage is the stated goal — it's what turns “yolo coding” into something you can actually trust at speed.
/codex needs OpenAI's Codex CLI installed; /design-shotgun uses GPT Image. Install once with the paste-in command, then ./setup --no-prefix for short names (/qa) or --prefix for namespaced ones (/gstack-qa) if you run other skill packs. Note the /ios-* skills drive a physical iPhone — they won't apply to Android work, but /qa and /browse cover web flows on any platform.