GSD — The Expensive Way to Use 100% of an AI's Intelligence

TL;DR

• GSD (gsd-build/get-shit-done) is a Claude Code-class meta-framework built by TÂCHES (real name Lex Christopherson) — not a single skill bundle but a spec-driven cycle with opinions about the context environment itself. As of 2026-05-13 (v1.41.0 stable + v1.42.0-rc3 canary): 61.9k★, about 86 entries in the system prompt's eager skill listing (slashes + skills combined; the commands/gsd/ directory is roughly 70 slashes + 6 namespace routers), 31 agents (per docs/INVENTORY.md), 11 hooks, 15 runtimes. Released 2025-12.
• The mechanism in one line: each phase starts with its own fresh 200k context. The five stages — discuss, plan, execute, verify, ship — each summon a fresh Claude, while the main session stays at 30–40% and acts only as dispatcher.
• The cost of this design: it spends tokens linearly. There's a GitHub issue, left closed, where a Claude Max $200-plan user burned a 5-hour window in 40 minutes, and the maintainer answers "4 agents ≈ 4× tokens, this is an intended trade-off." The price of getting peak intelligence every time is peak token cost.
• Used alone, it's strong at marathon, multi-file, multi-session work. Mixed with Superpowers/gstack, it collides at the five conflict surfaces of §6 — especially triple SessionStart hook injection and the point where a GSD subagent bypasses the Superpowers HARD-GATE.

1. Introducing GSD

1.1. What It Is

gsd-build/get-shit-done — a Claude Code-class spec-driven development meta-framework built by TÂCHES. The README introduces itself as "A light-weight meta-prompting, context engineering, and spec-driven development system," but its actual core is a cycle that solves context-window quality degradation (context rot) through environment isolation.

The core promise is compressed into one line of the README:

"Each executor gets a fresh 200k-token context. Each task gets its own atomic commit. Walk away, come back to completed work with a clean git history. … Your main context window stays at 30–40%. The work happens in the subagents." — README

These two sentences are GSD's entire identity. Work doesn't happen in the main context. The main is a dispatcher, and the actual work is done by a 200k-context subagent that spins up fresh each time. When a phase ends, that subagent leaves markdown state on disk and terminates. The next phase's subagent reads that markdown and starts again from a clean 200k.

Why this mechanism matters comes from the problem GSD self-identifies — context rot. The threshold Medium/Mak summarizes from community testing is that quality drops past 50% context usage, and past 70% hallucinations spike (original: "Community testing shows quality drops past 50% context usage. Past 70%, hallucinations spike.").

GSD solves that problem by forcing the main session never to cross that threshold. The five-stage boundaries of discuss, plan, execute, verify, ship are forced termination points that clear the context and start fresh each time.

1.2. The Creator — "How a Solo Developer Doesn't Write Code"

You can't understand GSD without the creator's self-description. From the README's "Why I Built This," verbatim:

"I'm a solo developer. I don't write code — Claude Code does. … Other spec-driven tools exist, but they're all built for 50-person engineering orgs — sprint ceremonies, story points, stakeholder syncs, Jira workflows. I'm not that. I'm a creative person trying to build great things consistently. … The complexity is in the system, not in your workflow." — TÂCHES

GSD's target persona is the solo developer burdened by the ceremony of enterprise spec-driven tools (BMAD, SpecKit, Taskmaster, etc.). It strips away SAFe/Scrum rituals and leaves only spec → phase → execute, isolating the complexity inside the system.

One thing commonly omitted from GSD write-ups: GSD is not actually a one-person project. As of 2026-05-13: 136 contributors, 2,593 cumulative commits. Actual maintainer activity is split between trek-e (1,124 commits) and glittercowboy (= TÂCHES, 945 commits), and the maintainer persona answering user issues is trek-e. The "solo developer" marketing is a founder's self-image, not a governance fact. Worth noting for the piece's credibility.

1.3. Strengths

• It solves context rot at the environment level. Superpowers solves it with process discipline, gstack with role personas — GSD swaps out the context window itself. "The other two change the workflow, GSD changes the workenvironment" is the one-line category classification for the series.
• The TypeScript SDK is gradually rising into the core — but the timeline must be told honestly. The README calls it a "meta-prompting system," yet TS code like sdk/src/phase-runner.ts (50KB) has progressively taken over core behavior. The SDK was introduced in v1.30 (2026-03-26), but until v1.38.4 (2026-04-25) the SDK carried a stripped copy (~17% of the volume), so its actual impact was limited. npm @gsd-build/sdk@latest still sits at v0.1.0, bundled in the parent tarball, so external stand-alone import is impossible (Issue #3406). On top of that caveat, controlling context clearing, git-branch management, token tracking, and stuck-loop detection at the programming level is GSD's implementation difference from the other two (markdown-prompt cores).
• 15 runtimes supported — the broadest of the three. Claude Code, Codex, Copilot CLI, Cursor, Windsurf, Augment, Gemini CLI, OpenCode, Kilo, Antigravity, Trae, Qwen Code, Cline, CodeBuddy, Hermes. One --all flag in install.js installs them all.
• Atomic commit per task. Even with multiple executors running in parallel in the same wave, each task gets its own atomic commit. If one fails, only that commit can be reverted. The git history stays exactly in the phase sequence.
• Defense in Depth. The plan-checker agent pre-verifies the plan → the executor makes atomic commits → a post-hoc verifier checks against phase goals → UAT (human verification) is the final gate. So that a failure at one stage can't leak into the next.

1.4. Installation

# Claude Code standalone
npx get-shit-done-cc --claude

# Claude Code + minimal (94% reduction in system-prompt overhead)
npx get-shit-done-cc --claude --minimal

# Install to all supported runtimes
npx get-shit-done-cc --all

After install, the core assets unpack into ~/.claude/get-shit-done/, and slash commands mount under ~/.claude/commands/gsd/. First use is /gsd-new-project to initialize the project → /gsd-discuss-phase 1 → /gsd-plan-phase 1 → /gsd-execute-phase 1, in that order.

The runtime recommendation is stamped into the README:

claude --dangerously-skip-permissions

"GSD is built for frictionless automation. Skip-permissions is how it's intended to run." — README

Because stopping at every permission prompt makes phase parallel execution meaningless. But the caveat that applying it as-is to production code is dangerous is also stated in GSD's docs.

2. How It Works — Phase Boundaries Coupled With Fresh Context

2.1. The 5 Design Principles (ARCHITECTURE.md)

Why GSD works the way it does is all in the Design Principles section of docs/ARCHITECTURE.md — the header itself is just Design Principles, with no number, and the body lists five in turn. Quoted:

1. Fresh Context Per Agent — "Every agent spawned by an orchestrator gets a clean context window (up to 200K tokens). This eliminates context rot — the quality degradation that happens as an AI fills its context window with accumulated conversation."
2. Thin Orchestrators — "Workflow files (get-shit-done/workflows/*.md) never do heavy lifting."
3. File-Based State — "All state lives in .planning/ as human-readable Markdown and JSON. No database, no server, no external dependencies."
4. Absent = Enabled — a missing workflow feature flag is the enabled state. Only explicit deactivation deactivates.
5. Defense in Depth — "Plans are verified before execution (plan-checker agent). Execution produces atomic commits per task. Post-execution verification checks against phase goals. UAT provides human verification as final gate."

These five principles combine to form the cycle. 1 and 2 explain why work doesn't happen in the main, 3 explains how information passes between phases, 4 explains why the configuration burden is low, and 5 explains why the quality gates are embedded.

2.2. The Core Loop — discuss, plan, execute, verify, ship

The README's core loop:

/gsd-new-project          # 1. Initialize: Questions → research → requirements → roadmap
/gsd-discuss-phase 1      # 2. Discuss: capture decisions before plan
/gsd-plan-phase 1         # 3. Plan: research → plan → verify loop
/gsd-execute-phase 1      # 4. Execute: parallel waves, atomic commits per task
/gsd-verify-work 1        # 5. Verify: walk through, diagnose fixes
/gsd-ship 1               # 6. Ship → /gsd-complete-milestone → /gsd-new-milestone

Each stage is a different subagent instance. The main session only dispatches those instances.

Wave execution — the heart of /gsd-execute-phase. The wave visual from docs/USER-GUIDE.md:

Wave 1 (parallel):
  [Executor A] → 01-01-PLAN.md (core function)  ✓ committed
  [Executor B] → 01-02-PLAN.md (middleware)      ✓ committed

[Verifier] Checking codebase against phase goals...
  REQ-001 validateSignature() ✓
  REQ-002 timing-safe compare ✓
  REQ-003 tolerance window    ✓

Multiple executors in the same wave run genuinely in parallel. Per docs/ARCHITECTURE.md, parallel commit safety is guaranteed by two mechanisms:

"--no-verify commits — Parallel agents skip pre-commit hooks (which can cause build lock contention, e.g., cargo lock fights in Rust projects). STATE.md file locking — All writeStateMd() calls use lockfile-based mutual exclusion (STATE.md.lock with O_EXCL atomic creation)."

That is, GSD subagents deliberately skip your project's pre-commit hooks (--no-verify). If you run standard tooling like static analysis, test automation, or conventional-commit lint, you have to be conscious of this — under GSD, that verification has to be handled inside the executor, and external git hooks are neutralized.

2.3. The .planning/ Directory — file-based state

The reason GSD uses neither a database nor a server is the phase boundary. Even when one phase's executor disappears, the next phase has to be able to pick up with only the markdown left in .planning/. The key files:

Phase boundary = state write = next boot. Since all information is on disk, crash recovery happens naturally. (v2 switched to SQLite + DB-authoritative state, but the v1 main line is still markdown-based.)

2.4. The 6 namespace meta-skills (a cost lever introduced in v1.40)

Exposing all 86 slash commands directly in the system prompt costs ~2,150 tokens of cold-start overhead. From v1.40, they're bundled into 6 namespace routers, exposing only the routers' descriptions:

"Six namespace routers ship as the first-stage entry points in v1.40. They keep the eager skill-listing token cost low (~120 tokens for 6 routers vs ~2,150 for a flat 86-skill listing)." — docs/COMMANDS.md

86 → 6 = about 94% cold-start cost reduction. Even so, the core cost — each executor grabbing a fresh 200k during phase execution — doesn't change. This is a router-level optimization, not an execution cost one.

2.5. --minimal install — an additional system-prompt lever

The --minimal (or --core-only) flag installs only the core skills. CHANGELOG v1.41.0:

"Cuts cold-start system-prompt overhead from ~12k tokens to ~700, useful for local LLMs with 32K–128K context (Sonnet 4.6 / Opus 4.7 don't need it)."

≈ 94% reduction (12k → 700). Combined with the namespace meta-skills, GSD can be made light in cold-start tokens alone — but the execution cost is still determined by the fresh-context model core.

3. Token Cost — an Honest Unpacking of the "Expensive" Part

The most commonly skipped part of GSD write-ups is token cost. The README only stresses that "the main stays at 30–40%," but user reports say that 30% can be multiplied 5–10×.

3.1. The README's Claim

"Your main context window stays at 30–40%. The work happens in the subagents." — README

Read this sentence alone and it looks like cost drops, but the key is the "work happens in the subagents" part. The main is at 30%, but N subagents each grab 200k. Total token usage is main + N × fresh.

3.2. The Actual User Report — Issue #1553

"GSD burns through my $200 Max Claude token allocation in minutes. A few actions with ~10% of work completed and my 5-hour usage window is done. I can't code more than 40 minutes if I use parallel instances or multiple agents." — Issue #1553

The issue was closed with status: blocked + upstream-bug labels. Maintainer trek-e's answer (verbatim):

"GSD's core design — fresh context per agent — is a deliberate tradeoff. Each subagent gets a clean 200K context window. This prevents context rot (quality degradation as context fills up) but means: — The orchestrator holds context while waiting for agents — Each agent loads relevant planning artifacts independently — Parallel agents multiply this linearly (4 agents ≈ 4× tokens) — Cache reads are the hidden cost — they're billed differently than input tokens but still count against your quota

This is how the system works. The quality consistency you get from fresh-context agents comes at a token cost."

In other words, "Max plan burned in 40 minutes" is not a bug but the design. The honest sticker price of fresh-context. "Use 100% of an AI's intelligence = pay the cost anew every time" — the expensive part of the title hardens into fact here: since you get peak intelligence not once but anew every phase, the cost is billed anew every phase too.

3.3. User-Reported Overhead Ratios

• DEV/Kazmi: "4:1 token overhead ratio (reported by one user)." — Pro plan ($20/mo) "insufficient for regular GSD." Max plan ($100–200/mo) recommended.
• maintainer trek-e (Issue #1553): "4 agents ≈ 4× tokens. Cache reads are the hidden cost."
• USER-GUIDE: "Too many MCPs can reduce your effective window from 200K to ~70K." — with MCP servers installed, the effective context shrinks and the token cost gets heavier.
• ARCHITECTURE.md: "Heavyweight MCP servers (browser/playwright, Mac-tools, Windows-tools) can each cost 20k+ tokens per turn — often dwarfing what model_profile tuning saves."

Add all these numbers up and GSD doesn't run well on Claude Pro ($20), and even on Max ($100–200) you have to mind your usage. This is why external analyses recommend the following:

3.4. Mitigation Levers — cost controls GSD itself provides

1. --minimal install — 12k → 700 tokens cold-start (94% reduction).
2. 6 namespace meta-skills — 2,150 → 120 tokens system prompt (94% reduction).
3. model_profile — quality (all Opus), balanced (plan Opus + execute Sonnet), budget (plan Sonnet + execute Sonnet + verify Haiku). The README states "/gsd:set-profile budget — This is the single biggest lever."
4. /gsd-health --context — 60% utilization warns, 70% critical. Signals you to spin up a fresh /gsd-thread before the main session crosses the threshold.
5. Disable MCP servers — turning off unused MCPs saves 20k+ tokens per turn.
6. /gsd-fast / /gsd-quick — skip the planning stage. Doesn't force a full cycle on a trivial task.

In summary: GSD's core cost is genuinely heavy, and these levers can shave it by, at the low end, close to 90%. But the cost of the core mechanism itself — fresh context per subagent — can't be shaved; that's GSD's identity.

3.5. One-Line Verdict

To close the expensive hook honestly:

• Claude Pro ($20/mo): the GSD full cycle structurally doesn't run. Don't even start. /gsd-quick or no GSD is the answer.
• Claude Max ($100–200/mo): within the same 5-hour window, worst case is ~40 minutes (full parallel wave + no restraint — Issue #1553), typical is 2–3 hours (restrained waves, model_profile=budget, --minimal), and the sustained pace is a ceiling of one project per day. The three horizons are different faces of one envelope, split by how the same user exercises restraint.
• Direct API (token-based pricing, unlimited): token cost flows straight to dollars, so it's an environment where you can measure cost per unit of work. On marathon projects you have to explicitly weigh the trade-off of time saved vs. the token bill.

The one line trek-e gave in Issue #1553 is the heart of it — "This is how the system works. The quality consistency you get from fresh-context agents comes at a token cost." To the person who kept hearing "oh, I forgot that" every time the context window filled up, GSD sells an expensive way to stop hearing it. It's the exact right tool only for the user who can pay that price anew every time.

4. The Slash Catalog

The commands/gsd/ directory has about 66 slash .md files + 6 namespace routers. The system prompt's eager skill listing combines commands + skills + agents descriptions for ~86 entries (per CHANGELOG v1.41.0). Only the core 6 + the 6 most frequently used are covered in the body.

Per-runtime spelling differences (docs/COMMANDS.md):

"Claude Code / Copilot / OpenCode / Kilo: /gsd-command-name [args] (hyphen). Gemini CLI: /gsd:command-name [args] (colon). Codex: $gsd-command-name [args]. The hyphen and colon forms are runtime-specific spellings of the same command."

GSD is the only one of the three that isolates every slash behind a /gsd- prefix. Install Superpowers/gstack on the same system and the slash names won't collide. This is a big advantage when combining, in §6.

The 6 Most-Used Commands

The core ones a new project will pass through in a full cycle.

/gsd-new-project

Project initialization. Throws questions at the user, gathers answers, and generates PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md, config.json. The --auto @file.md flag can extract from an existing document and skip the questions. Runs once.

/gsd-discuss-phase [N]

The stage that makes decisions explicit before a phase starts. README: "capture decisions before plan." If the user starts writing code straight away without making a plan, GSD can't catch which decisions were left buried unmade. Discuss explicitly saves those decisions to CONTEXT.md. Flags: --all, --auto, --batch, --analyze, --power, --assumptions.

/gsd-plan-phase [N]

A research + plan + verify loop. Generates PLAN.md. A plan is recommended to be 2–3 tasks max (USER-GUIDE: "Plans should have 2–3 tasks maximum. If tasks are too large, they exceed what a single context window can produce reliably."). Large plans are solved by splitting into phases. Added in v1.51 — Package Legitimacy Gate: when the researcher recommends an external package, it runs slopcheck install <pkg> --json to defend against slopsquatting (fake packages an LLM hallucinated).

/gsd-execute-phase <N>

Executes all of a phase's plans in parallel waves. Multiple executors in parallel within a wave, atomic commit per task, committing with --no-verify (bypassing pre-commit hooks). Flags: --wave N, --validate, --cross-ai (cross-check with another LLM), --no-cross-ai. This is where token cost is heaviest — Issue #1553's "Max plan burned in 40 minutes" happens at exactly this command.

/gsd-verify-work [N]

Verifies the executed work against the phase goals. Generates VERIFICATION.md. Found defects are organized into a diagnosed fix plan — flowing naturally into the next plan-phase.

/gsd-ship [N]

Turns the phase result into a PR. The auto-generated PR body combines SUMMARY.md + VERIFICATION.md + UAT.md. --draft can create a draft PR. After ship, /gsd-complete-milestone → /gsd-new-milestone starts the next milestone.

Fast Paths — /gsd-quick, /gsd-fast

GSD's own answer to the "GSD is too heavy" criticism raised in Issue #2251:

• /gsd-quick — minimal workflow. Compresses the discuss/plan/execute/verify/ship cycle into one phase.
• /gsd-fast — completely skips the planning stage. Executes a trivial task inline.

Work like a color change, a typo fix, polishing one line of a README should not run the whole cycle — go to these two commands. Start with /gsd-plan-phase by mistake and you spend 4×–10× more tokens.

5. v1 → v2 — From a Markdown Framework to a TypeScript Application

Look at GSD at a single point in time and you miss an axis of evolution. v1 was a markdown-prompt bundle; v2 is a TypeScript application.

5.1. Gradual SDK evolution within v1 (CHANGELOG analysis)

The timeline of the SDK gradually becoming the core inside gsd-build/get-shit-done (= the v1 line):

The v1 line is a hybrid where markdown prompts + a TypeScript SDK coexist. The SDK keeps adding thickness, but the end-user surface is still slash commands. Key SDK code locations:

sdk/src/phase-runner.ts      (50 KB)  ← core phase orchestration
sdk/src/init-runner.ts       (26 KB)
sdk/src/cli.ts               (20 KB)
sdk/src/event-stream.ts      (14 KB)  ← telemetry
sdk/src/plan-parser.ts       (15 KB)
sdk/src/context-engine.ts    (6.5 KB)
sdk/src/context-truncation.ts (7 KB)

5.2. v2 — the separate repo gsd-build/gsd-2

The real v2 is a separate repo in the same organization — gsd-build/gsd-2. 7.4k★, v2.82.0 (2026-05-10), TypeScript 95.0%, MIT.

v1 → v2 differences (summarized from the gsd-2 README):

The v2 core holds DB-authoritative state in SQLite, and .gsd/ markdown is merely a projection. v2's Context Mode claims "40–60% token reduction" via sandboxed gsd_exec, gsd_exec_search, gsd_resume (a claim, externally unverified). 24 bundled MCP extensions + 20+ LLM provider support.

One line from the v2 README compresses GSD's identity most:

"The iron rule: a task must fit in one context window."

5.3. Implications of the Evolution

What v1 asked of the LLM via prompts shifted in v2 to forcing the LLM via TypeScript code. This is a decisive difference from the other two in the category:

• Superpowers = still a markdown-prompt bundle. using-superpowers/SKILL.md forces with "You MUST," but if the LLM breaks it, that's that.
• gstack = markdown slash commands. Each command carries persona instructions, but in essence it's a prompt guide.
• GSD v1 = a markdown + TypeScript SDK hybrid. The SDK clears context directly and manages git branches directly. If the LLM breaks it, the SDK catches it.
• GSD v2 = a TypeScript application. The LLM is the worker, the SDK is the manager.

This is why GSD has the thickest engineering investment of the three. The implementation difference within the category is the largest.

6. Where It Breaks When Used Alongside Superpowers/gstack

The points below aren't observed from running them together — they're read off each one's SessionStart hooks, README, definition files, and filed issues, listing only collisions that are structurally inevitable.

Installing all three meta-frameworks on one machine, there are five conflict surfaces. Some are direct technical conflicts, some are design mismatches.

6.1. SessionStart Hook — triple bootstrap injection

All three embed a SessionStart hook. The official Claude Code manual:

"All matching hooks run in parallel, and identical handlers are deduplicated automatically. Command hooks are deduplicated by command string and args."

→ Since the three register on SessionStart with different commands, all three bootstraps inject into context. The order is nondeterministic. Superpowers' <EXTREMELY_IMPORTANT> block + gstack's auto-update banner + GSD's gsd-update-banner.js all go in at once, and which went in first determines that session's behavior.

An extra variable: Claude Code itself has Issue #19491, left closed — "SessionStart hooks are checked and executed before plugins with those hooks are fully loaded, resulting in a 'startup hook error' message at session start." Even with only Superpowers installed, there's an official issue of the hook not running in the first session. A multi-framework environment is more nondeterministic still.

Mitigation: don't run the three bootstraps concurrently in one environment — pick one main framework and opt the rest in per project via .claude/settings.local.json. Or just one at a time.

6.2. Slash names — only GSD avoids them, gstack is top-level

Names like /review and /ship are occupied by gstack. GSD isolates them as /gsd-review, /gsd-ship. Superpowers has essentially no slash commands (legacy slashes like /brainstorm, /execute-plan were removed in v5.1.0, making Skill self-invocation the default path). Direct slash-name collisions are nearly nonexistent. Thanks to GSD's prefix discipline.

6.3. CLAUDE.md intrusion — only gstack modifies the user's policy file

The gstack README instructs you to add a section directly to your CLAUDE.md:

"Install gstack: … then add a 'gstack' section to CLAUDE.md that says to use the /browse skill from gstack for all web browsing, never use mcp__claude-in-chrome__* tools, …"

GSD, by contrast, doesn't auto-modify CLAUDE.md — only recommends. Superpowers keeps its instructions in the plugin's own CLAUDE.md and doesn't touch the user's CLAUDE.md.

The result: gstack's instructions stick most stubbornly into the user context. With all three installed, gstack's policy is permanently visible across every session of the project, while GSD's and Superpowers' bootstraps inject only at session start. A priority emerges that differs from the user's intent.

Mitigation: if you install gstack, review that section yourself. Putting it in project-level .claude/CLAUDE.md rather than the global ~/.claude/CLAUDE.md is better for isolation.

6.4. GSD subagent fresh context — bypassing the Superpowers HARD-GATE

GSD's very identity bypasses Superpowers' most central mechanism.

Superpowers' brainstorming/SKILL.md nails down "Every project goes through this process. A todo list, a single-function utility, a config change — all of them." The using-superpowers message injected by the SessionStart bootstrap lays this HARD-GATE each time, together with the "1% rule."

But the executor GSD dispatches via /gsd-execute-phase starts with fresh 200k context — the main session's bootstrap is not passed to the subagent. That is:

• In the main session, the Superpowers HARD-GATE works → a user utterance triggers brainstorming
• But inside the executor GSD dispatched, there's no Superpowers bootstrap → the HARD-GATE is inactive
• The executor takes GSD's PLAN.md and writes code straight from it — it never sees Superpowers' "no implementation without brainstorming" rule

This is not a bug but a design conflict. GSD's fresh-context = out-of-the-box neutralization of the Superpowers HARD-GATE. To combine them, you'd have to manually brigade Superpowers' discipline by wrapping it into GSD's PLAN.md instructions or agent definitions — but that erodes both sides' design assumptions.

Mitigation: don't use the two frameworks in the same phase. The recommendation external combination guides agree on is stage separation — Medium/Mak summarizes it as make the spec and plan with GSD, hand the code stage to Superpowers, but no concurrent operation in the same phase. That is, float the spec and plan into the jet stream with GSD, and when writing code move to Superpowers' brainstorming → SDD cycle. Or just one of the two.

6.5. gstack's empty Build phase — the very motivation for combining

gstack has an intentional empty space. The workflow goes Think (/office-hours) → Plan (/plan-*-review) → Build → Review (/review) → Ship (/ship), but there is no slash or skill defined for the Build phase. When writing code, Claude Code falls back to default mode until the user manually calls /review.

This is the direct reason the combination discourse exists. Three external analyses all converge on the same conclusion:

• The Pulumi comparison table's GSTACK row, "Where it struggles" column: "The actual writing-code part."
• Medium/Mak: groups the three frameworks as think (gstack) · stabilize (GSD) · execute (Superpowers).
• DEV/Chen (imaginex): Decision/roles (gstack) → Context/spec (GSD) → Execution (Superpowers) — layer-wise sequence separation.

Since the three frameworks each have their own role, they can be combined in sequence, but not together at the same stage. This is why the combination recommendation is always "separate by stage."

6.6. Interactive Q&A blocking the stream

A micro-conflict Medium/Mak found:

"In practice, there's a technical blocker: Superpowers' interactive Q&A prompts during the build phase block Claude Code's input stream. GSD v2 is a TypeScript application rather than Markdown prompts, adding integration complexity."

Superpowers' brainstorming stage waits for the user's answer. GSD's /gsd-execute-phase assumes frictionless automation (the same grain as the README's --dangerously-skip-permissions recommendation). When the two assumptions meet in one session, GSD stalls or falls back to a fallback mode.

Mitigation: don't run the two frameworks in interactive mode concurrently in the same stream. It's safer to export one framework's result as .planning/ markdown and use it as the next framework's starting input — which is also what DEV/Imaginex's combination guide recommends.

6.7. Conflict-Surface Summary

It's also interesting that the three frameworks never mention each other in their official docs. The combination discourse is generated 100% by third parties (Pulumi, Medium, DEV.to, YouTube). That is, there's no official guideline, and every combination is the user's experiment.

7. Limitations and Trade-offs

7.1. Learning curve — Issue #2251

"52 skill commands, 25+ agent configurations, many workflow steps … Long documentation, hard for new users to get started quickly. For most developers, this flexibility may be a burden rather than help. 53k stars but only 4.5k forks — many might just be 'bookmarking'." — Issue #2251

GSD has a lot to do. 86 commands, 5 phases, 31 agents, 9 standard markdown files. There's a community rebuttal that "starting with /gsd-quick takes 5 minutes," but that's only if you use that command alone. Learning the core cycle has a learning cost.

7.2. v2 SDK npm gate — Issue #3406

"SDK query layer documented in v1.39+ CHANGELOG but @gsd-build/sdk@latest is still v0.1.0 (no query subcommand)"

The SDK thickening inside the v1 line is bundled in the parent tarball without a stable publish as a separate npm package. The path to import the GSD SDK standalone from outside is unfinished. If a user wants to embed the SDK into their own toolchain, they have to install the entire v1 package.

7.3. Solo-developer marketing vs. governance fact

The part covered in §1.2 — the difference between the "solo developer" self-image and the 136-contributor, separated-maintainer governance. A small team's collaborative project is closer to the truth.

7.4. --no-verify commits and the deactivation of external git hooks

The point covered in §2.2. GSD subagents commit with --no-verify, bypassing the project's pre-commit hooks. If you run lint, formatter, type check, or secret scanner as git hooks, GSD doesn't see them. The verification has to move inside the executor.

7.5. The source of the README claim "the context-rot threshold"

GSD frequently cites "quality drops past 50%, hallucinations spike past 70%," but where these numbers were originally measured is not specified in the README/USER-GUIDE. It only says "Community testing." A critical user should measure it on their own workload.

7.6. Fresh-context's cross-task information loss

That a phase boundary forcibly terminates the context also means the next phase can't see the subtle decisions of the immediately prior phase. Compressed transfer via SUMMARY.md / VERIFICATION.md happens, but compression is loss. Subtle implicit decisions — e.g. "this function name was deliberately left long" — disappear between phases.

With the arrival of 1M-context models (Opus 4.6, Sonnet 4.6), GSD responds with "Adaptive Context Enrichment" — on 500K+ models, the executor additionally receives prior-wave SUMMARYs + the phase CONTEXT/RESEARCH. This is a partial relaxation of the fresh-context principle, not its abandonment.

8. Synthesis — GSD Is a Framework of "Environment Opinion"

Boiled to three lines:

1. Not a process opinion but an environment opinion. Superpowers forces how to work, gstack forces who works. GSD forces where to work — a fresh 200k context every phase. Of the three in the category, the deepest at the environment level.
2. A TypeScript core — the only one of the three controlling the LLM with code. The other two ask via markdown prompts. GSD v1 is a hybrid, v2 a full TS application. The thickest implementation investment in the category.
3. An expensive trade-off, honestly exposed. The maintainer's answer in Issue #1553 — "4 agents ≈ 4× tokens. This is how the system works." — says the essence. The cost of getting AI's 100% intelligence anew every phase is billed anew every phase. A Max plan or above is effectively the premise.

Operational conclusion: for marathon, multi-file, multi-day projects, GSD is the best fit of the three. For a 5-minute single-file fix, the worst fit of the three. Don't run it concurrently in the same session with Superpowers/gstack — out-of-the-box combination collides at the conflict surfaces of §6 (especially the nondeterministic order of SessionStart hooks and the GSD subagent's bypass of the Superpowers HARD-GATE). Only the layer-sequence separation agreed on by three external guides (gstack strategy → GSD spec/state → Superpowers build) is valid. If you install it alone, isolating the other two via per-project opt-in is the safe path. The honest close on the expensive hook is in §3.5.

One-line recommendation — if you have tokens to spare, turn GSD on. For the Max-plan-or-above user, or the solo developer who can consciously manage token cost via the direct API, GSD is the tool that most reliably extracts peak quality of the three. The promise that you can get the same work anew every phase from a Claude that hasn't gone dumb is real, and the mechanism keeps that promise faithfully. If you're short on tokens, GSD can't keep its promise — in that environment, lightweight Superpowers alone is the more honest choice. In other words, budget is the deciding variable. When you have the budget, GSD knows the best way to spend it.

References

Official primary

• gsd-build/get-shit-done — v1.41.0 stable, v1.42.0-rc3 canary
• README.md · README.ko-KR.md
• docs/ARCHITECTURE.md — the 5 design principles, MCP token cost, adaptive context enrichment
• docs/COMMANDS.md — 86 commands + 6 namespace router definitions
• docs/USER-GUIDE.md — wave execution, plan-size recommendations
• CHANGELOG.md — v1.29~v1.41 SDK evolution timeline
• gsd-build/gsd-2 — v2 standalone CLI (v2.82.0, 7.4k★)

GSD's honest limits, seen through issues

• Issue #1553 — Max $200 plan burned in 40 minutes. maintainer's answer: "deliberate tradeoff"
• Issue #2251 — learning curve, excessive complexity — "53k stars but only 4.5k forks"
• Issue #1086 — adaptation to the 1M-context model (Opus 4.6/Sonnet 4.6) era
• Issue #3309 — the token cost of the human-verify checkpoint
• Issue #3406 — the SDK npm-publish gate

Comparison & combination, external analyses

• Pulumi — Superpowers, GSD, GSTACK: Picking the Right Framework — Diri, 2026-04-13. The official comparison table
• Medium — What Each Claude Code Framework Actually Constrains — Mak, 2026-04-06. "gstack thinks, GSD stabilizes, Superpowers executes"
• DEV — A Claude Code Skills Stack: Combine Without the Chaos — Chen, 2026-04-06. Combination-sequence guide
• Augment Code — GSD Stars Analysis — Galstian, 2026-04-16. 14 runtimes, numeric summary
• DEV — Complete Beginner's Guide to GSD — Kazmi, 2026-03-17. The 4:1 token-overhead report

The creator

• LinkedIn — Lex Christopherson
• X — @official_taches / @gsd_foundation
• GSD Discord