gstack: AI Software Engineering Stack

AI coding agents can already write functions, modify repositories, run tests, and open pull requests. The harder problem is getting an agent to follow a repeatable engineering process before, during, and after the code is written.

gstack, a project from Garry Tan originally built around Claude Code, takes a different route: instead of replacing your coding agent with another platform, it wraps the agent you already use with specialized skills, browser tooling, reviews, safety controls, and release processes. The project describes the result as a virtual engineering team – twenty-three specialists and eight power tools, all slash commands, all Markdown, MIT licensed.

The comparison targets depend on which part of gstack you need: skill collections such as Superpowers, specification systems such as OpenSpec and GitHub Spec Kit, methodologies such as BMAD, orchestration platforms such as Ruflo, or your own maintained set of agent skills. Several of these combine with gstack rather than replace it, and the wider ecosystem they all belong to is mapped in the AI Developer Tools hub of this site.

What Is gstack?

gstack is an open-source collection of AI engineering workflows. In gstack’s framing, software development consists of several different kinds of reasoning, and asking one generic coding prompt to perform all of them is a poor abstraction – so the project exposes specialized skills instead:

• product exploration
• product and CEO review
• architecture review
• developer experience review
• design review
• implementation review
• browser-based QA
• investigation and debugging
• security analysis
• documentation
• benchmarking
• release preparation
• deployment
• retrospectives

The project presents these roles as a virtual engineering team: a CEO who rethinks the product, an eng manager who locks architecture, a designer who catches “AI slop”, a reviewer who finds production bugs, a QA lead who opens a real browser, a security officer who runs OWASP and STRIDE audits, and a release engineer who ships the PR. The toolchain around the skill definitions is TypeScript and Bun: a setup script, generated skill documentation, session hooks, state under ~/.gstack/, a bundled browser, and a set of standalone CLIs.

gstack is not a foundation model and not a replacement for Claude Code; it is a process layer running on top of an agent harness:

Two structural properties decide where gstack fits. First, the project describes it as a process rather than a collection of tools: the skills run in the order a sprint runs – think, plan, build, review, test, ship, reflect – and each skill hands its artifacts to the next, so /office-hours writes a design doc that /plan-ceo-review reads, and /plan-eng-review writes a test plan that /qa picks up. Second, gstack is not Claude Code-only: ./setup auto-detects the agents installed on the machine, and ./setup --host <name> targets Codex CLI, OpenCode, Cursor, Factory Droid, Kiro, Slate, OpenClaw, and Hermes, while a 2KB instruction-only digest in the repo covers rules-reading agents that need no install at all.

Why gstack Exists

A blank Claude Code session is extremely flexible, and that flexibility is also one of its weaknesses. Consider a feature request such as:

Add organization-level API tokens to the application.

A capable agent might immediately inspect the repository and start modifying authentication code, whereas a senior engineer would first ask who owns the tokens, whether users can belong to multiple organizations, how tokens are revoked, whether permissions are inherited, what happens to existing authentication, whether tokens should expire, how secrets are displayed, and which audit events are required. The agent may discover some of these questions eventually, but there is no guarantee it will discover them before implementation. gstack moves that discipline into reusable workflows: instead of idea -> coding agent -> code, the change passes product review, technical planning, architecture review, implementation, code review, browser QA, and release as named stages, each with its own command (the full sequence is in A Practical gstack Workflow below).

This does not make the AI correct; it changes the probability distribution of its mistakes. The agent is pushed to challenge assumptions earlier, inspect evidence, review its own work from several perspectives, and verify the application instead of stopping when the code compiles.

How gstack Turns Markdown Skills into Process

Most of gstack’s capabilities originate in Markdown skill definitions. An agent skill can describe:

• when it should run
• what context it should inspect
• what questions it should ask
• which tools it may use
• which commands it should execute
• which evidence it must gather
• which checks must pass
• how the result should be structured

Such a skill acts somewhere between documentation, a reusable prompt, a standard operating procedure, and executable workflow configuration. The underlying mechanics are covered in Claude Skills and SKILL.md for Developers; gstack adds infrastructure on top of that primitive: generated skill definitions, startup and completion hooks, state management under ~/.gstack/, browser automation, safety mechanisms, repository inspection, opt-in telemetry, cross-session memory managed by /learn, and optional persistent knowledge through the separate GBrain project, which /setup-gbrain can stand up as a local PGLite database, a Supabase project, or a remote MCP endpoint.

The Most Important gstack Skills

The exact collection changes quickly, but several workflows illustrate how the system is intended to be used.

office-hours

/office-hours belongs near the beginning of a project or feature. It runs six forcing questions about the problem before any code is written, and in the README’s worked example it reframes a request for a “daily briefing app” into a personal chief-of-staff AI, then writes the design doc that every downstream skill reads. For vague input like “we need better project search”, the output is a requirement, not code.

plan-ceo-review

/plan-ceo-review examines the product-level assumptions behind a plan. It works in four scope modes – Expansion, Selective Expansion, Hold Scope, Reduction – and can challenge scope, identify missing opportunities, reduce unnecessary work, or suggest framing the problem differently. It runs before the requirements are fixed, a stage most coding-agent tools do not have.

plan-eng-review

/plan-eng-review shifts the perspective toward engineering: architecture, data flow, diagrams, edge cases, a test matrix, failure modes, and security concerns. It stays separate from the product review because merging both into one large prompt makes the model mix product decisions with implementation decisions.

plan-design-review and design-review

gstack treats visual and interaction design as a separate discipline. /plan-design-review rates each design dimension from 0 to 10, describes what a 10 looks like, and edits the plan to close the gap, with “AI slop” detection as a named check. The later /design-review runs the same audit against the actual implementation and fixes what it finds with atomic commits and before/after screenshots. For web applications, both pair with gstack’s browser automation.

review

/review performs engineering review against repository changes from a staff-engineer perspective: it auto-fixes the obvious findings, flags the rest for approval, and keeps an advisory simplification lens for over-built code. Code written successfully is not necessarily code that should be merged.

investigate

/investigate enforces a systematic debugging rule the project calls the Iron Law: no fixes without investigation. It traces data flow, tests hypotheses, and stops after three failed fix attempts instead of continuing to thrash. It also auto-activates /freeze, which locks edits to the module under investigation.

qa and qa-only

/qa has the agent operate a browser, interact with the application, find bugs, fix them with atomic commits, re-verify, and generate a regression test for every fix. /qa-only runs the same methodology report-only. Many coding agents stop verification at “tests passed”; for a web application the browser is where integration errors, layout problems, incorrect flows, authentication failures, and JavaScript exceptions usually become visible.

ship, land-and-deploy, and canary

The release chain is three skills rather than one. /ship syncs main, runs tests, audits coverage, pushes, and opens the pull request, bootstrapping a test framework if the project has none. /land-and-deploy merges, waits for CI and the deployment, and verifies production health. /canary then runs a post-deploy monitoring loop that watches for console errors, performance regressions, and page failures.

autoplan, spec, learn, and retro

/autoplan runs the CEO, design, DX, and engineering review pipeline automatically – engineering always last, so the shipping gate reviews the final amended plan – and surfaces only taste decisions for approval. /spec turns vague intent into a precise, executable spec in five phases (why, scope, technical with mandatory code-reading, draft, file) with an outside-review quality gate before filing. /learn manages what gstack has learned across sessions – patterns, pitfalls, and preferences – with review, search, prune, and export. /retro produces a team-aware weekly retro; /retro global runs it across all your projects and AI tools.

Browser Automation in gstack

On supported macOS systems (macOS 15+), gstack drives the Aside browser first – your real browser, with your real logged-in sessions, in tabs the agent opens for itself and closes when done. When Aside is unavailable, gstack falls back to its own Chromium-based engine, which ./setup builds and which runs a persistent daemon rather than launching a fresh browser for every command:

Persistent browser state lets cookies, authentication sessions, and tabs survive between operations, which makes browser-based QA practical. /open-gstack-browser exposes the fallback engine headed, with a sidebar agent that routes fast actions (click, navigate, screenshot) to Sonnet and reading or analysis to Opus. When the agent hits a CAPTCHA, an auth wall, or an MFA prompt, $B handoff opens a visible browser at the same page with cookies and tabs intact; you solve it, and $B resume continues where the agent left off. The agent suggests a handoff automatically after three consecutive failures. /pair-agent shares the browser with other agents – OpenClaw, Hermes, Codex, Cursor, or anything that can curl – with scoped tokens, tab isolation, rate limiting, and per-tab activity attribution.

The persistent engine also increases the security surface, since an agent with access to authenticated sessions holds a meaningful privilege. gstack ships a layered prompt-injection defense for this: content filters (datamarking, hidden-element stripping, ARIA scrubbing, URL blocklist) on every page read, plus a local ML classifier in a sidecar subprocess that scans page-derived content before the agent sees it, with a verdict combiner that requires classifier agreement before blocking. Page content is treated as untrusted input – the agent takes syntax from a page, never instructions. Checks before and while using browser-driven QA:

• Decide in advance which authenticated environments the agent may operate in, and prefer an isolated profile for QA work when the fallback engine is in use.
• Know the emergency kill switch: GSTACK_SECURITY_OFF=1 disables the security layer – do not leave it set.
• The persistent daemon retains cookies and sessions between runs, so stop it when you are done and confirm nothing is left running, for example ps aux | grep -i chrom.
• Read the hooks and safety mechanisms in the cloned repository before enabling them – they are plain files, so review them the way you would review CI configuration.
• After updating the clone, re-run ./setup so generated components stay in sync with the skill definitions.

Safety Guardrails and Second Opinions

Three power tools act as session-level safety switches. /careful warns before destructive commands – rm -rf, DROP TABLE, force-push, git reset --hard – and activates by saying “be careful”; recursive deletes of the root or home directory and force-pushes to the default branch are hard-denied. /freeze restricts file edits to one directory so the agent cannot “fix” unrelated code while debugging, and /guard activates both at once.

Second-opinion reviews cross harnesses: on Claude Code, /codex sends the work to OpenAI Codex CLI for an independent review, challenge, or consultation; on the other harnesses, /claude-code does the reverse. Each report identifies the provider that actually completed the review.

A Practical gstack Workflow

You do not need every gstack skill for every change. A reasonable feature workflow:

1. /office-hours
2. /plan-ceo-review
3. Create the implementation plan
4. /plan-eng-review
5. Implement
6. /review
7. /qa
8. /ship

Which review skills to add depends on who the software is for:

For a trivial bug fix, going straight to investigate, implementation, review, and tests is often enough. A tool-neutral version of the same shape – spec, design, tasks, implement, validate – is in Spec-Driven Development Workflow From Requirements to Code. The project’s README describes running ten to fifteen of these sprints in parallel, each in its own isolated workspace; the sprint structure is what the project says keeps parallel agents from becoming sources of chaos.

Installing gstack

The current installation expects a working Claude Code setup, Git, Bun v1.0+, and, on Windows, Node.js – Bun has a known bug with Playwright’s pipe transport on Windows, so the browse server falls back to Node.js there. If you have not configured Claude Code yet, start with the Claude Code overview first. On macOS, the Aside browser (macOS 15+) is recommended for the browser skills; without it, the bundled Chromium daemon is used.

1. Verify your prerequisites: git --version and bun --version (the toolchain is Bun-based).

2. Clone gstack into the Claude skills directory:

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

3. Run the setup script from the cloned directory:

   cd ~/.claude/skills/gstack
   ./setup
   

   Setup installs and generates the components required by the supported skills and builds the bundled browser; a Chromium install failure is best-effort, setup records the reason, finishes registering every skill, and prints which skills are affected.

4. Add a ## gstack section to the project’s CLAUDE.md. The project’s install instructions include this step, and it is what makes Claude Code route the skills: use /browse from gstack for all web browsing, never use mcp__claude-in-chrome__* tools, and list the available skills.

5. Verify the install: check that the generated files are present in the cloned directory, start a Claude Code session, and run /office-hours on a scratch project to confirm the skill is recognized.

Team mode

For repositories, gstack offers a team-oriented setup where developers share one workflow instead of individually configured environments:

(cd ~/.claude/skills/gstack && ./setup --team) && \
  ~/.claude/skills/gstack/bin/gstack-team-init required && \
  git add .claude/ CLAUDE.md && \
  git commit -m "require gstack for AI-assisted work"

required blocks AI-assisted work in the repo without gstack; swap it for optional to nudge teammates instead of blocking them. No files are vendored into the repo: every Claude Code session starts with a fast auto-update check (throttled to once per hour, network-failure-safe, silent), which removes version drift across the team. Personal configuration improves one developer; repository-level configuration creates a shared engineering convention.

Other harnesses, upgrades, and uninstall

• Other agents: ./setup --host codex, --host opencode, --host cursor, --host factory, --host kiro, --host slate, --host openclaw, and --host hermes install the skills into each agent’s own skills directory. The 2KB instruction-only digest at agents-digest/gstack-AGENTS.md covers agents that only read rules files.
• Command naming: skills register with short names by default (/qa, /review); ./setup --prefix switches to namespaced names (/gstack-qa), which matters when you run other skill packs alongside gstack.
• Upgrades: re-run ./setup after a git pull (required on Windows, where installs are file copies), or use the /gstack-upgrade skill; setting auto_upgrade: true in ~/.gstack/config.yaml keeps the install current automatically.
• Telemetry is off by default and asks for opt-in on first run. If you opt in, it sends skill name, duration, success/fail, gstack version, and OS – never code, file paths, repo names, or prompts. gstack-config set telemetry off disables it at any time.
• Uninstall: ~/.claude/skills/gstack/bin/gstack-uninstall removes skills, symlinks, ~/.gstack/ state, project-local state, browse daemons, and hook registrations.

Verify the install and fix common failures

• ./setup fails – confirm Bun is on your PATH with bun --version; the generated components are built by the Bun toolchain.
• Skills not recognized by Claude Code – confirm the clone actually lives in ~/.claude/skills/gstack, that the project’s CLAUDE.md has a gstack section, and re-run ./setup.
• /browse reports NEED_ASIDE or ASIDE_NOT_RUNNING – the probe is telling you it will use the fallback browser. That is normal on Linux and Windows; on macOS it means Aside is not open or signed in.
• The fallback browser fails – cd ~/.claude/skills/gstack && bun install && bun run build.
• Stale install after an update – run /gstack-upgrade, or set auto_upgrade: true in ~/.gstack/config.yaml.

Trying gstack Without Adopting Everything

Use gstack on a real but non-critical feature rather than migrating your development process. The project’s quick start is the same trial, and it ends with “stop there”:

1. /office-hours – problem definition
2. /plan-ceo-review – product reasoning
3. /review – engineering verification, after implementation
4. /qa – runtime verification, for web projects

If those stages surface findings your normal Claude Code workflow misses, the rest of the system is worth exploring; if they mostly produce additional text without changing engineering decisions, adopting the entire stack probably will not help.

What gstack Does Well

Separated engineering roles. Instead of one giant “be a senior engineer” instruction, product strategy, architecture, UX, QA, security, and release engineering each get their own reasoning mode.

Verification, not just generation. Review, browser QA with regression-test generation, security audits, benchmarking, and the ship-deploy-canary chain are first-class workflows in gstack rather than optional afterthoughts.

Inspectable. Much of the behavioral layer is plain Markdown files developers can read and modify, unlike the internal workflows of a proprietary autonomous agent. The repo also ships audit tooling for the stack itself: gstack-context-bill reports what an installed skill tree costs in tokens, and gstack-egress writes a hash-chained receipt for every off-machine send, telemetry included.

Team infrastructure. Skills can encode engineering conventions – instead of typing

Remember to check API compatibility, run integration tests,
inspect the browser console, and update the changelog.

in every session, the requirements live in a reusable workflow, and team mode makes that workflow a repository requirement.

Where gstack Can Be Too Much

gstack is intentionally opinionated, and that limits its fit: a mature organization may already have architecture review procedures, release tooling, CI gates, QA automation, security scanning, ADR conventions, specification templates, and code review policies, and adding another complete methodology on top creates overlap instead of clarity.

There is also a context and token cost: each additional review stage adds repository inspection, model reasoning, and potentially more external model calls. The goal is the minimum reliable process needed to ship correct software, not a maximum number of AI reviews; gstack-context-bill can quantify what your installed skill set actually costs per session before you decide how much of it to keep.

gstack works best as a toolbox whose workflows you select and adapt, not as ceremony for every commit.

gstack Alternatives and Combinations

The closest alternatives, and the layer each occupies:

gstack + Superpowers: implementation discipline inside the roles

Both are skill frameworks, so they overlap the most. The division of labor when combining them: gstack supplies the surrounding roles – product, design, QA, release – while Superpowers supplies the discipline inside the implementation phase (TDD, planning before implementation, systematic debugging, subagent review). Install both skill sets, then trim the overlapping skills so the agent never sees two conflicting instructions for the same phase; if command names collide, install gstack with ./setup --prefix so its skills register as /gstack-* and coexist with the other pack. Install and workflow details are in the Superpowers quickstart.

gstack + OpenSpec: durable specs, live reviews

OpenSpec keeps human and agent aligned around explicit change specifications – artifacts for the proposed change, specifications, design decisions, and implementation tasks. The key property is persistence: a chat conversation disappears into context history, but a specification remains in the repository where humans and future agent sessions can review it. gstack adds the product review before the spec exists and the review and QA after it is implemented:

A concrete sequence: run /office-hours and /plan-ceo-review, capture the outcome as an OpenSpec change, implement against it, then run /review and /qa. Note that gstack also ships its own /spec skill, which archives specs under ~/.gstack; if OpenSpec owns the specification, keep gstack’s /spec out of the loop so the two do not diverge. The OpenSpec quickstart covers the explore-propose-apply-archive loop in detail.

gstack + GitHub Spec Kit: pick one planning backbone

Spec Kit’s core workflow is a sequence of explicit stages – constitution, specify, plan, tasks, implement, converge – and it has expanded into bug-fixing, idea-assessment, extensions, presets, and integrations. Since both Spec Kit and gstack center the planning stage, running both full flows duplicates work. If requirements traceability and formal stages matter, let Spec Kit own the specification backbone and use gstack for the layers Spec Kit does not enforce – product review, design review, browser QA, and shipping. A broader comparison of spec-driven setups, including Kiro and Claude Code, is in GitHub Spec Kit vs Kiro vs Claude Code SDD Workflows.

BMAD and Ruflo: different axes

BMAD is a broader AI-driven development methodology whose adaptive workflows cover product thinking, specifications, architecture, and implementation, scaling the ceremony to the size of the work. It and gstack both play the process-backbone role, so choose one as the backbone rather than running both in full; gstack’s individual skills can still be selected alongside a methodology.

Ruflo targets multi-agent orchestration: coordinated workers, shared memory, swarms. gstack applies multiple specialist perspectives to one engineering workflow; an orchestration platform applies multiple executing agents to one engineering objective. The boundary blurs – gstack can call external tools and additional models, and orchestrators can implement structured engineering roles – but the decision is independent: if the problem is that the agent skips engineering discipline, a skill framework is the direct fix; if it is running ten agents concurrently across many tasks and repositories, an orchestrator sits above a workflow like gstack rather than replacing it.

Custom skills: the most customizable layer

You can also skip the framework entirely and create a small collection of skills for the procedures your team already follows:

skills/
  architecture-review/
  api-review/
  database-migration-review/
  incident-analysis/
  release-check/
  security-review/

Each skill encodes organization-specific knowledge a generic framework cannot know. A database migration skill can require rollback analysis, table-lock analysis, index impact review, migration duration estimation, deployment ordering, and compatibility with the previous application version; an API review skill can require backwards compatibility, authentication checks, pagination consistency, idempotency analysis, rate-limit behavior, and OpenAPI changes. A practical path: start from the gstack skills you actually use, copy their structure into your own skills/ directory, and rewrite the checks around your conventions.

Four Layers: Skills, Specifications, Methodologies, Orchestrators

Four layers cover most of these tools, and they show how the combinations above fit together:

Skills answer “how should the agent behave?”

gstack, Superpowers, and custom agent skills.

Specification systems answer “what exactly are we building?”

OpenSpec and GitHub Spec Kit; the underlying spec-driven concepts and terminology are defined in What Is Spec-Driven Development?.

Methodologies answer “how should the project move from idea to software?”

BMAD, Superpowers, and parts of gstack.

Orchestrators answer “how should multiple agents execute work?”

Ruflo and other multi-agent runtimes.

The layers compose; a development environment can contain all four:

gstack already spans several of these boundaries.

Should You Use gstack?

The project’s README describes the audience as technical founders and CEOs who still want to ship, first-time Claude Code users who want structured roles instead of a blank prompt, and tech leads and staff engineers who want rigorous review, QA, and release automation on every PR. gstack is worth trying if you use coding agents extensively and the limiting factor is no longer code generation itself. Typical symptoms:

• the agent starts implementing before understanding the problem
• implementation plans miss architectural implications
• generated code passes tests but fails in the browser
• reviews are inconsistent between sessions
• release steps are repeatedly forgotten
• different developers prompt the agent in completely different ways
• useful engineering instructions remain buried in CLAUDE.md files
• you repeatedly type the same review prompts manually

If your automation already provides strong deterministic gates and the agent only handles small, well-specified tasks, gstack adds little.

gstack and the Direction of AI Software Development

The shift gstack sits in tracks in generations: code completion (2022-2023), coding agents (2024-2025), specifications and agent workflows (2025-2026), and programmable AI engineering organizations. The products will change, but the model remains one component; engineering quality increasingly depends on the surrounding system:

• persistent specifications
• reusable skills
• repository knowledge
• browser access
• tests
• deterministic tools
• review loops
• security controls
• memory
• human approval boundaries
• orchestration

Conclusion

gstack is the engineering process around a coding agent, packaged as inspectable, version-controlled skills, and its value is in forcing that process onto the agent rather than in any single skill.

Start from the trial sequence and keep only the skills that earn their place. Beyond it, the direction is composable layers – specification, skills, deterministic verification, orchestration – each doing what the others cannot.

References

• gstack repository – source, skill definitions, and setup
• gstack skill deep dives – philosophy, examples, and workflow for every skill
• Aside browser – the browser gstack drives first on macOS
• Superpowers repository – source, skills, and plugin manifests
• OpenSpec repository – source, docs, and the CLI package
• GitHub Spec Kit documentation – official Spec Kit workflow reference
• BMAD-METHOD repository – the adaptive AI-driven agile methodology
• Ruflo repository – the multi-agent orchestration platform