gstack for Claude Code: What Its 23-Agent Workflow Actually Does

A 14-file pull request can pass unit tests and still fail for three entirely different reasons: the product behavior is underspecified, the interface is awkward, and the release notes omit a migration step. Running Claude Code once with “review this PR” compresses those concerns into one overloaded conversation.

gstack takes a more opinionated approach. Its 23 role-based tools divide software delivery into planning, design, implementation, review, browser QA, release work, and documentation. Instead of asking one general-purpose coding assistant to improvise a process, you invoke a sequence of focused Claude Code workflows such as /plan-ceo-review, /plan-eng-review, /review, /qa, and /ship.

That distinction matters. gstack is not merely a directory of useful prompts, and its “23 agents” are not 23 autonomous workers continuously coordinating in the background. They are role-specific Claude Code skills, invoked at particular points in an engineering workflow. The value comes from the operating model they impose; so does most of the overhead.

gstack Claude Code Is an Operating System, Not a Prompt Pack

The useful mental model for gstack Claude Code is an engineering operating system layered on top of Claude Code. Each tool gives Claude a role, a procedure, and expected outputs. Together, those tools encode opinions about how software should move from an idea to production.

A generic prompt might be:

Review my implementation plan.

A role-based workflow asks a narrower question:

/plan-eng-review

That skill can direct Claude to examine architecture, dependencies, failure modes, testability, rollout risk, and implementation sequencing. A product-oriented planning skill can inspect the same plan for user value and scope. A design-oriented skill can challenge interaction details rather than backend boundaries.

The difference is repeatability. Team members do not each have to remember a 40-line review prompt or invent their own checklist. The skill carries the procedure.

The trade-off is equally important: gstack brings someone else’s procedure into your repository. It assumes that multiple review passes, explicit QA, and structured release work are worth the context and time they consume. That is often appropriate for production changes, but excessive for a typo or a two-line internal script.

What the 23 Role-Based Tools Actually Cover

The repository’s exact roster can evolve, so I treat the checked-out SKILL.md files as authoritative rather than relying on screenshots or launch descriptions. The important architecture is the division of responsibilities.

This is why calling gstack a “collection of prompts” undersells it. Planning outputs feed implementation; implementation produces a diff; review and QA interrogate that diff; shipping and documentation package the result.

It is also why “23-agent workflow” can be misleading. What actually happens when you invoke a skill is that Claude Code loads instructions and performs the associated workflow using the tools available in the current session. Unless a skill explicitly delegates work, there are not 23 persistent processes sharing a global state.

Planning is intentionally redundant

The product, engineering, and design reviews overlap. That is deliberate.

Consider a proposed “export all customer activity” feature:

• Product review asks whether users need a complete export or a filtered report.
• Engineering review asks whether the export can fit in memory and how retries work.
• Design review asks where export status, failure, and download controls appear.
• QA asks what happens with zero records, expired links, and interrupted jobs.

In practice, this separation catches assumptions that disappear inside a generic implementation plan. The cost is repeated context loading. If the plan is already 8,000 tokens, three review passes can become expensive and produce duplicate observations.

Review and QA are different jobs

/review is primarily evidence from code: diffs, types, tests, call sites, and repository conventions. /qa and /browse can gather runtime evidence from the application itself.

That separation is one of gstack’s stronger ideas. A diff can look correct while the rendered result is unusable. Conversely, a happy-path browser check can pass while the implementation introduces a race condition or authorization bypass.

A practical sequence looks like this:

/plan-eng-review
/careful
# Implement the approved plan in Claude Code
/review
/qa
/document-release
/ship

Do not treat that as a mandatory pipeline. For a database migration, engineering review and rollback planning may matter much more than visual design. For a CSS regression, /browse, design review, and QA may be the core workflow.

Installing gstack Without Blindly Trusting It

A typical user-level installation places the repository under Claude Code’s skills directory and runs its setup script:

git clone https://github.com/garrytan/gstack.git \
  ~/.claude/skills/gstack

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

Restart Claude Code after setup if the new commands are not discovered immediately. Then inspect the installed skills rather than assuming the published count still matches your checkout:

find ~/.claude/skills/gstack \
  -name SKILL.md \
  -print |
  sort

find ~/.claude/skills/gstack \
  -name SKILL.md |
  wc -l

A common gotcha is running installation scripts because the repository is popular without reading what they change. gstack includes executable workflow machinery, not inert Markdown. Before running setup, inspect it:

cd ~/.claude/skills/gstack
git status --short
git log -1 --oneline
sed -n '1,240p' setup

For a team rollout, pin a reviewed commit instead of silently tracking the repository’s latest state:

git clone https://github.com/garrytan/gstack.git vendor/gstack
cd vendor/gstack
git checkout <reviewed-commit-sha>
./setup

The exact installation procedure and dependencies can change as the project develops. The repository’s current README and setup script should therefore win over copied commands in an older article, including this one.

Put Claude Code Permissions Around the Workflow

Some gstack tools need broad access to inspect files, run tests, operate a browser, or interact with Git. That does not mean every tool should receive unrestricted shell and release permissions.

A project-level .claude/settings.json can establish a conservative baseline:

{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(npm test:*)",
      "Bash(npm run lint:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(git push:*)",
      "Bash(git push --force:*)"
    ]
  }
}

Treat this as an example policy, not a universal drop-in file. Adapt commands to your package manager, test runner, and Claude Code version.

The deliberate denial of git push is particularly useful during evaluation. /ship can still inspect release readiness, but the human retains the final network side effect. After the team understands the workflow, you can decide whether a tightly scoped push permission is justified.

Also test browser-oriented skills against staging or seeded local data. Browser automation with a production session can mutate real records if the workflow clicks a destructive control.

Adopt a Subset Before Adopting the System

I would not introduce all 23 tools to a team on day one. Start with the points where your existing process loses the most information.

A sensible evaluation matrix is:

Run the subset on several real changes and record:

• Which findings caused code or scope changes?
• Which findings were duplicates?
• How much context had to be repeated?
• Did generated artifacts stay synchronized with the implementation?
• Which commands required permissions the team would not grant in CI?
• Did developers understand when to invoke each role?

Context overhead is not theoretical. Each role needs repository state, requirements, and previous decisions. Separate sessions can lose rationale; one long session can accumulate stale assumptions. I keep the approved plan in a repository file such as docs/plans/export-jobs.md, then tell each workflow to use that artifact. Durable files are more reliable than expecting conversational context to function as project memory.

Documented Behavior Versus Promotional Claims

The defensible claim is that gstack provides 23 role-oriented Claude Code tools and an opinionated workflow spanning the software lifecycle. You can verify that behavior by reading the installed skills and executing them in a test repository.

Broader claims such as producing dramatically more output, replacing an engineering team, or compressing weeks into hours are promotional until they are demonstrated in your environment. Outcomes depend on repository quality, test coverage, task ambiguity, model choice, permissions, and the developer supervising the work.

The current model lineup also does not erase these constraints. Sonnet 4.6 may be a practical default for sustained coding work, while Haiku 4.5 can fit lighter classification or documentation tasks. Fable 5’s 1M context can help with very large bodies of material, and gpt-5.6-sol provides another engineering-oriented option in supported environments. None turns a role prompt into verified product knowledge or production evidence.

Practical Takeaways

• Treat gstack as an opinionated development process implemented through Claude Code skills.
• Understand “23 agents” as role-based tools, not automatically coordinated persistent workers.
• Install from the repository, inspect setup, and pin a reviewed commit for team use.
• Start with two or three workflows that address known delivery failures.
• Keep approved plans and decisions in files so roles share durable context.
• Separate code review from runtime QA; they catch different classes of failure.
• Restrict secrets, production sessions, Git pushes, and deployment commands while evaluating.
• Measure useful findings and avoided defects, not the number of commands invoked.
• Adopt the full operating system only when its process cost is lower than the failures it prevents.