Get Shit Done: phased context engineering for coding agents

Everything you need to know about gsd-build/get-shit-done: the historical repository of a spec-driven development workflow that now redirects its active development to open-gsd/gsd-core.

What Get Shit Done is

Get Shit Done (GSD) was a lightweight system of metaprompts, context engineering, and spec-driven development for coding agents. Its historical README describes it as a proposal for Claude Code; the repository no longer contains active code: since May 2026 it has shown a notice redirecting to open-gsd/gsd-core, which now concentrates code, issues, releases, and contributions.

The continuation, GSD Core, aims to limit the quality degradation that accumulates as an agent’s conversation fills its context window. To do this, it preserves project artifacts such as STATE.md and CONTEXT.md, and offloads intensive research, planning, and execution to subagents with fresh context. Its current README declares compatibility with Claude Code, OpenCode, Antigravity CLI, Kimi CLI, Kilo, Codex, Copilot, Cursor, and Windsurf, among others.

Translucent context window split into isolated chambers with agents processing tasks, alongside the STATE.md and CONTEXT.md files glowing in neon green.

The origin: a popular repository that changed homes

The GitHub API dates the creation of gsd-build/get-shit-done to December 14, 2025. Its description attributes the system to TÂCHES, but the sources retrieved do not verifiably identify a specific person behind that name; therefore, no individual authorship is attributed. The API’s top contributors are trek-e (1,435 contributions), glittercowboy (945), and Tibsfox (127).

The recent history is sharper than the initial launch: the historical repository’s README states that GSD continued as GSD Core at open-gsd/gsd-core. The API dates this new repository to May 22, 2026. No launch announcement with origin anecdotes was found, nor a team post explaining the organizational reason for the move; beyond the migration notice, that part remains unverified.

The transition also creates a practical tension: the historically popular repository is still the one that shows up in searches and community links, while the current instructions explicitly say it should not be used for issues, releases, or contributions. In other words, the historical repository’s figures alone do not describe current maintenance.

Cyberpunk migration scene: a weathered server tower labeled gsd-build/get-shit-done connected by a neon data bridge to a bright new core labeled open-gsd/gsd-core, with the dates Dec 14, 2025 and May 22, 2026 floating nearby.

Philosophy and principles

The proposal rests on five repeatable per-phase steps:

Converse: settle implementation decisions before planning.
Plan: research, break down, and verify that the plan fits in a fresh context.
Execute: process plans in parallel waves, with clean-context executors.
Verify: review what was built, diagnose failures, and fix them before declaring it done.
Deliver: create the pull request, archive the phase, and repeat the cycle.

Five-panel holographic infographic representing the Converse, Plan, Execute, Verify, and Deliver phases, connected by a looping neon line.

It is a philosophy of context control and persistent state, not a promise that any agent will produce correct code. The current README argues that the operational problem is information loss between sessions and the absence of verification; the artifacts and the verification phase are its explicit answer.

How it works

The current install runs with:

npx @opengsd/gsd-core@latest

The installer asks about the environment and about a global or local install; the documentation advises against directly copying files from agents/ or commands/, since the install adapts the package to each environment.

Futuristic terminal showing the command npx @opengsd/gsd-core@latest in neon green, with icons for compatible environments like Claude Code, Cursor, and Windsurf connected by strands of light.

To start a project, among other commands, these are used:

/gsd-new-project   # new project
/gsd-onboard       # existing codebase

The result of the cycle is not just a conversation: GSD preserves decisions and state in files, splits the work into phases, and can run plans in parallel. GSD Core’s documentation claims each executor receives a clean context of up to 200,000 tokens; that is a feature the project states, not an independent measurement.

The latest stable release retrieved for GSD Core, v1.9.1 (July 31, 2026), adds an input type for external reviewers and fixes, among other items, worktree isolation, a clean Codex install, and project-root resolution. The most recent historical release of gsd-build/get-shit-done was the release candidate v1.43.0-rc2, from May 17, 2026.

Official and semi-official status

No evidence was found that gsd-build/get-shit-done was accepted into an official marketplace from Anthropic, OpenAI, GitHub, Cursor, or another provider. No vendor endorsement statement was found either. It is therefore not appropriate to describe it as an official plugin or a formal standard.

It can be described as a de facto reference within part of the agent-workflow community: the Hacker News thread from March 2026 placed it alongside Superpowers, OpenSpec, and Spec Kit, and several commenters used it as a point of comparison. This status describes community use and recognition, not vendor certification or validation of results.

The ecosystem

Repositories maintained by the GSD organizations

The GitHub API, retrieved on August 2, 2026, shows an active family around the Open GSD continuation:

open-gsd/gsd-core: main continuation; 7,558 stars and 518 forks.
open-gsd/gsd-pi: adaptation for Pi; 989 stars and 88 forks.
open-gsd/gsd-path: disciplined evolution from idea to shipped code; 0 stars in the response consulted.
open-gsd/gsd-spec-build-loop: spec → build → review loop skill; 5 stars.
open-gsd/gsd-browser: command-line interface for browser automation based on the Chrome DevTools Protocol; 36 stars.
open-gsd/gsd-test-runner: remote Node test runner in containers; 9 stars.
open-gsd/gsd-cursor: plugin for the Cursor marketplace; 1 star.
open-gsd/marketplace-gsd-dev: OpenGSD marketplace; 2 stars.
open-gsd/gsd-cloud-daemon: GSD Cloud daemon; 3 stars.

The former gsd-build organization also holds gsd-2 (7,749 stars), agent-inbox (57), gsd-browser (251), daemon (8), context-packet (50), docs (2), and protocol-go (1). These names and figures come from querying those organizations’ repositories; they do not imply that all of them have the same support status.

Ports, forks, and community extensions

rokicool/gsd-opencode appears in GSD Core’s README as the original OpenCode port. Its star count was not retrieved in this run.
itsjwill/gsd-pro, a fork advertising multi-model routing, retrieval, and adaptive context, had 79 stars and 16 forks.
sudokku/gsd-watch, a real-time dashboard for phases, tasks, and sessions with tmux, had 19 stars.
lgwanai/spec-skill presents itself in Chinese as a deep recreation of the GSD workflow and claims to interoperate .planning documents with GSD; it had 6 stars. It is a verifiable example of a non-English adaptation.
PCJIRON/gsd-qwen adapts GSD to the Qwen Code extension; it had 2 stars.
buildtheturfu/turfu-gsd states in French that it builds on GSD and preserves the research, converse, plan, execute, verify, and deliver phases; its search result showed 0 stars.
uublive/GSD-Locksmith adds team coordination to avoid milestone and phase collisions; the result showed 0 stars.
snipcodeit/mgw defines itself as GitHub project orchestration on top of GSD, from issue to pull request; it showed 5 stars.

These forks and extensions are third-party projects. Their existence does not amount to endorsement by the Open GSD team.

Glowing hexagonal core of open-gsd/gsd-core surrounded by satellite nodes representing repositories such as gsd-pi, gsd-browser, gsd-test-runner, gsd-pro, and gsd-watch.

Repo numbers

Measured: August 2, 2026, public GitHub API.

Metric	`gsd-build/get-shit-done` historical	`open-gsd/gsd-core` active
Stars	64,783	7,558
Forks	5,463	518
Real subscribers	266	31
Commits	2,928	4,898
Open issues reported by API	0	150
License	MIT	MIT
Created	December 14, 2025	May 22, 2026
Last metadata update	August 2, 2026	August 2, 2026
Latest release retrieved	`v1.43.0-rc2`, May 17, 2026	`v1.9.1`, July 31, 2026

Commit totals are derived from the last page indicated by the API’s pagination links. In the historical repository, the API’s primary language is JavaScript, and the retrieved breakdown contains JavaScript, TypeScript, and Shell. The general API mirrors the star count in watchers_count; that’s why subscribers_count is reported here as the real subscriber figure. Its open_issues_count field can include open pull requests; it should not be read as an issue-only count.

The active repository’s top contributors are trek-e (2,982 contributions), glittercowboy (945), Tibsfox (127), davesienkowski (125), and jeremymcs (122).

As an additional usage signal, npm reported 41,372 downloads of get-shit-done-cc between July 2 and July 31, 2026, and 38,843 of @opengsd/gsd-core over the same interval. Downloads do not identify unique installs or successful usage.

Dashboard with two holographic bar charts comparing the historical repository's and the active repository's metrics, alongside an npm downloads chart.

How to contribute

Contributions should be directed to open-gsd/gsd-core, not to the archived repository. The guide requires Node per .nvmrc, npm run check:env, npm ci, and npm test; npm ci is mandatory to respect the lockfile.

The process is explicitly “issue before code.” For a bug fix, a report is opened first and confirmation is awaited; for an enhancement, the approved-enhancement label is needed; for a new feature, an approved specification and approved-feature. A pull request is then created with the appropriate template, tests, and a reference to the issue. Nearly all pull requests target the next branch; main is reserved for production, critical fixes, and releases. The guide states that pull requests without an approved issue are automatically closed and that CI must stay green.

Cyberpunk flow diagram of the contribution process: an issue report advances to an approved enhancement, a pull request, and finally a green CI status, with the next and main branches diverging at the end.

How the community received it

The Hacker News submission 47417804, posted by stefankuehnel on March 17, 2026, reached 473 points and 253 comments according to the Algolia search; directly querying the item returned 65 comments in the available response. The discrepancy is an observable limitation of the retrieved responses, so the second number is not used as the definitive total.

Hacker News terminal with a point counter ticking up to 473 and comment bubbles mixing favorable reactions with criticism about cost and session limits.

The reception was clearly mixed and offers concrete examples:

yoaviram stated that GSD did “95%” of the work on complex tasks and that they used it to launch a SaaS product; they added that models had also improved over the period. This is enthusiasm based on personal experience, not a controlled evaluation.
schnitzelstoat, in thread 48019025, said the tool helped them plan and keep context small, though it was slower than using Claude directly. That thread recorded 270 points and 40 comments on the item retrieved.
anentropic appreciated that the system asks questions and manages context, but noted that it doesn’t let you just fire off a task and forget about it, and that it re-reads its own planning files quite a bit.
The most repeated criticism was cost. MeetingsBrowser said they got no measurable improvement over direct instructions and hit session limits in about 30 minutes; gtirloni estimated, from their experience, ten times more token consumption; vinnymac criticized the interaction time and excessive planning.
ibrahim_h objected that the historical recommendation to run with --dangerously-skip-permissions can open a risk surface: by their reading, the plan checker reviews logical completeness, not every generated command. This is a technical criticism attributed to that commenter; it was not validated through an independent audit in this run.
Andrei_dev questioned whether generating a lot of code equates to reviewing it well and cited risks such as hardcoded credentials and unauthenticated routes. joegaebel argued that natural-language specifications do not replace automated tests. Both are objections from participants, not confirmed defects of the project.

Get Shit Done versus other proposals

Proposal	Verifiable overlap	Verifiable difference or comparison limit
`obra/superpowers`	In the HN thread, several participants compared it to GSD as a structured agent workflow.	`gtirloni` said they preferred the native planning mode and associated both frameworks with higher token spend; no independent test establishing a winner was found.
`github/spec-kit`	`bgnm2000` and `ochronus` listed it alongside GSD as a planning or spec-driven development tool.	The sources found only prove that the community groups them together; they are not enough to claim architectural or performance equivalence.
OpenSpec	`gbrindisi` said they preferred it because it lets you adjust the workflow progressively.	That is a user preference, not an experimental comparison; GSD differs here in its phase cycle and documented artifacts.
`ChristopherKahler/paul`	`jankhg` presented it as another alternative and linked a comparison in their repository.	The commenter said PAUL avoids subagents and might therefore require fewer tokens; the linked study was not retrieved or verified.
`buildomator/buildomator`	Described as a plan → execute → verify workflow for Claude Code, and states it evolved from GSD.	GitHub’s description advertises project status via MCP and drift detection; it had 83 stars, but its token-savings claims were not verified.

Use cases and who this repository can help

Teams starting a codebase or bringing an existing project into an agent workflow can install the active continuation with npx @opengsd/gsd-core@latest and start with /gsd-new-project or /gsd-onboard. The converse, plan, execute, verify, and deliver cycle leaves decisions and state in artifacts such as CONTEXT.md and STATE.md, splits work by phase, and lets fresh-context executors process plans in waves.

Maintainers who need to contribute to or update GSD should work in open-gsd/gsd-core, not the historical repository: set up the environment with .nvmrc, run npm run check:env, npm ci, and npm test, open an issue before writing code, and direct most pull requests to next. The repository can also serve those comparing spec-driven workflows, but it’s worth weighing token cost, extra planning, and execution permissions before applying it to small or sensitive tasks.

Resources

Historical repository: https://github.com/gsd-build/get-shit-done
Current code, issues, and releases: https://github.com/open-gsd/gsd-core
Documentation and installation: https://github.com/open-gsd/gsd-core#quickstart
Commands and configuration: https://github.com/open-gsd/gsd-core/tree/main/docs
Official contributing guide: https://github.com/open-gsd/gsd-core/blob/main/CONTRIBUTING.md
Official skills and workflow: https://github.com/open-gsd/gsd-core/tree/main/agents
Discord community: https://discord.gg/mYgfVNfA2r
Community conversation and reviews: https://news.ycombinator.com/item?id=47417804, https://news.ycombinator.com/item?id=48019025

Note: this article combines GSD’s README and contributing guides, the GitHub API, the npm API, and Hacker News data retrieved on August 2, 2026. Figures change over time.