Superpowers, GSD, and GSTACK: Picking the Right Framework for Your Coding Agent

Three community frameworks have emerged that fix the specific ways AI coding agents break down on real projects. Superpowers enforces test-driven development. GSD prevents context rot. GSTACK adds role-based governance. All three started as Claude Code plugins and now reach across Codex, Cursor, Windsurf, Gemini CLI, OpenCode, and half a dozen other agents.

Pulumi uses general-purpose programming languages to define infrastructure. TypeScript, JavaScript, Python, Go, .NET, Java. Every framework that makes AI agents write better TypeScript also makes your pulumi up better. After spending a few weeks with each one, and revisiting them again as the space moved, I have opinions about when to use which.

The problem these orchestration frameworks solve

AI coding agents are impressive for the first 30 minutes. Then things go sideways. The patterns are predictable enough that three separate teams independently built agent orchestration frameworks to fix them:

Context rot. Every LLM has a context window. As that window fills up, earlier instructions fade. You start a session asking for an S3 bucket with AES-256 encryption, proper ACLs, and access logging. Two hours and 200K tokens later, the agent creates a new bucket with none of those requirements. The context window got crowded and your original instructions lost weight.

No test discipline. Agents write code that looks plausible. Plausible code compiles. Plausible code even runs, for a while. But plausible code without tests is a liability. The agent adds a feature and quietly breaks two others because nothing verified the existing behavior was preserved.

Scope drift. You ask for a VPC with three subnets. The agent decides you also need a NAT gateway, a transit gateway, a VPN endpoint, and a custom DNS resolver. Helpful in theory. In practice, you now have infrastructure you never requested and barely understand. You will also pay for it monthly.

These problems aren’t specific to Claude Code or any particular agent; they happen with Cursor, Codex, Windsurf, and every other LLM-powered coding tool. The context window doesn’t care which name is on the wrapper.

That’s where agent-orchestration frameworks come in. In a single-agent workflow, the agent uses one continuous conversation to hold the whole project in its head. With an orchestration framework, the agent decomposes work into phases, enforcing tests or reviews along the way, handing state between context windows, and dispatching subagents for isolated tasks. Superpowers, GSD, and GSTACK are the three most widely adopted frameworks that do this.

Superpowers: What does it do, and who is it for?

Superpowers enforces a strict rule: no production code gets written without a failing test first. Superpowers was created by Jesse Vincent and has grown to roughly 279K GitHub stars.

The framework enforces a 7-phase workflow. Brainstorm the approach. Write a spec. Create a plan. Write failing tests (TDD). Spin up subagents to implement. Review. Finalize. Every phase has gates. You cannot skip ahead. The iron law is that production code only exists to make a failing test pass.

This sounds rigid. It is. That is the point.

Superpowers includes a Visual Companion for design decisions, which helps when you are making architectural choices that need visual reasoning. The main orchestrator manages the entire workflow from a single context window, delegating implementation work to subagents that run in isolation.

The tradeoff is that the mega-orchestrator pattern means the orchestrator itself can hit context limits on very long sessions. One big brain coordinating everything works well until the big brain fills up. For most projects, this is not an issue. For marathon sessions with dozens of files, keep it in mind.

The workflow breaks down into skills that trigger automatically:

The results are worth citing carefully. chardet 7.0’s own performance docs show it running 41x faster than chardet 6.0.0 (494 files/sec versus 12). Maintainer Dan Blanchard wrote about rewriting chardet from scratch with Claude, delegating implementation work to subagents — but his post never names Superpowers, and it’s mostly about whether the result counts as a derivative work. Take the 41x figure as verified; take “built with Superpowers specifically” as unconfirmed.

Superpowers now reaches well beyond Claude Code: Antigravity, Codex App, Codex CLI, Cursor, Devin CLI, Factory Droid, Gemini CLI, GitHub Copilot CLI, Grok Build CLI, Kimi Code, OpenCode, Pi, and Hermes Agent are all in its current install list.

GSD: How does it prevent context rot?

GSD prevents context rot by keeping the orchestrator out of the work: your main session spawns a fresh-context subagent for each research, planning, execution, and verification task, then collects results instead of accumulating them. GSD (Get Shit Done) was created by Lex Christopherson, known online as TÂCHES.

The key architectural decision: the orchestrator never touches source files. Because it only spawns agents, collects their results, and updates shared state on disk, its own context window grows slowly and predictably, while each spawned agent starts with a clean window scoped to exactly one task. Phase state lands in .planning/ as durable files, so the next step reads artifacts rather than conversation history.

Think about why this matters. When the orchestrator also writes the code, your 200K token context window is a shared resource. Instructions from hour one compete with code from hour three. GSD sidesteps this entirely, because the orchestrator’s job is dispatch and bookkeeping, not implementation. GSD also includes quality gates that detect schema drift and scope reduction. If the agent starts cutting corners or wandering from the plan, the gates catch it.

The tradeoff: GSD has more ceremony than the other two frameworks. For a quick script or a single-file change, the phase-based workflow is overkill. GSD earns its keep on projects that span multiple files, multiple sessions, or multiple days.

The core commands map to a phase-based workflow:

GSD Core’s installer supports Claude Code, OpenCode, Antigravity CLI, Kimi CLI, Kilo, Codex, Copilot, Cursor, and Windsurf, and prompts you for which one at install time.

GSTACK: What does role-based governance buy you?

GSTACK buys you a division of labor: instead of one agent trying to hold product, engineering, QA, and security judgment simultaneously, it splits the work across 23 specialist roles, each with its own scope and constraints. GSTACK was created by Garry Tan (President and CEO of Y Combinator) and has grown to roughly 130K stars.

The framework enforces five layers of constraint. Role focus keeps each specialist in their lane. Data flow controls what information passes between roles. Quality control gates ensure standards at handoff points. The “boil the lake” principle means each role finishes what it can do perfectly and skips what it cannot, rather than producing mediocre work across everything. And the simplicity layer pushes back against unnecessary complexity.

The role isolation is what makes GSTACK distinctive. The engineer role does not see the product roadmap. The QA role does not see the implementation details. Each role only receives the context it needs to do its job. This is not just about efficiency. It prevents the kind of scope creep where an agent that knows everything tries to do everything.

“Boil the lake” is my favorite principle across all three frameworks. It is the opposite of how most agents work. Agents default to attempting everything and producing something mediocre. GSTACK says: do fewer things, but do them right.

The tradeoff: 23 specialist roles feels heavy for pure infrastructure work. If you are writing Pulumi programs and deploying cloud resources with component resources, you probably do not need a product manager role or a designer role. GSTACK shines when you are building a product, not just provisioning infrastructure.

Each slash command activates a different specialist:

GSTACK’s Codex support is the most deliberate of the three: setup reads the model field from your ~/.codex/config.toml and generates a matching behavioral profile automatically, so the role constraints adapt to the specific Codex model you are running. It also supports Claude Code, OpenCode, Cursor, Factory Droid, Slate, Kiro, and Hermes.

Superpowers, GSD, or GSTACK: Which one’s the best fit for you?

None of these is universally best. Knowing your failure mode is the real decision.

For infrastructure work, GSD’s context management matters most. Long Pulumi sessions that provision dozens of resources across multiple stacks are exactly the scenario where context rot bites hardest. GSD’s phase-based approach keeps each orchestrator fresh.

Superpowers’ TDD workflow maps well to application code where unit tests are straightforward. Infrastructure testing is different. You cannot unit test whether an IAM policy actually grants the right permissions. You can test the shape of the policy with Pulumi’s testing frameworks, but the real validation happens at pulumi preview and pulumi up. Superpowers still helps here (discipline is discipline), but the TDD cycle is less natural for infra than for app code.

GSTACK shines when the project has product dimensions. If you are building a SaaS platform where the infrastructure serves a product vision, GSTACK’s multi-role governance keeps the product thinking connected to the engineering work. For pure infra provisioning, the extra roles add overhead without much benefit.

Do Superpowers, GSD, and GSTACK work with Codex?

Yes, all three now support OpenAI’s Codex, though the depth of that support varies. Superpowers ships two separate Codex integrations distributed through the official OpenAI plugin marketplace; GSTACK goes furthest by detecting your specific Codex model and generating a matching behavioral profile; GSD’s installer offers Codex as one of several supported runtimes without Codex-specific tuning.

Codex support has deepened noticeably since this post first ran. All three frameworks now treat it as a first-class target rather than one more name in an install matrix.

What are the alternatives to Superpowers, GSD, and GSTACK?

The most talked-about alternative right now is Everything Claude Code (ECC), built by Affaan Mustafa. Where Superpowers, GSD, and GSTACK each impose one opinionated methodology, ECC takes the opposite approach: a large pre-built bundle of subagents, skills, hooks, and commands — dozens of the first, hundreds of the second — plus a security layer called AgentShield. It works best with Claude Code today, has a supported Codex sync path, and offers capability-limited adapters for Cursor and OpenCode, so check its support-status matrix before assuming feature parity across agents. It has grown large enough that community threads now debate “ECC vs. Superpowers” the same way they debate the three frameworks above. Choose ECC if you want breadth and are willing to pick your own process; choose one of the three above if you want the process itself enforced.

Also worth knowing: wshobson/agents positions itself as a plugin marketplace rather than a single framework, aggregating dozens of agents, skills, and commands that install natively through Claude Code’s plugin system. It is less a competitor to Superpowers, GSD, or GSTACK than a different shelf in the same store.

You can also roll your own. Claude Code’s native subagents, hooks, and skills now cover a meaningful slice of what these frameworks automate, including asynchronous subagent execution that used to require a third-party context-management layer. If your needs are narrow, a CLAUDE.md file plus a couple of custom skills may get you 80% of the value without adopting a whole framework.

For infrastructure specifically, there is also the managed-agent route rather than the framework route — see the note on Pulumi Neo at the end of this post.

How do these frameworks work with Pulumi?

These frameworks solve the “how” of agent orchestration. Skills (like the ones from Pulumi Agent Skills) solve the “what,” teaching agents the right patterns for specific technologies. Frameworks and skills complement each other. A skill tells the agent to use OIDC instead of hardcoded credentials. A framework makes sure the agent still remembers that instruction 200K tokens later. This works because Pulumi infrastructure is real code: an agent operating under Superpowers’ TDD gates or GSD’s phase boundaries can test, refactor, and version infrastructure the same way it does application code, which a declarative config format does not give it room to do.

GSD’s state-to-disk approach pairs naturally with Pulumi stack outputs. Each phase can read the previous phase’s stack outputs from the state files, so a networking phase can provision a VPC and the compute phase can reference the subnet IDs without any context window gymnastics.

Superpowers’ TDD cycle maps to infrastructure validation. Write a failing test (the expected shape of your infrastructure). Run pulumi preview (red, the resources do not exist yet). Run pulumi up (green, the infrastructure matches the test). This is not a perfect analogy since infrastructure tests are broader than unit tests, but the discipline of “verify before moving on” translates directly.

You do not have to pick one framework and commit forever. Try GSD for a long multi-stack project. Try Superpowers for a focused library. See which failure mode bites you most and let that guide your choice.

How do you install and get started?

github.com/obra/superpowers

github.com/open-gsd/gsd-core

github.com/garrytan/gstack

All three frameworks support multiple agents. For Claude Code, the current install commands are:

# Superpowers
/plugin install superpowers@claude-plugins-official

# GSD Core (installer asks which agent and whether to install globally or locally)
npx @opengsd/gsd-core@latest

# GSTACK
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup

If you have an old GSD install pointed at get-shit-done-cc, switch to @opengsd/gsd-core; the original repository is archived and will not receive further updates. Check each repository’s README for Codex, Cursor, Windsurf, and other agent-specific instructions.

If you want a managed experience that handles orchestration for you, Pulumi Neo is grounded in your actual infrastructure, not internet patterns. It understands your stacks, your dependencies, and your deployment history. The 10 things you can do with Neo post shows what that looks like in practice.

Pick one and give it a project. You will know within an hour whether it fixes your particular failure mode.