GSD hits 53.9K stars with spec-driven dev system for Claude Code

Context rot is a problem most developers hit and few talk about openly. As Claude fills its context window during long coding sessions, output quality drops: responses get shorter, instructions get missed, code gets inconsistent. Get Shit Done (GSD) is the most structured open-source attempt I've seen at solving it systematically.

Created by developer TÂCHES, GSD sits on top of Claude Code as a context engineering layer. It just crossed 53.9K GitHub stars, which tells me this problem is more widespread than most teams admit, and that developers are done waiting for model vendors to fix it.

What Happened

GSD v1.36.0 is the latest release, with the project now at 132 contributors, 49 releases, and 4.5K forks since its initial commit in December 2025. That's a significant amount of development velocity for a project that's only a few months old.

The system started as a Claude Code-specific tool and has since expanded to support 14 runtimes including Codex, Copilot, Cursor, Windsurf, Augment, Gemini CLI, and Qwen Code. Installation is a single command: npx get-shit-done-cc@latest.

What I'd flag here is the pace of the v1.36.0 release specifically. It added a knowledge graph integration for planning agents (/gsd-graphify), a TDD pipeline mode with a --tdd flag, context-window-aware prompt thinning for sub-200K models, and 30+ bug fixes. That's not an incremental release; it's a meaningful expansion of what the system can do.

Key Features

• Fresh context per plan execution. Each task plan runs in a new subagent with a full 200K token window, avoiding accumulated context degradation. The orchestrator session stays at 30-40% usage throughout.
• Wave-based parallel execution. Plans are grouped by dependency into waves. Independent plans run in parallel within a wave; dependent plans wait. Each task gets its own atomic git commit.
• Spec-driven planning pipeline. A five-step workflow: discuss phase decisions, research implementation approaches, generate XML-structured task plans, execute in parallel, then verify against requirements.
• Multi-agent orchestration. Thin orchestrators spawn specialized agents for research (4 parallel investigators), planning (planner and checker loop), execution (parallel per wave), and verification (verifier and debugger).
• 14 runtime support. One installer targets Claude Code, Codex, Copilot, Cursor, Windsurf, Augment, Gemini CLI, OpenCode, Kilo, Antigravity, Trae, Qwen Code, Cline, and CodeBuddy.
• Built-in security scanning. Path traversal prevention, prompt injection detection, a PreToolUse guard hook, and CI-ready injection scanning across all agent workflow files.

Why It Matters

The core insight behind GSD is that AI coding agents produce worse output as their context window fills up. Rather than fight this limitation, GSD works around it: break projects into small, atomic task plans, execute each in a fresh context, and stitch results together with git commits.

For teams, the practical result is real. A developer can run /gsd-execute-phase and walk away. The system handles parallel execution, verification, and commit history without manual intervention. According to the README, the project is trusted by engineers at Amazon, Google, Shopify, and Webflow.

The broader pattern I'm seeing is developers moving past raw prompting toward structured systems that manage AI agent context deliberately. GSD is a clear bet that the prompt engineering layer, not the model itself, is the bottleneck for reliable AI-assisted development. Based on the star trajectory, a lot of developers agree.

Example Use Case

A solo developer building a SaaS app with Next.js runs /gsd-new-project and describes their idea. GSD asks clarifying questions, spawns research agents, then generates PROJECT.md, REQUIREMENTS.md, and ROADMAP.md.

For Phase 1 (authentication), they run /gsd-discuss-phase 1 to lock decisions: email-based login, JWT via jose, httpOnly cookies. /gsd-plan-phase 1 produces atomic plans with XML task structures that include the action, the files to touch, and a built-in verification step. /gsd-execute-phase 1 runs both plans in parallel, each in fresh context, commits per task, then verifies against phase goals.

This is the workflow I'd walk through with a team that's been asking how to make AI-assisted development actually reliable at scale. The answer here is concrete enough to evaluate in an afternoon.

Competitive Context

GSD positions itself directly against other spec-driven development tools. The README calls out BMAD and Speckit specifically, arguing they add unnecessary enterprise ceremony: sprint ceremonies, story points, stakeholder syncs. GSD takes the opposite position. Complexity lives in the system, not the workflow.

The distinction worth understanding is that GSD doesn't replace Claude Code; it sits on top of it. Where Claude Code provides the execution runtime, GSD provides the planning structure, context management, and multi-agent orchestration that keep output consistent across long projects. Compared to manual CLAUDE.md files or ad hoc prompting strategies, GSD offers a full lifecycle: project initialization, phase planning, parallel execution, verification, and milestone management, all with automatic state tracking.

The 14-runtime support is also worth noting. This started as a Claude Code tool and now spans Cursor, Copilot, Codex, Gemini CLI, and more. That breadth tells me TÂCHES is optimizing for where developers actually work, not just where the project started.

My Take

GSD is a structured meta-prompting system that solves context window degradation for AI coding agents by breaking work into atomic plans executed in fresh contexts. If you use Claude Code or any of the 13 other supported runtimes for serious development work and have hit quality walls on longer projects, this is worth evaluating.

Install with npx get-shit-done-cc@latest and run /gsd-help to start. At 53.9K stars, 132 contributors, and 4.5K forks, the community weight behind it is real. I'd rather adopt a system that's already been stress-tested across this many codebases than rebuild the same scaffolding myself.