Twenty-three specialist roles impose one founder's process
gstack packages a complete product-development method as agent skills. Its README describes 23 specialists and 8 power tools covering product discovery, architecture, visual design, code review, browser QA, security, documentation, release work, deployment, and retrospectives. Commands pass artifacts to later stages, so an office-hours document can feed plan reviews and tests can feed shipping evidence. That continuity is the main appeal: the agent follows a named process instead of inventing a new one in every session.
The opinions are strong. Product review is supposed to challenge scope, engineering review asks for diagrams and failure modes, and /ship can prepare a pull request after checks. This can rescue a solo founder from a vague prompt followed by an unchecked diff. An established team may find that gstack duplicates existing design review, threat modeling, CI, release, and incident practices. Adoption works best when the team wants this process, rather than when one developer silently installs it.
The 957 MB install is larger than a prompt collection
Our fresh checkout contained 1,360 files and about 222,808 lines of source before installation. The repository itself used 19.8 MB, while installing 234 packages increased disk use to 957 MB. That difference makes sense once the browser, TypeScript tooling, command binaries, tests, and integrations are considered. gstack is marketed through Markdown skills, but the working product includes far more than Markdown.
The basic requirements are Git, Bun 1.0 or newer, and Claude Code. Node.js is also required on Windows. Setup now detects 10 coding-agent hosts, including Codex, Cursor, OpenCode, Factory Droid, Hermes, and Kiro. Claude remains the reference experience, and some commands call external model tools or services when configured. A mixed-agent team should test the generated profile for each model instead of assuming identical behavior from shared skill text.
What happened when we ran it
Our sandbox installed commit ad84005 in 33 seconds, adding 234 packages and consuming 957 MB. The build passed in 7 seconds. The project had 14 CI workflow files and a tests directory, but no Dockerfile. Those results show that the Bun-based source setup can complete in a clean Node 22 environment without secrets.
Tests ran for 264 seconds and exited with code 1. The tail reported shard 1 with 41 failing tests in 9 files, shard 6 with 35 failures in 8 files, and shard 7 with 1 failure in 1 file. It also reported 0 crashed workers. One repeated failing case concerned gstack-session-update pull wedge and expected a genuine pull failure to log its reason, rather than only an exit code.
The log printed separate run totals of 1,225 tests across 80 files, 1,291 across 78 files, and 881 across 12 files for those shards. We have not combined those figures because the output does not establish whether every printed group is unique. The safe finding is that the suite was materially red, with multiple failing shards. The 7-second build is encouraging, while it cannot substitute for tests of commands that edit repositories, handle secrets, or release code.
Team mode changes repositories and checks for updates
Personal installation places gstack under the user's agent-skill directory. Team mode goes further: its documented command initializes project files, stages .claude and CLAUDE.md, and creates a commit. The required setting can block teammates who lack gstack, while optional only prompts them. Every Claude Code session then performs a silent update check, limited to once per hour and designed to tolerate network failure.
That arrangement prevents vendored copies from drifting, but it also makes upstream changes part of session startup. Regulated teams may prefer a pinned reviewed revision, even if that gives up automatic updates. The uninstall section matters too: manual deletion can leave hook entries in ~/.claude/settings.json, where they keep erroring. Using the supplied uninstall script is safer than removing the skill directory alone.
Browser and release commands deserve explicit authority boundaries
The browser tools can launch a real Chromium session, click through applications, take screenshots, persist authentication, and import cookies from Chrome-family browsers. /qa may fix discovered bugs and add regression tests. /ship can commit and push, while /land-and-deploy can merge and verify production. These are useful powers, and they cross boundaries that many teams keep behind separate approvals.
The README documents defenses such as prompt-injection filtering, a local classifier, scoped pair-agent tokens, a destructive-command guard, edit freezing, trust for verification hooks, and an egress receipt ledger. Telemetry is off by default and sends only limited usage data after opt-in. These controls show attention to agent risk. They do not replace repository permissions, branch protections, secret isolation, or a human approval before production changes.
Open issue 2679 reports unguarded mktemp failures that could bypass one redaction path and damage an upgrade installation under a forced failure. The report includes a proposed fix, but it was still open when fetched. That is precisely the kind of edge case that matters in a tool allowed to touch credentials and working trees.
August activity is intense and the issue queue is crowded
GitHub recorded 129,894 stars, 802 combined issues and pull requests, and a last push on August 26, 2026. There was no latest GitHub release object, so the repository changelog and versioned source are better release references. Open issue 2685 describes a test that fails when gbrain autopilot is running, despite that background mode being documented. The failure differs from our session-update failures, but it confirms that environment-sensitive tests are under active discussion.
gstack offers more coherent process than a folder of generic prompts. Its value rises when one person owns product decisions and wants the agent to carry context through an entire sprint. Our 264-second red test run is enough reason to avoid imposing it across a company today. Try the planning and review commands first, inspect the generated changes, and grant browser or release authority only after those paths behave predictably on your repositories.