For months "context engineering" has been LinkedIn currency: numbered lists with arrows, motivational blurbs about structured AI workflows. The phrase looks like padding.

Then Get Shit Done shows up: 52k GitHub stars, 4,400 forks, 473 Hacker News points after the March 2026 launch post, and a v1.35.0 release two days ago. Whatever the marketing layer is doing, the demand underneath is real.

The problem it solves

Anthropic's engineering team published a direct explanation in September 2025: as an LLM's context window fills, model quality degrades. They call it "context rot." The transformer architecture treats every token as having pairwise relationships with every other token, so the more tokens you stuff in, the more diffuse the attention budget gets. A 200k token context window is not 200k tokens of equally good reasoning.

Anyone who has run Claude Code or Cursor on a project longer than a few hours has watched it happen. The agent contradicts decisions it made earlier. It drops requirements it confirmed two phases ago. It suggests changes that break things it already fixed.

GSD's answer: each task in a build plan gets its own fresh context window.

What that looks like in practice

npx get-shit-done-cc@latest

Works on 14 runtimes as of v1.35.0, including Claude Code, Gemini CLI, Cursor, Copilot, Windsurf, and nine others (Cline, CodeBuddy, Qwen Code, OpenCode, Kilo, Codex, Antigravity, Augment, Trae).

Full disclosure: I work the adjacent layer of this problem in PromptScript, where one .prs source compiles into native instruction files for 38+ agent targets, so the same project rules land in CLAUDE.md, AGENTS.md, .cursorrules, and the rest without a per-runtime fork. Different layer of the stack than GSD, but the multi-runtime fan-out is recognizable from the other side. I will cover that contrast in a separate article.

The workflow has six phases:

/gsd-new-project       captures vision, requirements, roadmap
/gsd-discuss-phase N   surfaces design decisions before building
/gsd-plan-phase N      generates XML-structured atomic task plans
/gsd-execute-phase N   runs tasks in dependency-ordered waves, fresh context per task
/gsd-verify-work N     tests output, generates fix plans on failure
/gsd-ship N            atomic git commits, PR creation

Phase 4 is where the structural work happens. "Wave-based execution" means independent tasks run in parallel, each with a clean context window. Dependent tasks wait. State persists across resets via PROJECT.md, REQUIREMENTS.md, STATE.md, and since v1.34.0 a queryable .planning/intel/ directory holding structured JSON codebase intelligence. The agent does not need to rediscover what it already knows. It reads the files.

v1.35.0 (April 11, 2026) adds Cline, CodeBuddy, and Qwen Code to the supported runtime list, plus an AI framework selection wizard and 25+ bug fixes covering worktree safety and file integrity issues.

The criticism worth quoting

GSD hit 473 HN points, but the most pointed GitHub discussion comment puts the real question in plain text: "GSD is a highly overengineered piece of software that unfortunately does not get shit done, burns limits and takes ages while doing so."

A separate commenter in a Claude Code setup thread went back to unstructured prompting after GSD created "an illusion" of structure without proportional output. A third called it "somewhat overengineered" but acknowledged "a kernel of a good idea."

That kernel is real. The engineering around it is heavy: six command phases, XML task structures, multiple persistent state files, quality gates for schema drift, security enforcement, and scope-reduction detection. For a weekend project this overhead is absurd. For anything with more than three phases and multiple agents running in parallel, the tradeoff likely holds.

The open issues list confirms this is not a polished product yet: path resolution breaks in WSL and Docker, permission errors on fresh installs, a config loop bug with certain runtime combinations. Active triage by the maintainer, but rough edges visible.

What changed in April

v1.34.0 introduced a global learnings store: knowledge from one project persists and can be queried in future projects. v1.34.2 lowered the Node.js requirement from 24 back to 22 (LTS until October 2026), which was quietly breaking installs. v1.35.0 added the framework selection wizard, which asks which runtime you are on before configuring, fixing the previous situation where you had to know the right package name per editor.

The release cadence (five versions in eight days, April 4-11) suggests either a very active project or a very unstable one. Probably both.

Sources: GitHub repo, Anthropic Engineering Blog, HN discussion