A practical step-by-step guide for solo developers on using GSD (Get Shit Done) with Claude Code — covering context rot, wave execution, and the full workflow from new-project to ship.

If you're a solo developer who codes with AI — you've probably hit this wall. You open Claude Code, start describing your feature, write some code, ask for fixes, write more code… and somewhere around message 30, the AI starts forgetting things. It re-introduces bugs you already fixed. It contradicts decisions it made earlier. The responses get shorter, sloppier. You're fighting the tool as much as using it.

This is context rot — and it's the silent killer of AI-assisted solo development.

GSD (Get Shit Done) is an open-source meta-prompting and context engineering system built specifically for Claude Code that solves this problem systematically. This guide walks you through the full workflow using a real project: ginbok.com — a bilingual technical blog built on Next.js 14 (frontend) and Episerver Optimizely CMS 12 (backend), developed and maintained entirely by one person.

The Problem: Context Rot

Claude Code has a 200,000-token context window. That sounds enormous — and it is. But as a session grows, something subtle happens. Every message, every code block, every back-and-forth narrows the "working memory" Claude can actually use effectively. By the time you've had 40 exchanges, the early decisions — your architecture choices, your naming conventions, the bug you fixed in hour one — have drifted to the bottom of the context stack. Claude still technically "sees" them, but the quality of reasoning degrades.

Researchers call this lost-in-the-middle: LLMs are better at recalling things from the beginning and end of context, and worse at the middle. A long coding session is mostly middle.

For ginbok.com, this was a real problem. The project has two moving parts — a Next.js frontend deployed on Vercel and an Optimizely CMS backend hosted at api.ginbok.com — plus a custom MCP server called ginbok-mcp for CMS management. A single coding session might touch API routes, CMS content models, Azure DevOps pipeline config, and Vercel environment variables. Without structure, context collapses fast.

GSD's solution is elegant: never let important context drift into the middle. Instead, every piece of work happens in a fresh sub-agent context with only the relevant information loaded. Your main session stays light. The sub-agents do the heavy lifting.

Step 0: Install GSD

Prerequisites: Node.js 18+, Claude Code CLI, Git.

# Navigate to your project root
cd ginbok-frontend

# Install GSD locally
npx get-shit-done-cc@latest

The installer asks two questions:

Runtime → choose Claude Code
Location → choose Local (installs to ./.claude/commands/gsd/)

Launch Claude Code:

claude --dangerously-skip-permissions

The --dangerously-skip-permissions flag lets GSD run bash commands (git commits, file creation) without stopping to ask you every time. This is intentional — GSD is designed to run autonomously. If you prefer granular control, add specific allow rules to .claude/settings.json instead.

Verify everything is working:

/gsd:help

You should see the full command list. If not, restart Claude Code to reload the commands.

Step 1: Map Your Existing Codebase

ginbok.com is a brownfield project — it already has code, conventions, and a deployment pipeline. Before initializing, tell GSD what it's working with:

/gsd:map-codebase

This spawns parallel agents that analyze your stack, architecture, naming conventions, and any existing quirks. For ginbok.com the analysis would surface things like:

Next.js App Router with TypeScript
Episerver content API at api.ginbok.com with JWT auth
Custom ginbok-mcp MCP server for CMS operations
Azure DevOps CI/CD pipeline deploying to Vercel
Bilingual content (EN/VI) with separate language branches in the CMS

This codebase map is stored and referenced in every subsequent planning and execution step. The planner won't suggest Redux if it sees you're using Zustand. It won't propose a new API layer if it sees your MCP server already handles CMS operations.

Then initialize:

/gsd:new-project

GSD interviews you about what you want to build next — not about what already exists, because it already knows. For ginbok.com, you might describe:

"I want to add a reading time estimate to every blog post, displayed next to the publish date. Calculate it from the post body word count. Display format: '5 min read'. No backend changes needed — the body HTML already comes from the CMS API."

GSD produces:

PROJECT.md — project vision, stack summary, always loaded
REQUIREMENTS.md — scoped v1/v2 requirements
ROADMAP.md — phases
STATE.md — decisions and current position, persists across sessions

How Phases Work: One Phase ≠ One Feature

A common misconception: phases map 1-to-1 with features. They don't. A phase is a unit of shippable work — it can be large or small depending on scope.

Project
├── Phase 1: Authentication
│   ├── Wave 1: DB schema + middleware
│   └── Wave 2: Login UI + API routes
├── Phase 2: Blog Reading Time        ← one small feature = one phase
│   ├── Wave 1: readingTime utility
│   └── Wave 2: PostCard + PostHeader
└── Phase 3: SEO & Sitemap Fixes      ← bundle small fixes into one phase

The rule of thumb:

Large or complex requirement → one phase with multiple waves (e.g. "build OAuth login")
Medium-sized feature → one focused phase (e.g. "add reading time estimate")
Small fixes or tweaks → skip phases entirely, use /gsd:quick

GSD determines this granularity automatically when you run /gsd:new-project or /gsd:discuss-phase — it splits the roadmap into phases based on your description. You don't manually assign phase numbers. They appear in ROADMAP.md after the first planning step.

Step 2: Discuss the Phase (Shape Before You Build)

/gsd:discuss-phase 1

This step is what separates GSD from naive "just generate the code" approaches. Before any planning happens, GSD identifies the gray areas in your phase — the decisions that seem minor but affect everything downstream.

For the reading time feature on ginbok.com, it might surface:

Should the calculation strip HTML tags before counting words, or use a library?
What's the assumed reading speed (200 wpm? 250 wpm)?
Should "1 min read" or "less than 1 min" display for very short posts?
Where exactly in the UI does it appear — post card, post header, or both?
Does it need to be bilingual (Vietnamese posts read differently than English)?

You answer these once, here. The answers go into 1-CONTEXT.md. Every subsequent step reads this file. You never re-explain these decisions.

❌ Without discuss: the executor implements reading time in the post header only, you realize it should also be in the post card, and now you're mid-session explaining the UI structure from scratch.

✅ With discuss: "post card AND post header" is locked in before a single line is planned.

Step 3: Plan the Phase

/gsd:plan-phase 1

The planner reads your codebase map, CONTEXT.md, and REQUIREMENTS.md, then creates atomic task plans. Each plan is small enough to execute in a single fresh context window.

For the reading time feature, the plans might be:

1-01-PLAN.md — Reading time utility function (lib/utils/readingTime.ts)
1-02-PLAN.md — Integrate into PostCard component
1-03-PLAN.md — Integrate into PostHeader component + bilingual label

Each plan is structured XML:

<task type="auto">
  <n>Create readingTime utility</n>
  <files>lib/utils/readingTime.ts</files>
  <action>
    Strip HTML tags from body string.
    Count words (split on whitespace).
    Divide by 238 wpm (average silent reading speed).
    Return ceiling. Minimum return value: 1.
    Export: readingTime(html: string): number
  </action>
  <verify>Unit test: 476-word body returns 2, 50-word body returns 1</verify>
  <done>Function exported from lib/utils/readingTime.ts, tests pass</done>
</task>

Precise. No ambiguity. Verification built in. A plan checker agent validates each plan against requirements before you ever see them.

Step 4: Execute — Where Wave Execution Shines

/gsd:execute-phase 1

This is GSD's most technically interesting step. The executor reads your plans, groups them into waves based on dependencies, and runs each wave:

Plans in the same wave run in parallel (independent work)
Plans in later waves wait for their dependencies

For the ginbok.com reading time feature:

Wave 1 (parallel):
  └── 1-01: readingTime utility    (no dependencies)

Wave 2 (parallel):
  ├── 1-02: PostCard integration   (depends on 1-01)
  └── 1-03: PostHeader + i18n      (depends on 1-01)

The key insight: each executor sub-agent gets its own fresh 200k token context. It loads the specific plan, the project context, and only the files it needs to touch. No accumulated conversation history. No context rot.

Your main session context stays at 30–40% while the sub-agents work. You can open another terminal, grab coffee, or start reviewing the previous phase's output.

After execution, every completed task gets its own atomic git commit:

a1b2c3 feat(1-01): add readingTime utility with HTML stripping
d4e5f6 feat(1-02): integrate reading time into PostCard
g7h8i9 feat(1-03): add reading time to PostHeader with EN/VI label

Each commit is independently revertable. If the PostHeader integration has a layout issue, you revert just that commit — the utility and PostCard stay intact.

Step 5: Verify — Human + AI in the Loop

/gsd:verify-work 1

GSD walks you through the actual deliverables one by one:

"Does the post card on the homepage show a reading time estimate next to the publish date?"

"On a Vietnamese post, does the label appear in Vietnamese ('5 phút đọc' instead of '5 min read')?"

You test it in the browser. Yes or no. If something's broken, describe what's wrong — GSD spawns a debug agent, diagnoses the root cause, and creates a fix plan ready for re-execution. No manual debugging.

Step 6: Ship

/gsd:ship 1

Creates a pull request with an auto-generated body summarizing what was built. The Azure DevOps pipeline picks it up, runs the build, and deploys to Vercel on merge.

Then repeat for the next feature. Or let GSD figure out what's next:

/gsd:next

Quick Mode: For Ad-Hoc Tasks

Not every ginbok.com change needs the full ceremony. Fixing a broken sitemap, tweaking a CSS variable, updating an MCP tool — these are one-off tasks:

/gsd:quick
> What do you want to do? "Fix the double-path resolution bug in next.config.js rootDirectory"

GSD creates a lightweight plan in .planning/quick/ and executes it with the same guarantees — fresh context, atomic commit — without the full discuss/plan/verify cycle. For solo devs maintaining a live site, this is the mode you'll use most often for maintenance work.

The Mental Model: Why This Works

Most AI coding tools fail at scale because they treat the conversation as the workspace. GSD treats the files as the workspace and the conversation as a thin control layer on top.

Every important piece of context lives in a file: PROJECT.md, REQUIREMENTS.md, 1-CONTEXT.md, 1-01-PLAN.md. Sub-agents load exactly what they need. Nothing accumulates in the main context. The codebase map means GSD already understands your stack before you type a single command.

For ginbok.com — a real bilingual site with a custom CMS, a CI/CD pipeline, and an MCP server — this structure is what makes AI-assisted development sustainable over months, not just for one session.

Getting Started Today

# Existing project
cd your-project
npx get-shit-done-cc@latest
claude --dangerously-skip-permissions
/gsd:map-codebase
/gsd:new-project

# New project
mkdir my-project && cd my-project && git init
npx get-shit-done-cc@latest
claude --dangerously-skip-permissions
/gsd:new-project

The repo is at github.com/gsd-build/get-shit-done — MIT licensed, 39k stars, actively maintained.

Stop fighting your context window. Let GSD manage it for you.