Retired system (July 2026). GSD, the methodology this artifact documents, was retired on 2026-07-06 in favor of a lighter unit of execution: a loop with a goal, a deterministic gate, an iteration budget, and a receipt. The /gsd:* commands no longer exist. This artifact stays published as a record of the system that built this site. The full story: Why I retired the system I documented.

Getting Started with GSD

You start a project with Claude. The first session is productive. Ideas flow, code gets written, decisions get made. Then the session ends.

Next time you come back, Claude doesn't remember any of it. The architectural decisions you debated for thirty minutes? Gone. The approach you chose after weighing three alternatives? Gone. The specific file structure you agreed on? Gone. You spend the first twenty minutes of every session rebuilding context that existed five hours ago.

This is the default experience of AI-assisted development. It's powerful in bursts, but it doesn't compound. Each session is an island. Progress resets. Decisions get re-litigated. Work gets duplicated.

GSD - Get Stuff Done - exists to fix this. It's a workflow framework for Claude Code that replaces ad-hoc sessions with structured, persistent execution. The context you build doesn't disappear. The decisions you make get recorded. The work you complete gets tracked. Every session picks up exactly where the last one left off.

What GSD Actually Does

At its core, GSD does three things:

Persistent project memory. GSD creates a .planning directory that acts as your project's brain. Your roadmap, requirements, decisions, and progress live there in plain markdown files. When a new session starts, GSD reads these files and immediately has full context. No re-explaining. No context rebuilding. The session starts productive.

Structured phases. Instead of "ask Claude to build something," GSD breaks work into numbered phases, each with a clear goal. Phase 1 might be "authentication system." Phase 2 might be "dashboard layout." Each phase goes through a defined workflow: discuss, plan, execute, verify. This structure prevents the scope drift that turns simple projects into complicated ones.

Specialized agents. Instead of one general Claude session doing everything, GSD spawns focused agents for different tasks. A Planner agent that creates detailed execution plans. An Executor agent that implements those plans with atomic commits. A Verifier agent that checks whether goals were actually achieved. Each agent does one thing well.

These three capabilities combine into something more powerful than the sum of their parts. Memory means context compounds. Structure means progress is predictable. Specialization means quality is consistent.

The Core Workflow Loop

Every phase in GSD follows the same four-step loop:

Discuss

Start by talking through the phase with /gsd:discuss-phase. This is the conversation stage - clarifying what you want, surfacing assumptions, identifying edge cases. GSD captures the discussion in a CONTEXT.md file that persists.

Why this matters: the biggest source of wasted effort in AI development is building the wrong thing. Five minutes of discussion prevents five hours of rework. The discussion stage is cheap insurance against misalignment.

Plan

Once the goal is clear, run /gsd:plan-phase to create detailed execution plans. The Planner agent reads your project context, your codebase documentation, and your discussion notes, then produces structured plans with specific tasks, specific files, specific success criteria.

Plans in GSD aren't vague outlines. They're detailed enough that the Executor can follow them without asking clarifying questions. Each task specifies what to do, which files to change, how to verify it worked, and what "done" looks like.

Execute

With an approved plan, run /gsd:execute-phase to build. The Executor agent works through the plan task by task, committing atomically after each task. This means you can see exactly what changed at each step, revert individual tasks if needed, and track progress in real time.

The Executor follows the plan. It doesn't add scope. It doesn't redesign the architecture mid-implementation. If it encounters something unexpected that requires a decision, it pauses and asks rather than guessing. This discipline is what makes execution predictable.

Verify

After execution, run /gsd:verify-work to check the results. The Verifier agent doesn't just confirm that tasks were completed - it checks whether the phase goal was actually achieved. There's a critical difference: a task can be "done" while the goal remains unmet if the implementation is shallow or the integration is broken.

The Verifier produces a report with specific findings. If it finds gaps, those gaps feed directly back into the planning stage for targeted fixes. The loop continues until verification passes.

The File Structure

GSD organizes everything in your .planning directory:

Everything is markdown. Everything is human-readable. You can open any file and understand what happened, what decisions were made, and why. This isn't just for GSD's internal use - it's a project history that's useful to you, to collaborators, and to future Claude sessions.

The STATE.md file is particularly important. It tracks exactly where you are: which phase, which plan, which task, what the last action was. When you start a new session, GSD reads STATE.md and knows precisely where to resume. No "where were we?" No lost progress.

Smart Agents and Model Profiles

GSD's agents are specialized Claude instances. Each one has a specific role, specific tools, and specific instructions that focus its capabilities:

The Planner creates execution plans. It reads your project context, researches your codebase, and produces structured plans with tasks, verification criteria, and success conditions.

The Researcher gathers domain knowledge before planning. For unfamiliar domains - a new API, a complex library, a specialized algorithm - research before planning prevents expensive wrong turns.

The Executor implements plans. It follows tasks in order, commits atomically, and handles minor deviations automatically while surfacing major decisions to you.

The Verifier checks goal achievement. It derives what must be true for a phase goal to be met, then checks the actual codebase against those truths.

The Codebase Mapper analyzes your project's stack, architecture, conventions, and technical debt. Its output feeds the Planner and Executor, ensuring they write code that matches your project's patterns.

You control the quality-cost balance with model profiles:

Quality mode uses the most capable model for every agent. Maximum precision, higher cost. Use this for complex or critical work.

Balanced mode uses the most capable model for planning and verification, a faster model for execution. Good default for most work.

Budget mode optimizes for speed and cost. Use for straightforward work where the risk of rework is low.

Switch profiles anytime with /gsd:set-profile. The workflow stays the same - only the underlying model changes.

A Real Workflow

Here's what using GSD looks like from start to finish:

Start a new project:

bash

/gsd:new-project

GSD asks about your vision, generates a roadmap with phases, and creates the project memory structure. This takes a few minutes but saves hours of disorganized work later.

Plan your first phase:

bash

/gsd:plan-phase 1

The Planner reads your roadmap, researches your codebase, and produces detailed execution plans. Review the plans, suggest changes, approve when ready.

Execute the phase:

bash

/gsd:execute-phase 1

The Executor works through each plan, task by task. You'll see atomic commits appear as work progresses. If decisions are needed, you'll get a clear checkpoint with options.

Verify the results:

bash

/gsd:verify-work 1

The Verifier checks that the phase goal was actually achieved. If gaps exist, plan and execute targeted fixes, then verify again.

Continue to the next phase:

bash

/gsd:progress

GSD shows your current position and routes you to the next action. The loop repeats for each phase until your milestone is complete.

Why Structure Beats Speed

The instinct with AI coding is to go fast. Skip the planning. Skip the verification. Just start building and fix problems as they appear.

This works for trivial tasks. For anything substantial, it's a trap. The problems you skip past don't disappear - they accumulate. By the time you notice them, they're entangled with everything else you've built. Fixing them means reworking code that was built on broken assumptions.

GSD's structure isn't about slowing down. It's about building at a pace you can sustain. Each phase is fully planned, fully executed, and fully verified before you move on. Nothing is half-done. Nothing is "I'll fix that later." The discipline of finishing each phase completely means you never inherit debt from previous phases.

The result is a project that stays clean, stays organized, and stays on track. Every session is productive because context is preserved. Every phase is solid because verification is built in. Every decision is traceable because the planning infrastructure captures it.

Stop losing context. Start shipping code. Run /gsd:new-project and see the difference.

Related

For the full guide to each GSD agent - invocations, output formats, and usage patterns - see Working with GSD Agents.

For the process infrastructure philosophy behind structured AI development, see ClaudeOps Process Infrastructure Strategy.