gstack: AI Software Engineering Stack

Garry Tan released gstack, an open-source process layer built around Claude Code that wraps existing coding agents with 23 specialized skills and 8 power tools delivered as slash commands and Markdown under an MIT license. The project structures development as ordered sprint stages — think, plan, build, review, test, ship, reflect — with each skill passing artifacts to the next, and its TypeScript/Bun setup script auto-detects installed agents, supporting Codex CLI, OpenCode, Cursor, Factory Droid, Kiro, Slate, OpenClaw, and Hermes in addition to Claude Code.

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 https://www.glukhov.org/ai-devtools/ of this site. 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: 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: php flowchart TD A LLM -- B Claude Code or another supported harness B -- C gstack skills and workflow rules subgraph G gstack process stages D1 Planning D2 Architecture review D3 Design review D4 Code review D5 Browser QA D6 Security D7 Release and deployment D8 Learning and memory end C -- G G -- E Git repository, browser, and development tools 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. 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. Most of gstack's capabilities originate in Markdown skill definitions. An agent skill can describe: 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 https://www.glukhov.org/ai-devtools/claude-code/claude-skills-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 exact collection changes quickly, but several workflows illustrate how the system is intended to be used. /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 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 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. 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 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 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 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. 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 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. On supported macOS systems macOS 15+ , gstack drives the Aside https://aside.com 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: php flowchart LR A Coding Agent -- B gstack Browser CLI B -- C Local Browser Service C -- D Aside or bundled Chromium D -- E Application 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: GSTACK SECURITY OFF=1 disables the security layer -- do not leave it set. ps aux | grep -i chrom . ./setup so generated components stay in sync with the skill definitions. 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. You do not need every gstack skill for every change. A reasonable feature workflow: php flowchart TD A Feature idea -- B office-hours B -- C plan-ceo-review C -- D Create implementation plan D -- E plan-eng-review E -- F Implement F -- G review G -- H qa H -- I ship Which review skills to add depends on who the software is for: | Building for | Plan stage before code | Live audit after shipping | |---|---|---| | 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 | /plan-eng-review | /review | | All of the above | /autoplan | -- | 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 https://www.glukhov.org/app-architecture/documentation/spec-driven-development-workflow/ . 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. 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 https://www.glukhov.org/ai-devtools/claude-code/ first. On macOS, the Aside browser macOS 15+ is recommended for the browser skills; without it, the bundled Chromium daemon is used. git --version and bun --version the toolchain is Bun-based . git clone --single-branch --depth 1 \ https://github.com/garrytan/gstack.git \ ~/.claude/skills/gstack 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. 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. /office-hours on a scratch project to confirm the skill is recognized. 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. ./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. /qa , /review ; ./setup --prefix switches to namespaced names /gstack-qa , which matters when you run other skill packs alongside gstack. 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. gstack-config set telemetry off disables it at any time. ~/.claude/skills/gstack/bin/gstack-uninstall removes skills, symlinks, ~/.gstack/ state, project-local state, browse daemons, and hook registrations. ~/.claude/skills/gstack , that the project's NEED ASIDE or ASIDE NOT RUNNING cd ~/.claude/skills/gstack && bun install && bun run build . 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": /plan-ceo-review -- product reasoning 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. 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. 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. The closest alternatives, and the layer each occupies: | System | Primary focus | Workflow style | Agent portability | Best fit | |---|---|---|---|---| | gstack | Full engineering workflow | Role-oriented skills and tools | 10 agents via ./setup --host | End-to-end AI-assisted engineering | | Superpowers | Engineering methodology | Automatic composable skills | High | Disciplined coding and TDD | | OpenSpec | Change specifications | Lightweight spec artifacts | High | Brownfield feature development | | GitHub Spec Kit | Spec-driven development | Structured multi-stage workflow | High | Formal requirements-to-code process | | BMAD Method | AI-driven agile development | Adaptive roles and workflows | High | Larger end-to-end projects | | Ruflo | Multi-agent orchestration | Agents, swarms, memory | Platform-oriented | Parallel autonomous agent systems | | Custom skills | Your own process | Fully customizable | Potentially very high | Mature teams with established practices | 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 https://www.glukhov.org/ai-devtools/superpowers/ . 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: php flowchart LR A Feature request -- B gstack product review B -- C OpenSpec change C -- D Implementation D -- E gstack review E -- F gstack QA 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 https://www.glukhov.org/ai-devtools/openspec/ covers the explore-propose-apply-archive loop in detail. 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 https://www.glukhov.org/ai-devtools/ai-coding-assistants/spec-kit-vs-kiro-vs-claude-code/ . 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. 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 cover most of these tools, and they show how the combinations above fit together: gstack, Superpowers, and custom agent skills. OpenSpec and GitHub Spec Kit; the underlying spec-driven concepts and terminology are defined in What Is Spec-Driven Development? https://www.glukhov.org/app-architecture/documentation/what-is-spec-driven-development/ . BMAD, Superpowers, and parts of gstack. Ruflo and other multi-agent runtimes. The layers compose; a development environment can contain all four: php flowchart TD A Product requirement -- B Specification system B -- C Engineering workflow C -- D Agent orchestrator D -- E Implementation agent D -- F Test agent D -- G Review agent D -- H QA agent E -- I Repository F -- I G -- I H -- I gstack already spans several of these boundaries. 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: If your automation already provides strong deterministic gates and the agent only handles small, well-specified tasks, gstack adds little. 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: 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.