Get Shit Done (GSD) for Claude Code is a community framework that drives Claude Code through a fixed loop of discuss, plan, execute, verify and ship, pushing heavy work into fresh subagents and keeping project state in Markdown files. The original gsd-build/get-shit-done repository is archived; the project continues as GSD Core, installed with:
npx @opengsd/gsd-core@latest
Applies to: GSD Core 1.15.0 on npm (@opengsd/gsd-core) with Claude Code, per the project’s README and docs as of October 2, 2026. Last checked: October 2, 2026.
GSD is not an Anthropic product. Everything below describes what the project’s own README and docs say it does. Directory listing: /skills/gsd-core.
On this page
Where the project lives now
| Repository | Status | What it holds |
|---|---|---|
| gsd-build/get-shit-done | Archived | A README titled “GSD Has Moved” that points to the new repository |
| open-gsd/gsd-core | Active | Source, issues, releases and docs; MIT license (LICENSE) |
The archived repository’s README says it “is no longer the active home for GSD development” and that the project “now continues as GSD Core in the Open GSD repository”. Guides and posts that tell you to clone or install from gsd-build/get-shit-done are out of date.
What the README says GSD Core does
The GSD Core README describes it as “a light-weight meta-prompting, context engineering, and spec-driven development system” for Claude Code, OpenCode, Antigravity CLI, Kimi CLI, Kilo, Codex, Copilot, Cursor, Windsurf and more. The problem it targets, per the README, is “context rot”: output quality falling as an agent fills its context window. Its answer is to run research, planning and execution in fresh-context subagents while the main session stays small.
Each milestone repeats a five-step loop, one phase at a time (README; The phase loop):
- Discuss: capture implementation decisions before planning.
- Plan: research, break the phase into plans and check they fit a fresh context window.
- Execute: run plans in parallel waves; the README says each executor starts with a clean 200k-token context.
- Verify: walk through what was built, diagnose gaps and generate fix plans.
- Ship: create the pull request, archive the phase, move to the next one.
An optional UI design step (/gsd-ui-phase) can sit between Discuss and Plan for frontend work.
Install in Claude Code
-
Run the installer. It asks which runtime you use and whether to install globally or locally:
npx @opengsd/gsd-core@latestThe install guide gives the non-interactive form for Claude Code at user level:
npx @opengsd/gsd-core@latest --claude --global -
Restart Claude Code. The same guide says the skills land in
~/.claude/and the commands appear as/gsd-*slash commands in your next session. -
Start a project:
/gsd-new-project # greenfield project /gsd-onboard # existing codebase
The README says the installer “is required for cross-runtime compatibility” and tells you not to copy files from agents/ or commands/ by hand. The install guide also documents a native Claude Code plugin path through a .claude-plugin/plugin.json manifest, and notes that install-time configuration is not applied on that path.
If you install both globally and locally, the install guide says the global skill wins the /gsd-<name> trigger, following Claude Code’s rule that personal skills override project skills (Claude Code skills docs); GSD prints a warning after install when this happens.
Main commands
From the project’s command reference. In Claude Code the form is /gsd-command-name; in Codex it is $gsd-command-name.
| Command | What the docs say it does | Main output |
|---|---|---|
/gsd-new-project | Starts a project with context gathering; --auto @file.md extracts from a document | PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md, config.json, research/, CLAUDE.md |
/gsd-onboard | Guides an existing codebase through mapping and setup | .planning/codebase/, .planning/onboarding/SUMMARY.md |
/gsd-discuss-phase N | Gathers decisions for a phase through questions | {phase}-CONTEXT.md, {phase}-DISCUSSION-LOG.md |
/gsd-plan-phase N | Researches, plans and checks a phase | {phase}-RESEARCH.md, {phase}-{N}-PLAN.md, {phase}-VALIDATION.md |
/gsd-execute-phase N | Runs all plans in a phase in waves; --wave N runs one wave | Per-plan SUMMARY.md, git commits, {phase}-VERIFICATION.md |
/gsd-verify-work N | User acceptance testing with diagnosis | {phase}-UAT.md, fix plans if issues are found |
/gsd-ship N | Creates a PR from verified work; needs the gh CLI installed and signed in | GitHub PR, updated STATE.md |
/gsd-next | Reads state and offers the next step, then runs one command | None (router) |
/gsd-quick | Runs an ad-hoc task with the same guarantees; --full adds discussion, research and checks | Task artifacts |
/gsd-autonomous | Runs the remaining phases without stopping; --from, --to, --only limit the range | Phase artifacts |
/gsd-update | Updates GSD with a changelog preview | None |
The reference also lists six namespace routers (/gsd-workflow, /gsd-project, /gsd-quality, /gsd-context, /gsd-manage, /gsd-ideate). It says they keep the skill listing at about 120 tokens instead of about 2,150 for the full flat list, while every concrete command stays callable.
A typical cycle from the project’s user guide, started with plain claude:
/gsd-new-project
/clear
/gsd-discuss-phase 1
/gsd-plan-phase 1
/gsd-execute-phase 1
/gsd-verify-work 1
/gsd-ship 1
How it uses subagents
The project’s context engineering explainer says the main session acts as an orchestrator that “never touches source files”: it spawns agents, collects their results, updates shared state and routes to the next step. For /gsd-plan-phase, it describes the sequence as:
- Load a compact JSON context payload (project summary, phase goal, relevant config).
- Spawn a researcher agent with a clean window.
- Spawn a planner agent with the research output and phase requirements.
- Spawn a plan-checker agent to verify the plan before execution.
The command reference adds that the heavy Claude Code skills (/gsd-plan-phase, /gsd-execute-phase, /gsd-autonomous) declare effort: max and must run at the top level so they keep the Agent tool they need to spawn subagents. Claude Code’s own subagents docs explain how subagents get their own context window.
How it keeps state in files
According to the explainer, every meaningful output is written to .planning/ as Markdown or JSON, so a restart does not lose work and you can read, edit or commit the files.
| File | Role per the docs |
|---|---|
.planning/STATE.md | Current milestone, phase and completed plans, decisions, blockers and progress; every workflow reads it at start and writes it back |
PROJECT.md, REQUIREMENTS.md, ROADMAP.md | Project scope, requirements with IDs, and the phase list |
{phase}-CONTEXT.md | Implementation decisions from the Discuss step |
{phase}-RESEARCH.md, {phase}-{N}-PLAN.md | Research findings and dependency-ordered plans with acceptance criteria |
{phase}-VERIFICATION.md, {phase}-UAT.md | What the verifier and user acceptance checks found |
.planning/config.json | Project settings such as mode, granularity and model_profile |
The same explainer says GSD registers Claude Code hooks (PreCompact, Stop, SubagentStop) to warn about context headroom, and uses FileChanged to reload config.json mid-session. Claude Code’s hooks reference documents those events.
Permissions and auto-approve settings
The project’s user guide shows a full-cycle example that starts with claude --dangerously-skip-permissions. The guide’s own caution says the flag is optional, skips per-file confirmation while GSD’s subagents read and write files, should be used only in low-stakes or throwaway contexts, and that you can start with plain claude to keep confirmations.
Warning
Anthropic’s permission modes docs say
bypassPermissionsmode, which--dangerously-skip-permissionsturns on, “disables permission prompts and safety checks so tool calls execute immediately”, and to use it only in isolated environments like containers, VMs or dev containers without internet access, where Claude Code cannot damage your host system.
Safer options documented by Anthropic:
acceptEditsmode auto-approves file edits and common filesystem commands while other commands still prompt (permission modes).- Allow rules in settings pre-approve specific tools or commands, and deny rules block them in every mode (Configure permissions).
- For unattended runs, Anthropic points to its dev container configuration, which runs Claude Code as a non-root user (permission modes).
GSD has its own mode setting in .planning/config.json. The configuration reference lists interactive (the default, which confirms at each step) and yolo, which “auto-approves decisions”. That setting controls GSD’s own workflow gates, not Claude Code’s tool permissions.
