GSD vs Superpowers: Project Phases or Engineering Procedures?

Choose GSD Core when the main problem is coordinating phases, state and context across a project. Choose Superpowers when the main problem is getting the agent to follow sound engineering steps on each change. Both include planning, execution and verification. The distinction is their organizing emphasis, not a claim that either lacks the other’s practices.

There is a source change worth resolving before any comparison: as checked November 6, 2026, gsd-build/get-shit-done says it is no longer the active development home and directs readers to GSD Core at open-gsd/gsd-core. This article compares that documented successor with current Superpowers. It does not silently apply older GSD commands to the new project. Sources: migration notice, GSD Core README.

What each workflow organizes

GSD Core describes a context-engineering and spec-driven development framework. A milestone repeats a discuss, plan, execute, verify and ship loop, one phase at a time. Heavy work runs in fresh-context subagents; structured artifacts preserve decisions and state between sessions. Source: current workflow.

Superpowers describes a complete development methodology made from composable skills. Its workflow draws out intent, obtains design approval, writes an implementation plan, builds with testing, reviews the result and decides how to integrate the branch. Relevant skills trigger automatically. Source: current workflow.

Question	GSD Core emphasis	Superpowers emphasis
What unit organizes work?	Milestones, phases and plans	An approved design and implementation tasks
How does work survive sessions?	Structured state and context artifacts	Durable designs and plans, plus execution procedures
How is context managed?	Fresh-context subagents for heavy stages	Inline or fresh-subagent implementation routes
What does verification establish?	Whether the phase’s built behavior is acceptable	Evidence for completion claims, tests and reviewed work
What do you adopt?	Project lifecycle and coordination conventions	Connected engineering skills and triggering rules

These are editorial interpretations of the source documentation. They are not results from running the same feature twice. Neither repository’s description establishes comparative defect rates, speed or model cost.

When project state is the problem

Consider a migration with several stages: new schema, data backfill, dual reads, cutover and cleanup. Each stage has dependencies and a different definition of safe completion. A chat transcript is an awkward project ledger, especially when another session must resume midway.

GSD Core’s documented artifacts include STATE.md and CONTEXT.md. Its phase loop gives decisions, plans and verification an explicit place in the project lifecycle. That structure is relevant when you need to answer “which phase are we in?” before asking “what code should change?” Source: persistent context explanation in README.

The cost is adopting and maintaining the conventions. A state file that claims the backfill is complete when it is not can mislead the next executor. Treat project artifacts as reviewable engineering outputs, with an owner and evidence, rather than assuming their existence guarantees reliable memory.

GSD Core also documents onboarding an existing repository. It is not restricted to new projects. Read the current onboarding guide before introducing its lifecycle into an established team’s issue tracker and release process.

When engineering behavior is the problem

If the agent repeatedly codes before clarifying requirements, guesses at a bug fix, or declares success without command output, Superpowers targets those behaviors directly. Its skills include brainstorming, systematic debugging, TDD and verification before completion. Source: skills library.

That is useful even when your project tracker already handles roadmap state. You can evaluate the process at the scale of one substantial change: was the design agreed, did the plan address it, and does the evidence justify completion?

Superpowers is not confined to one uninterrupted chat. Designs and plans are durable artifacts, and the implementation workflow offers both inline execution and fresh implementer subagents. Conversely, GSD Core is not merely a planner; execution and verification are explicit stages. Avoid choosing based on an exaggerated “one handles projects, one only writes code” distinction.

For the individual procedures and earlier packaging, see our Superpowers guide. For more control over procedure selection, our Superpowers vs Matt Pocock skills comparison addresses a different decision.

Fresh context helps only when the handoff is sufficient

Both projects use subagents, but “fresh context” is a mechanism rather than proof of quality. A fresh executor cannot recover a requirement that the plan omitted. A long-running executor can also fail if obsolete assumptions remain unchallenged.

GSD Core foregrounds moving heavy research, planning and execution out of the main session. Superpowers offers fresh implementers per task as one implementation route. In either case, inspect the information crossing the handoff: accepted behavior, relevant files, dependencies, constraints and verification commands. Sources: GSD Core architecture summary, Superpowers execution routes.

Check whether another engineer could perform the task from the handoff. Capture missing context before increasing concurrency.

Context isolation does not establish lower model cost. This comparison contains no measured usage or cost estimate.

Worked example: a reporting rebuild

This example is illustrative, not a project we executed with either tool. Suppose a team must add scheduled reports, background generation, account permissions and downloadable results.

With GSD Core, a reasonable evaluation would divide the initiative into phases with explicit dependencies. Settle scheduling and permissions decisions before planning the relevant phase. Execute bounded plans, verify the built behavior, and record what is ready for the next phase. Inspect whether a resumed session can accurately locate the project’s current state.

With Superpowers, a reasonable evaluation would begin with the intended behavior and approved design. The implementation plan would break the work into reviewable tasks. Check that tests exercise permission failures and retry behavior, and that completion claims include current verification evidence. Inspect whether the reviewed branch matches the agreed design.

Include migration and deployment requirements in your acceptance criteria. Both workflows need your repository’s operational checks.

For a fair pilot, use the same acceptance criteria: unauthorized users cannot fetch reports, duplicate job delivery does not duplicate effects, and failed reports expose an actionable status. Record missing requirements, review corrections, verification gaps and intervention time. Speed alone cannot decide whether the result is safe to merge.

Adoption and switching

Follow the successor repository’s setup documentation for GSD Core. Its README says the installer is required for cross-runtime compatibility and warns against copying agent or command files directly. Superpowers likewise documents installation separately by host. This article deliberately leaves installation to those primary sources because a stale command can install a different workflow than the one compared here. Sources: GSD Core installation, Superpowers installation.

When switching, preserve accepted specifications, decisions and tests. Map unfinished work into the new workflow and start with one orchestration system.

Combining them is possible in principle, but first define who owns planning, execution and verification. Two automatic procedures can disagree about whether the next action is another discussion, a task executor or a phase closeout. Treat a combination as a workflow design you must evaluate, not an automatic upgrade.

FAQ

Is GSD now called GSD Core?

The former gsd-build/get-shit-done repository points to open-gsd/gsd-core as the continuing project. Check that destination and its documentation rather than assuming every historical GSD guide describes the current implementation. Source: migration notice.

Is Superpowers better for small changes?

Task size alone is insufficient. A small authorization fix may need careful diagnosis and tests; a large project may already have excellent coordination. Choose according to the missing discipline and evaluate the process overhead on your actual work.

Can both work on existing repositories?

GSD Core documents an existing-codebase onboarding path. Superpowers documents a general development workflow with workspace isolation and verification. In either case, inspect how it interacts with existing tests, project instructions and release rules before adopting it broadly.

Which should I try first?

Try GSD Core if lost state and phase dependencies dominate your corrections. Try Superpowers if skipped design, weak debugging or unsupported completion claims dominate. If neither is your main gap, use our Superpowers alternatives guide.

Sources and review scope

Checked November 6, 2026: GSD migration notice, GSD Core pinned README and Superpowers pinned README. This is a documented-workflow comparison with editorial decision criteria, not firsthand benchmark evidence. Review after source releases or on December 6, 2026.