GStack, explained for founders, not just engineers

What it does: Six forcing questions that reframe your product before you write code. Pushes back on your framing, challenges premises, and generates implementation alternatives. Produces a design doc every downstream skill reads.

When to use it: The very first thing you run on a new idea, before any planning or code.

Founder read: The outside perspective a solo founder does not get in a garage: someone asking "are you sure that's the real problem?" before you spend a week on the wrong one.

What it does: Rethinks the problem instead of implementing it literally. Finds the 10-star product hiding inside the request, across four modes: Expansion, Selective Expansion, Hold Scope, Reduction.

When to use it: At the start of any new feature or roadmap item, before a spec gets written.

Founder read: This is the question you'd ask in a founder review meeting, asked automatically before your team spends a week building the wrong thing.

What it does: Locks in architecture, data flow, diagrams, edge cases, and tests. Forces hidden assumptions into the open before implementation starts.

When to use it: Right after the CEO-review pass, before implementation begins.

Founder read: This is the artifact a strong technical co-founder would produce. Attach it to any ticket before work starts, even if you don't have one.

What it does: Rates each design dimension 0 to 10, explains what a 10 looks like, then edits the plan to close the gap. Includes AI Slop detection and asks one question per design choice instead of guessing.

When to use it: Before code gets written for anything end users will actually look at.

Founder read: Gives a non-designer founder a second pair of eyes before the product looks like every other AI-built app.

What it does: Interactive review of a developer-facing product: explores developer personas, benchmarks against competitors' time-to-hello-world, and traces friction step by step across three modes (expansion, polish, triage).

When to use it: Before shipping an API, CLI, or SDK, not a consumer-facing app.

Founder read: Relevant the moment your product is something other developers integrate with, not just something end users click through.

What it does: Runs the CEO, design, and engineering reviews automatically in sequence, with decision principles already encoded, and only surfaces genuine taste decisions for your approval.

When to use it: When you want the full planning pipeline without manually chaining three separate review commands.

Founder read: The fastest way to get a fully-reviewed plan when you don't have three separate specialists to loop in.

What it does: Turns a vague idea into a precise, executable spec across five phases: why, scope, technical detail with mandatory code reading, a draft, and filing. Includes a quality gate that blocks specs scoring below 7 out of 10.

When to use it: Before implementation on anything non-trivial, when "build the thing I said" isn't precise enough to hand off.

Founder read: The written brief a founder would normally have to write themselves, or pay someone to extract from their head.

What it does: Builds a complete design system from scratch: researches the landscape, proposes creative risks, and generates realistic product mockups.

When to use it: When there's no design system yet and you need a real starting point, not a template.

Founder read: The design co-founder a solo technical founder does not have.

What it does: Runs the same audit as /plan-design-review, then fixes what it finds directly, with atomic commits and before/after screenshots.

When to use it: After something is built, as a live design audit rather than a planning-stage review.

Founder read: Catches the drift between what was planned and what actually shipped, without you having to notice it yourself.

What it does: Generates four to six AI mockup variants, opens a side-by-side comparison board in your browser, collects your feedback, and iterates. A persistent taste profile learns what you pick over time.

When to use it: Early exploration, when you want options rather than one AI guess.

Founder read: Turns "describe your vision and hope" into "look at six options and point."

What it does: Turns a chosen mockup into production HTML that actually works: dynamic layouts, framework detection (React, Svelte, Vue), and routing tuned per design type. Around 30KB, no dependencies.

When to use it: Once a design direction from /design-shotgun is picked and needs to become real, shippable markup.

Founder read: The gap between "a mockup I like" and "code I can actually ship" closes in one command.

What it does: Finds the bugs that pass CI and blow up in production: race conditions, N+1 queries, broken retry logic, trust-boundary slips. Auto-fixes the obvious ones and flags completeness gaps.

When to use it: After code is written, before it merges.

Founder read: Quality stops depending on whichever engineer happened to be free to review that day.

What it does: Systematic root-cause debugging with one rule: no fixes without investigation first. Traces data flow, tests hypotheses, and stops after three failed fix attempts rather than guessing forever.

When to use it: When something is actually broken and the cause isn't obvious yet.

Founder read: Stops the expensive spiral of trying random fixes on a bug nobody has actually diagnosed.

What it does: Live audit of your developer experience: actually navigates your docs, tries the getting-started flow, times how long it takes to reach "hello world," and screenshots errors along the way.

When to use it: After shipping developer-facing surface area, to check the plan matched reality.

Founder read: Tells you, with a timer, whether a new developer can actually get started with what you built.

What it does: Runs an OWASP Top 10 and STRIDE threat model against your app, with 17 false-positive exclusions and an 8-out-of-10 confidence gate. Every finding includes a concrete exploit scenario.

When to use it: Before shipping anything that touches real user data or payments.

Founder read: The security review a two-person startup cannot afford to hire for, run before the mistake ships instead of after a breach.

What it does: An independent code review from OpenAI's Codex CLI, with three modes: a pass/fail review gate, an adversarial challenge, and open consultation.

When to use it: When you want a second, differently-trained model checking the same code, not just Claude checking itself.

Founder read: A cheap way to avoid a single model's blind spots on something that actually matters.

What it does: Tests your app, finds bugs, fixes them with atomic commits, re-verifies, and auto-generates a regression test for every fix.

When to use it: Before every release, or after any change that touches user-facing pages.

Founder read: The closest thing to a QA hire you can turn on with a slash command.

What it does: Same methodology as /qa, but produces a clean bug report instead of making autonomous changes to your codebase.

When to use it: Pre-launch checks, or any time you want a trustworthy bug list handed to your team without AI editing production code.

Founder read: Useful the moment you want a paper trail, not an autonomous fixer, touching a live codebase.

What it does: Shares your browser session with another AI agent (OpenClaw, Hermes, Codex, Cursor, or anything that can curl). Each agent gets its own isolated tab, with scoped tokens and rate limiting.

When to use it: When you're running more than one AI coding tool and want them looking at the same live app together.

Founder read: Useful once you're experimenting with more than one AI tool and don't want to explain the same bug twice.

What it does: A post-deploy monitoring loop that watches for console errors, performance regressions, and page failures after a release goes out.

When to use it: Right after a deploy, while you'd otherwise be refreshing the site nervously.

Founder read: Does the anxious post-launch refreshing for you, and actually tells you if something broke.

What it does: Baselines page load times, Core Web Vitals, and resource sizes, then compares before and after on every PR.

When to use it: Any time a change might affect real-world load speed, or as a standing check per PR.

Founder read: Catches the slow creep of a slower product that nobody notices until users start leaving.

What it does: A persistent, fast browser session so the agent can log in, click through your live app, take screenshots, and catch console errors, instead of only ever reading code.

When to use it: Any time you want a real, visual check on what's actually rendering.

Founder read: Your AI can demo your own product back to you and tell you what's broken, in under a minute.

What it does: Imports a session from your real browser (Chrome, Arc, Brave, Edge) into the headless testing session, so pages behind a login can be tested without retyping credentials.

When to use it: Once, when you first set up testing for anything that sits behind authentication.

Founder read: Most of a real product lives behind a login. This is what makes the QA skills actually useful on it.

What it does: Launches a full browser with a sidebar, anti-bot stealth, automatic model routing (a faster model for actions, a stronger one for analysis), and one-click cookie import.

When to use it: When you want a visible, interactive browser session rather than a fully headless one.

Founder read: Lets you watch the AI work on your actual product instead of trusting a text log.

What it does: Syncs main, runs tests, audits coverage, pushes, and opens the pull request. Bootstraps a test framework automatically if you don't have one yet.

When to use it: Once a branch is actually ready to go out.

Founder read: Removes the "it works on my machine, someone still has to ship it" drag that kills momentum right after the hard part is finished.

What it does: Merges the approved PR, waits for CI and the deploy to finish, and verifies production health. One command from "approved" to "verified in production."

When to use it: Right after a PR from /ship gets approved.

Founder read: Closes the gap between "someone approved my PR" and "I actually know it's live and healthy."

What it does: A one-time setup step for /land-and-deploy: detects your hosting platform, production URL, and deploy commands automatically.

When to use it: Once, the first time you want /land-and-deploy to work on a given project.

Founder read: The kind of setup a solo founder usually puts off for weeks, done once and forgotten.

What it does: Updates every project doc to match what just shipped: README, ARCHITECTURE, CONTRIBUTING, CLAUDE.md, TODOS. Builds a coverage map so documentation gaps are visible directly in the PR.

When to use it: As part of, or right after, shipping a feature.

Founder read: Docs stop going stale the week after launch, which is usually exactly when they do.

What it does: Writes missing docs from scratch (reference, how-to, tutorial, explanation), researching the actual codebase first so the docs match the code.

When to use it: When a project has no real documentation yet, or /document-release finds a coverage gap.

Founder read: The technical writer a small team cannot justify hiring yet, applied to the docs that would otherwise never get written.

What it does: Turns markdown into a publication-quality PDF. Mermaid and Excalidraw diagrams render as real vector graphics, fully offline. Can also output a self-contained HTML file or a Word document.

When to use it: Any time a plan, spec, or doc needs to go somewhere other people will actually read it, not just Git.

Founder read: The kind of tool behind a clean cheat sheet or one-pager, without opening a separate design app.

What it does: Turns an English description into an editable diagram: Mermaid source, an Excalidraw file you can open and hand-edit, and a rendered image, in one pass, with no network calls.

When to use it: Any time you need to explain a system visually instead of in a paragraph.

Founder read: Useful for the exact diagrams a board deck or investor update needs, without opening a separate design tool.

What it does: A team-aware weekly retrospective with per-person breakdowns, shipping streaks, and test health trends. /retro global runs the same analysis across every project and AI coding tool you use.

When to use it: Weekly, or at the end of a sprint.

Founder read: The closest thing to an engineering 1:1 a first-time CTO gets when they are the only engineer, or the founder managing their first hire.

What it does: Manages what GStack has learned across sessions: review, search, prune, and export project-specific patterns, pitfalls, and preferences.

When to use it: Ongoing, as a way to see and curate what the AI has picked up about how you work.

Founder read: Gives you visibility into what the AI actually remembers about your product, instead of trusting it silently.

What it does: Gets a persistent memory system (GBrain) running in under five minutes, with a local, existing-Supabase, or auto-provisioned Supabase backend, plus per-repo trust controls.

When to use it: Once, if you want GStack's memory to persist and sync across machines rather than stay local to one session.

Founder read: Optional infrastructure. Skip it unless you're already comfortable with what it sets up.

What it does: Re-indexes the current repo's code into GBrain so search and memory stay current with the codebase.

When to use it: Periodically, if GBrain is already set up, to keep it from going stale.

Founder read: Maintenance for the memory system, only relevant if you opted into /setup-gbrain.

What it does: Warns before destructive commands like rm -rf, DROP TABLE, or a force-push. Say "be careful" to activate; any warning can be overridden.

When to use it: Any session where a mistake would be expensive, especially near production data.

Founder read: A seatbelt for the moments an AI agent is about to do something you cannot undo.

What it does: Restricts file edits to a single directory, to prevent accidental changes outside the intended scope while debugging.

When to use it: When you want the AI focused on one part of the codebase and nowhere else.

Founder read: Stops a debugging session from quietly touching code you never asked it to.

What it does: Combines /careful and /freeze into a single command for maximum safety during production work.

When to use it: Any time you're working directly against production.

Founder read: The one command to reach for before touching anything live.

What it does: Removes the boundary set by /freeze.

When to use it: Once the scoped, careful work is done and normal editing should resume.

Founder read: Turns the seatbelt back off once you're out of the dangerous part.

What it does: Upgrades GStack to the latest version, detecting whether you have a global or per-project install and syncing both, with a summary of what changed.

When to use it: Periodically to stay current, though GStack also runs a silent, throttled auto-update check by default.

Founder read: One command to make sure you're not running a stale copy of the tool this whole page is about.

What it does: Drives a real, connected iPhone over USB, reads your Swift source, and generates typed accessors to run an automated QA loop against actual hardware, not a simulator.

When to use it: When your product includes a native iOS app and you want QA against a real device.

Founder read: Only relevant if you're shipping native iOS. Skip entirely if your product is web-only.

What it does: A bug-fix loop, a designer's-eye Human Interface Guidelines audit, debug-bridge cleanup, and accessor resync, rounding out the native iOS testing pipeline alongside /ios-qa.

When to use it: Alongside /ios-qa, for teams actively shipping and maintaining a native iOS app.

Founder read: Supporting commands for the same iOS-only audience as /ios-qa.