GSD for Claude Code: What It Is, How to Install It, and the Core Commands

GSD is an open-source workflow system that plugs into Claude Code as a set of slash commands, skills, subagents and hooks. You'll usually see it searched as the "Get S*** Done" Claude skill. It breaks a project into phases and runs each one through the same loop: discuss, plan, execute, verify, ship. The heavy work runs in fresh subagents so your main session stays small.

The part most guides miss: the original repository has moved. Here's where things stand as of October 2026:

• Current home: open-gsd/gsd-core, published as GSD Core under the MIT license
• Install: npx @opengsd/gsd-core@latest (the older npm package is marked as no longer supported)
• First commands: /gsd-new-project for a fresh project, /gsd-onboard for an existing codebase
• Works with: Claude Code, plus Codex, Copilot, Cursor, Windsurf, OpenCode and other agent runtimes

Below: what GSD actually does, how to install it for Claude Code, the commands you'll use daily, and when it's more process than you need.

What GSD for Claude Code is

GSD started life in the original gsd-build repository, whose description calls it "a light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code". That repository is now archived. Its README says GSD "has moved" and points to GSD Core in the Open GSD organization.

GSD Core's README describes the problem it targets as context rot: the drop in output quality that builds up as an AI fills its context window. If you've had a long Claude Code session start strong and then drift, forget earlier decisions, or redo finished work, that's the failure GSD is designed around.

Its answer has three parts:

• Fresh contexts for heavy work. Research, planning and execution run in subagents, not in your main chat. If subagents are new to you, our Claude Code subagents guide covers how they work. Anthropic's subagent docs explain the key property: each one gets its own context window.
• Files that outlive the session. GSD writes its state to disk in a .planning/ folder: PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md, plus per-phase files like CONTEXT.md and PLAN.md. A new session reads those files instead of relying on chat history.
• A verify step before "done." A verifier checks what was built against the phase goal and the decisions you recorded, then writes fix plans if something doesn't match.

Is GSD a Claude skill, a plugin, or something else?

All three, depending on how you install it. The npm installer copies commands, skills, agents and hooks into your Claude Code config. GSD Core also ships a native Claude Code plugin manifest. So "GSD Claude skill" and "GSD Claude Code plugin" point at the same project. For the general difference between these pieces, see our explainers on Claude skills and Claude Code plugins.

Who maintains it now

The project lives under the Open GSD organization, whose site at opengsd.net lists GSD Core alongside related tools: GSD Pi (a standalone terminal CLI), plus newer ones like gsd-path and gsd-loop. You don't need any of those to use GSD in Claude Code. GSD Core is the piece that plugs into an existing runtime.

How to install GSD in Claude Code

GSD Core's README gives one command for a standard install:

npx @opengsd/gsd-core@latest

The installer asks which runtime you use and whether to install globally (all projects) or locally (this project only). The README is explicit that the installer is required: don't copy files from the repo's agents/ or commands/ folders by hand, because each runtime needs them converted to its own format.

If you already know you want Claude Code, the project's install guide gives the non-interactive forms:

After installing, restart Claude Code. The /gsd-* commands appear in your next session. Per the install guide, a local install's settings take precedence over the global one when both exist.

What the installer adds besides commands

The install guide lists Claude Code hooks that GSD registers automatically. They cover update checks at session start, context monitoring, a read-before-edit guard, a guard against reading secret files, a prompt-injection scan on file reads, workflow and worktree guards, and commit validation.

This matters for review. Hooks run on every matching tool call, so read the hook table in the install guide before installing on a work machine.

The native plugin route

GSD Core also documents a Claude Code plugin path (claude plugin install gsd-core, marked "once listed"). Two differences from the npm route:

• Different command names. Plugin workflows are namespaced, for example /gsd-core:gsd-plan-phase instead of /gsd-plan-phase.
• No install-time config. Settings the npm installer bakes in at install time don't apply on the plugin path. The guide says to use the npm installer if you rely on them.

If you just want it working, the npm installer is the documented default.

The GSD workflow: discuss, plan, execute, verify, ship

Every GSD project is split into milestones (a releasable version) and phases (one bounded piece of work inside a milestone). Each phase runs through the same loop:

1. Discuss. You and Claude settle implementation choices before planning: libraries, error handling, edge cases. The result is a CONTEXT.md file the later steps all read.
2. Plan. A researcher, a planner and a plan-checker run as separate subagents. They produce RESEARCH.md and one or more PLAN.md files, grouped into waves that can run in parallel safely.
3. Execute. Executors run the plans, and each one commits its work atomically. The README says each executor "starts with a clean 200k-token context."
4. Verify. A verifier compares what was built with the phase goal and your recorded decisions, then writes VERIFICATION.md and fix plans for any gaps.
5. Ship. GSD opens a pull request from the phase work and marks the phase complete in STATE.md.

There's also an optional UI step between Discuss and Plan for phases with real interface work. It produces a UI-SPEC.md design contract.

The project's own phase loop explainer gives a good sizing rule. "Add HMAC-SHA256 signature validation middleware" is a good phase. "Build the authentication system" usually isn't, because it hides several independent concerns. A README typo is too small for the loop.

If you already use Claude Code's built-in plan mode, think of GSD as plan mode stretched across a whole project. It also writes the plan to disk, splits it into parallel tasks, and adds a verification pass at the end.

GSD commands you'll actually use

GSD Core's command reference is long. These are the ones that cover a normal week:

On Claude Code these use the hyphen form (/gsd-plan-phase). The reference notes Codex uses $gsd-plan-phase instead, and the installer writes the right form for each runtime.

The reference also lists six "namespace" commands (/gsd-workflow, /gsd-project, /gsd-quality, /gsd-context, /gsd-manage, /gsd-ideate). They route to the specific commands above, which keeps the list of skills Claude has to load small. You can still call every specific command directly.

When GSD is worth it, and when it isn't

GSD adds structure, and structure has a cost. Here's a fair way to decide:

A few practical cautions:

• Read your hooks. GSD installs several hooks. That's part of how it works, but you should know what runs on your machine.
• Watch your usage. Planning and execution spawn several subagents per phase, and /gsd-plan-phase and /gsd-execute-phase ask Claude Code for maximum effort. A phase will likely use more of your Claude usage than a single chat would.
• Check you're on the current package. Older tutorials install an npm package whose name ends in -cc. That package is no longer supported, and the repo it came from is archived. Use @opengsd/gsd-core instead.

Key takeaways

• GSD is a free, MIT-licensed workflow system for Claude Code and other agent runtimes, built to fight context rot.
• The original GSD repo under gsd-build is archived. The project continues as GSD Core at open-gsd/gsd-core.
• Install with npx @opengsd/gsd-core@latest, or --claude --global / --claude --local to skip the prompts. Restart Claude Code afterwards.
• The loop is discuss, plan, execute, verify, ship, run one phase at a time, with state saved in .planning/.
• Start with /gsd-new-project or /gsd-onboard, use /gsd-next when you're unsure what's next, and use /gsd-quick for small tasks.

If you like the idea of a proven setup but keep stalling at the install step, Taku mirrors a working AI setup into a desktop workspace and runs it, so you can use a power user's configuration without rebuilding their environment first. Taku is in Beta, and the Mac app is available now.

FAQ

What is the GSD Claude skill?

It's the community name for GSD, an open-source workflow system for Claude Code. It adds /gsd-* slash commands, skills, subagents and hooks that run your project through a discuss, plan, execute, verify and ship loop. The current version is GSD Core at open-gsd/gsd-core.

How do I install GSD in Claude Code?

Run npx @opengsd/gsd-core@latest and choose Claude Code when asked, or run npx @opengsd/gsd-core@latest --claude --global to skip the prompt. Restart Claude Code, then run /gsd-new-project or /gsd-onboard.

Is GSD free and open source?

Yes. GSD Core is released under the MIT license. You still need your own Claude Code access, and GSD's subagents use your normal Claude usage.

Why does the old GSD repo say it has moved?

The original GSD repository under the gsd-build account is archived. Its README points to GSD Core in the Open GSD organization as the active home for source code, issues and releases.

Does GSD only work with Claude Code?

No. GSD Core's README lists Claude Code, OpenCode, Antigravity CLI, Kimi CLI, Kilo, Codex, Copilot, Cursor and Windsurf, among others. The installer converts the files for each runtime.

What's the difference between /gsd-quick and the full phase loop?

/gsd-quick runs a single ad-hoc task inside GSD without the discussion, research and verification steps, unless you add flags like --discuss, --research, --validate or --full. The full loop is for real features that need planning and verification.