# GET STUFF DONE
**A light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code.**
**Solves context rot — the quality degradation that happens as Claude fills its context window.**
[](https://www.npmjs.com/package/@chude/get-stuff-done)
[](https://www.npmjs.com/package/@chude/get-stuff-done)
[](https://github.com/chudeemeke/get-stuff-done)
[](LICENSE)
```bash
npx @chude/get-stuff-done@latest
```
**Works on Mac, Windows, and Linux.**
*"If you know clearly what you want, this WILL build it for you. No bs."*
*"I've done SpecKit, OpenSpec and Taskmaster — this has produced the best results for me."*
*"By far the most powerful addition to my Claude Code. Nothing over-engineered. Literally just gets stuff done."*
**Trusted by engineers at Amazon, Google, Shopify, and Webflow.**
[Why I Built This](#why-i-built-this) · [How It Works](#how-it-works) · [Commands](#commands) · [Why It Works](#why-it-works) · [User Guide](docs/USER-GUIDE.md)
---
## Why I Built This
I'm a solo developer. I don't write code — Claude Code does.
Other spec-driven development tools exist; BMAD, Speckit... But they all seem to make things way more complicated than they need to be (sprint ceremonies, story points, stakeholder syncs, retrospectives, Jira workflows) or lack real big picture understanding of what you're building. I'm not a 50-person software company. I don't want to play enterprise theater. I'm just a creative person trying to build great things that work.
So I built GSD. The complexity is in the system, not in your workflow. Behind the scenes: context engineering, XML prompt formatting, subagent orchestration, state management. What you see: a few commands that just work.
> **Note**: This is a fork of the original [Get Shit Done](https://github.com/glittercowboy/get-shit-done) by TACHES, rebranded and enhanced with aidev styling and long-running session support.
The system gives Claude everything it needs to do the work *and* verify it. I trust the workflow. It just does a good job.
That's what this is. No enterprise roleplay bullshit. Just an incredibly effective system for building cool stuff consistently using Claude Code.
— **TÂCHES**
---
Vibecoding has a bad reputation. You describe what you want, AI generates code, and you get inconsistent garbage that falls apart at scale.
GSD fixes that. It's the context engineering layer that makes Claude Code reliable. Describe your idea, let the system extract everything it needs to know, and let Claude Code get to work.
---
## Who This Is For
People who want to describe what they want and have it built correctly — without pretending they're running a 50-person engineering org.
---
## Workflow Philosophy
### State Lives in Files, Not Context
Traditional Claude Code usage relies on conversation context to maintain state:
```bash
claude -c # Continue previous session
# Hope context hasn't degraded
# Hope Claude remembers decisions
# Watch quality decline as context fills
```
GSD takes a different approach. **Everything lives in files:**
```bash
gsd # Always start fresh
# Say "resume" or run /gsd:progress
# Claude reads STATE.md, PLAN.md, ROADMAP.md
# Full context from files, zero rot
```
### Why This Works
| Problem | GSD Solution |
|---------|--------------|
| Context rot degrades quality | Fresh 200k tokens every session |
| Decisions get forgotten | STATE.md persists across sessions |
| Long sessions confuse models | Heavy work runs in isolated subagents |
| Manual handoffs waste tokens | "Resume" reads from files instantly |
### The Practical Impact
**You don't need `claude -c` anymore.** When you run `gsd` and say "resume":
1. Claude reads `.planning/STATE.md` for decisions and blockers
2. Claude reads `.planning/ROADMAP.md` for phase progress
3. Claude reads `.planning/PLAN.md` for current tasks
No context dependency. No quality degradation. No "where were we?"
**For details, see [QUICKSTART.md](QUICKSTART.md).**
---
## Getting Started
### Installation
1. Clone the repository:
```bash
git clone https://github.com/chudeemeke/get-stuff-done.git ~/Projects/get-stuff-done
```
2. Add the launcher to your PATH:
```bash
# Add to ~/.bashrc or ~/.zshrc
export PATH="$HOME/Projects/get-stuff-done/bin:$PATH"
```
3. Create your config (optional - defaults work fine):
```bash
mkdir -p ~/.gsd
cp ~/Projects/get-stuff-done/config/default-config.json ~/.gsd/config.json
```
4. Run GSD:
```bash
gsd
```
Verify with `/gsd:help` inside Claude Code.
### Global Usage
GSD is designed to be your default Claude Code framework across ALL projects. The `gsd` launcher:
- Sets up context management automatically
- Loads from `~/.gsd/config.json` (user-level)
- Falls back to project-level `.gsd/config.json` if present
- Works the same in any directory
Non-interactive Install (Docker, CI, Scripts)
```bash
# Claude Code
npx @chude/get-stuff-done --claude --global # Install to ~/.claude/
npx @chude/get-stuff-done --claude --local # Install to ./.claude/
# OpenCode (open source, free models)
npx @chude/get-stuff-done --opencode --global # Install to ~/.opencode/
# Both runtimes
npx @chude/get-stuff-done --both --global # Install to both directories
```
Use `--global` (`-g`) or `--local` (`-l`) to skip the location prompt.
Use `--claude`, `--opencode`, or `--both` to skip the runtime prompt.
Development Installation
Clone the repository and run the installer locally:
```bash
git clone https://github.com/chudeemeke/get-stuff-done.git
cd get-stuff-done
node bin/install.js --claude --local
```
Installs to `./.claude/` for testing modifications before contributing.
### Recommended: Skip Permissions Mode
GSD is designed for frictionless automation. Run Claude Code with:
```bash
claude --dangerously-skip-permissions
```
> [!TIP]
> This is how GSD is intended to be used — stopping to approve `date` and `git commit` 50 times defeats the purpose.
Alternative: Granular Permissions
If you prefer not to use that flag, add this to your project's `.claude/settings.json`:
```json
{
"permissions": {
"allow": [
"Bash(date:*)",
"Bash(echo:*)",
"Bash(cat:*)",
"Bash(ls:*)",
"Bash(mkdir:*)",
"Bash(wc:*)",
"Bash(head:*)",
"Bash(tail:*)",
"Bash(sort:*)",
"Bash(grep:*)",
"Bash(tr:*)",
"Bash(git add:*)",
"Bash(git commit:*)",
"Bash(git status:*)",
"Bash(git log:*)",
"Bash(git diff:*)",
"Bash(git tag:*)"
]
}
}
```
---
## How It Works
> **Already have code?** Run `/gsd:map-codebase` first. It spawns parallel agents to analyze your stack, architecture, conventions, and concerns. Then `/gsd:new-project` knows your codebase — questions focus on what you're adding, and planning automatically loads your patterns.
### 1. Initialize Project
```
/gsd:new-project
```
One command, one flow. The system:
1. **Questions** — Asks until it understands your idea completely (goals, constraints, tech preferences, edge cases)
2. **Research** — Spawns parallel agents to investigate the domain (optional but recommended)
3. **Requirements** — Extracts what's v1, v2, and out of scope
4. **Roadmap** — Creates phases mapped to requirements
You approve the roadmap. Now you're ready to build.
**Creates:** `PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md`, `.planning/research/`
---
### 2. Discuss Phase
```
/gsd:discuss-phase 1
```
**This is where you shape the implementation.**
Your roadmap has a sentence or two per phase. That's not enough context to build something the way *you* imagine it. This step captures your preferences before anything gets researched or planned.
The system analyzes the phase and identifies gray areas based on what's being built:
- **Visual features** → Layout, density, interactions, empty states
- **APIs/CLIs** → Response format, flags, error handling, verbosity
- **Content systems** → Structure, tone, depth, flow
- **Organization tasks** → Grouping criteria, naming, duplicates, exceptions
For each area you select, it asks until you're satisfied. The output — `CONTEXT.md` — feeds directly into the next two steps:
1. **Researcher reads it** — Knows what patterns to investigate ("user wants card layout" → research card component libraries)
2. **Planner reads it** — Knows what decisions are locked ("infinite scroll decided" → plan includes scroll handling)
The deeper you go here, the more the system builds what you actually want. Skip it and you get reasonable defaults. Use it and you get *your* vision.
**Creates:** `{phase_num}-CONTEXT.md`
---
### 3. Plan Phase
```
/gsd:plan-phase 1
```
The system:
1. **Researches** — Investigates how to implement this phase, guided by your CONTEXT.md decisions
2. **Plans** — Creates 2-3 atomic task plans with XML structure
3. **Verifies** — Checks plans against requirements, loops until they pass
Each plan is small enough to execute in a fresh context window. No degradation, no "I'll be more concise now."
**Creates:** `{phase_num}-RESEARCH.md`, `{phase_num}-{N}-PLAN.md`
---
### 4. Execute Phase
```
/gsd:execute-phase 1
```
The system:
1. **Runs plans in waves** — Parallel where possible, sequential when dependent
2. **Fresh context per plan** — 200k tokens purely for implementation, zero accumulated garbage
3. **Commits per task** — Every task gets its own atomic commit
4. **Verifies against goals** — Checks the codebase delivers what the phase promised
Walk away, come back to completed work with clean git history.
**How Wave Execution Works:**
Plans are grouped into "waves" based on dependencies. Within each wave, plans run in parallel. Waves run sequentially.
```
┌─────────────────────────────────────────────────────────────────────┐
│ PHASE EXECUTION │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ WAVE 1 (parallel) WAVE 2 (parallel) WAVE 3 │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Plan 01 │ │ Plan 02 │ → │ Plan 03 │ │ Plan 04 │ → │ Plan 05 │ │
│ │ │ │ │ │ │ │ │ │ │ │
│ │ User │ │ Product │ │ Orders │ │ Cart │ │ Checkout│ │
│ │ Model │ │ Model │ │ API │ │ API │ │ UI │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
│ │ │ ↑ ↑ ↑ │
│ └───────────┴──────────────┴───────────┘ │ │
│ Dependencies: Plan 03 needs Plan 01 │ │
│ Plan 04 needs Plan 02 │ │
│ Plan 05 needs Plans 03 + 04 │ │
│ │
└─────────────────────────────────────────────────────────────────────┘
```
**Why waves matter:**
- Independent plans → Same wave → Run in parallel
- Dependent plans → Later wave → Wait for dependencies
- File conflicts → Sequential plans or same plan
This is why "vertical slices" (Plan 01: User feature end-to-end) parallelize better than "horizontal layers" (Plan 01: All models, Plan 02: All APIs).
**Creates:** `{phase_num}-{N}-SUMMARY.md`, `{phase_num}-VERIFICATION.md`
---
### 5. Verify Work
```
/gsd:verify-work 1
```
**This is where you confirm it actually works.**
Automated verification checks that code exists and tests pass. But does the feature *work* the way you expected? This is your chance to use it.
The system:
1. **Extracts testable deliverables** — What you should be able to do now
2. **Walks you through one at a time** — "Can you log in with email?" Yes/no, or describe what's wrong
3. **Diagnoses failures automatically** — Spawns debug agents to find root causes
4. **Creates verified fix plans** — Ready for immediate re-execution
If everything passes, you move on. If something's broken, you don't manually debug — you just run `/gsd:execute-phase` again with the fix plans it created.
**Creates:** `{phase_num}-UAT.md`, fix plans if issues found
---
### 6. Repeat → Complete → Next Milestone
```
/gsd:discuss-phase 2
/gsd:plan-phase 2
/gsd:execute-phase 2
/gsd:verify-work 2
...
/gsd:complete-milestone
/gsd:new-milestone
```
Loop **discuss → plan → execute → verify** until milestone complete.
Each phase gets your input (discuss), proper research (plan), clean execution (execute), and human verification (verify). Context stays fresh. Quality stays high.
When all phases are done, `/gsd:complete-milestone` archives the milestone and tags the release.
Then `/gsd:new-milestone` starts the next version — same flow as `new-project` but for your existing codebase. You describe what you want to build next, the system researches the domain, you scope requirements, and it creates a fresh roadmap. Each milestone is a clean cycle: define → build → ship.
---
### Quick Mode
```
/gsd:quick
```
**For ad-hoc tasks that don't need full planning.**
Quick mode gives you GSD guarantees (atomic commits, state tracking) with a faster path:
- **Same agents** — Planner + executor, same quality
- **Skips optional steps** — No research, no plan checker, no verifier
- **Separate tracking** — Lives in `.planning/quick/`, not phases
Use for: bug fixes, small features, config changes, one-off tasks.
```
/gsd:quick
> What do you want to do? "Add dark mode toggle to settings"
```
**Creates:** `.planning/quick/001-add-dark-mode-toggle/PLAN.md`, `SUMMARY.md`
---
## Why It Works
### Context Engineering
Claude Code is incredibly powerful *if* you give it the context it needs. Most people don't.
GSD handles it for you:
| File | What it does |
|------|--------------|
| `PROJECT.md` | Project vision, always loaded |
| `research/` | Ecosystem knowledge (stack, features, architecture, pitfalls) |
| `REQUIREMENTS.md` | Scoped v1/v2 requirements with phase traceability |
| `ROADMAP.md` | Where you're going, what's done |
| `STATE.md` | Decisions, blockers, position — memory across sessions |
| `PLAN.md` | Atomic task with XML structure, verification steps |
| `SUMMARY.md` | What happened, what changed, committed to history |
| `todos/` | Captured ideas and tasks for later work |
Size limits based on where Claude's quality degrades. Stay under, get consistent excellence.
### XML Prompt Formatting
Every plan is structured XML optimized for Claude:
```xml
Create login endpointsrc/app/api/auth/login/route.ts
Use jose for JWT (not jsonwebtoken - CommonJS issues).
Validate credentials against users table.
Return httpOnly cookie on success.
curl -X POST localhost:3000/api/auth/login returns 200 + Set-CookieValid credentials return cookie, invalid return 401
```
Precise instructions. No guessing. Verification built in.
### Multi-Agent Orchestration
Every stage uses the same pattern: a thin orchestrator spawns specialized agents, collects results, and routes to the next step.
| Stage | Orchestrator does | Agents do |
|-------|------------------|-----------|
| Research | Coordinates, presents findings | 4 parallel researchers investigate stack, features, architecture, pitfalls |
| Planning | Validates, manages iteration | Planner creates plans, checker verifies, loop until pass |
| Execution | Groups into waves, tracks progress | Executors implement in parallel, each with fresh 200k context |
| Verification | Presents results, routes next | Verifier checks codebase against goals, debuggers diagnose failures |
The orchestrator never does heavy lifting. It spawns agents, waits, integrates results.
**The result:** You can run an entire phase — deep research, multiple plans created and verified, thousands of lines of code written across parallel executors, automated verification against goals — and your main context window stays at 30-40%. The work happens in fresh subagent contexts. Your session stays fast and responsive.
### Atomic Git Commits
Each task gets its own commit immediately after completion:
```bash
abc123f docs(08-02): complete user registration plan
def456g feat(08-02): add email confirmation flow
hij789k feat(08-02): implement password hashing
lmn012o feat(08-02): create registration endpoint
```
> [!NOTE]
> **Benefits:** Git bisect finds exact failing task. Each task independently revertable. Clear history for Claude in future sessions. Better observability in AI-automated workflow.
Every commit is surgical, traceable, and meaningful.
### Modular by Design
- Add phases to current milestone
- Insert urgent work between phases
- Complete milestones and start fresh
- Adjust plans without rebuilding everything
You're never locked in. The system adapts.
---
## Commands
### Core Workflow
| Command | What it does |
|---------|--------------|
| `/gsd:new-project [--auto]` | Full initialization: questions → research → requirements → roadmap |
| `/gsd:discuss-phase [N] [--auto]` | Capture implementation decisions before planning |
| `/gsd:plan-phase [N] [--auto]` | Research + plan + verify for a phase |
| `/gsd:execute-phase ` | Execute all plans in parallel waves, verify when complete |
| `/gsd:verify-work [N]` | Manual user acceptance testing ¹ |
| `/gsd:audit-milestone` | Verify milestone achieved its definition of done |
| `/gsd:complete-milestone` | Archive milestone, tag release |
| `/gsd:new-milestone [name]` | Start next version: questions → research → requirements → roadmap |
### Navigation
| Command | What it does |
|---------|--------------|
| `/gsd:progress` | Where am I? What's next? |
| `/gsd:help` | Show all commands and usage guide |
| `/gsd:update` | Update GSD with changelog preview |
| `/gsd:join-discord` | Join the GSD Discord community |
### Brownfield
| Command | What it does |
|---------|--------------|
| `/gsd:map-codebase` | Analyze existing codebase before new-project |
### Phase Management
| Command | What it does |
|---------|--------------|
| `/gsd:add-phase` | Append phase to roadmap |
| `/gsd:insert-phase [N]` | Insert urgent work between phases |
| `/gsd:remove-phase [N]` | Remove future phase, renumber |
| `/gsd:list-phase-assumptions [N]` | See Claude's intended approach before planning |
| `/gsd:plan-milestone-gaps` | Create phases to close gaps from audit |
### Session
| Command | What it does |
|---------|--------------|
| `/gsd:pause-work` | Create handoff when stopping mid-phase |
| `/gsd:resume-work` | Restore from last session |
### Utilities
| Command | What it does |
|---------|--------------|
| `/gsd:settings` | Configure model profile and workflow agents |
| `/gsd:set-profile ` | Switch model profile (quality/balanced/budget) |
| `/gsd:add-todo [desc]` | Capture idea for later |
| `/gsd:check-todos` | List pending todos |
| `/gsd:debug [desc]` | Systematic debugging with persistent state |
| `/gsd:quick [--full]` | Execute ad-hoc task with GSD guarantees (`--full` adds plan-checking and verification) |
| `/gsd:health [--repair]` | Validate `.planning/` directory integrity, auto-repair with `--repair` |
¹ Contributed by reddit user OracleGreyBeard
---
## Configuration
GSD stores project settings in `.planning/config.json`. Configure during `/gsd:new-project` or update later with `/gsd:settings`. For the full config schema, workflow toggles, git branching options, and per-agent model breakdown, see the [User Guide](docs/USER-GUIDE.md#configuration-reference).
### Core Settings
| Setting | Options | Default | What it controls |
|---------|---------|---------|------------------|
| `mode` | `yolo`, `interactive` | `interactive` | Auto-approve vs confirm at each step |
| `depth` | `quick`, `standard`, `comprehensive` | `standard` | Planning thoroughness (phases × plans) |
### Model Profiles
Control which Claude model each agent uses. Balance quality vs token spend.
| Profile | Planning | Execution | Verification |
|---------|----------|-----------|--------------|
| `quality` | Opus | Opus | Sonnet |
| `balanced` (default) | Opus | Sonnet | Sonnet |
| `budget` | Sonnet | Sonnet | Haiku |
Switch profiles:
```
/gsd:set-profile budget
```
Or configure via `/gsd:settings`.
### Workflow Agents
These spawn additional agents during planning/execution. They improve quality but add tokens and time.
| Setting | Default | What it does |
|---------|---------|--------------|
| `workflow.research` | `true` | Researches domain before planning each phase |
| `workflow.plan_check` | `true` | Verifies plans achieve phase goals before execution |
| `workflow.verifier` | `true` | Confirms must-haves were delivered after execution |
| `workflow.auto_advance` | `false` | Auto-chain discuss → plan → execute without stopping |
Use `/gsd:settings` to toggle these, or override per-invocation:
- `/gsd:plan-phase --skip-research`
- `/gsd:plan-phase --skip-verify`
### Execution
| Setting | Default | What it controls |
|---------|---------|------------------|
| `parallelization.enabled` | `true` | Run independent plans simultaneously |
| `planning.commit_docs` | `true` | Track `.planning/` in git |
---
## Context Management
GSD uses **early auto-compaction** to prevent context rot while maintaining long-running sessions. This hybrid approach combines the best of both worlds:
- **GSD's philosophy**: State lives in files, not context
- **Long-running benefit**: Fewer reloads, smoother workflow
- **Rot prevention**: Auto-clear before degradation, not after
### How It Works
```
User working in session
│
▼
Context reaches threshold (default 50%)
│
▼
PreCompact hook saves state to files
│
▼
Compaction clears context
│
▼
Claude reloads from STATE.md, continues seamlessly
```
### Configuration
Configure via `~/.gsd/config.json`:
```json
{
"context_management": {
"precompact_save_state": true
}
}
```
| Setting | Default | Description |
|---------|---------|-------------|
| `precompact_save_state` | `true` | Save state before compaction |
### Autocompact Threshold
Autocompact is controlled by Claude Code internally. The GSD statusline shows your proximity to autocompact using Claude Code's own reporting.
Note: `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE` env var exists but has a [known bug](https://github.com/anthropics/claude-code/issues/18843) where it's ignored.
### PreCompact Hook
When compaction triggers, the hook:
1. Saves current state snapshot to `STATE.md`
2. Creates `CONTINUE.md` with resume instructions
3. Logs event to `events.log`
This ensures seamless resumption after context clears.
### Subagent Architecture
Heavy work runs in subagents with isolated 200k contexts:
- **gsd-executor**: Task execution (fresh context per task)
- **gsd-verifier**: Phase verification
- **gsd-researcher**: Research operations
The orchestrator stays lean (~30% context), dispatching work to subagents. Their results return as summaries, keeping the main context clean.
---
## Troubleshooting
**Commands not found after install?**
- Restart Claude Code to reload slash commands
- Verify files exist in `~/.claude/commands/gsd/` (global) or `./.claude/commands/gsd/` (local)
**Commands not working as expected?**
- Run `/gsd:help` to verify installation
- Re-run `npx @chude/get-stuff-done` to reinstall
**Updating to the latest version?**
```bash
npx @chude/get-stuff-done@latest
```
**Using Docker or containerized environments?**
If file reads fail with tilde paths (`~/.claude/...`), set `CLAUDE_CONFIG_DIR` before installing:
```bash
CLAUDE_CONFIG_DIR=/home/youruser/.claude npx @chude/get-stuff-done --global
```
This ensures absolute paths are used instead of `~` which may not expand correctly in containers.
### Uninstalling
To remove GSD completely:
```bash
# Global installs
npx @chude/get-stuff-done@latest --claude --global --uninstall
npx @chude/get-stuff-done@latest --opencode --global --uninstall
npx @chude/get-stuff-done@latest --gemini --global --uninstall
# Local installs (current project)
npx @chude/get-stuff-done@latest --claude --local --uninstall
npx @chude/get-stuff-done@latest --opencode --local --uninstall
npx @chude/get-stuff-done@latest --gemini --local --uninstall
```
This removes all GSD commands, agents, hooks, and settings while preserving your other configurations.
---
## Community Ports
| Project | Platform | Description |
|---------|----------|-------------|
| [gsd-opencode](https://github.com/rokicool/gsd-opencode) | OpenCode | GSD adapted for OpenCode CLI |
| [gsd-gemini](https://github.com/uberfuzzy/gsd-gemini) | Gemini CLI | GSD adapted for Google's Gemini CLI |
---
## Star History (Upstream)
*Star history from the original [Get Shit Done](https://github.com/glittercowboy/get-shit-done) repository.*
---
## License
MIT License. See [LICENSE](LICENSE) for details.
---
**Claude Code is powerful. GSD makes it reliable.**
*Forked from [Get Shit Done](https://github.com/glittercowboy/get-shit-done) by TACHES. MIT Licensed.*