---

What's Different from GSD

GSD-Teams extends the original Get Shit Done framework with team collaboration support. Solo projects continue working unchanged.

$3

Original GSD tracks everything in git — including STATE.md which stores your current position, decisions, and session info. When two developers work on the same project:

- Developer A is on Phase 3, Task 2
- Developer B pulls, sees A's position, gets confused
- Both commit STATE.md changes — merge conflicts
- Session state bleeds between developers

$3

GSD-Teams splits state into shared (git-tracked) and ephemeral (gitignored):

| What | Solo Project | Team Project |
|------|--------------|--------------|
| PLAN.md, SUMMARY.md | Git-tracked | Git-tracked |
| STATE.md | Git-tracked | Gitignored |
| sessions/{user}/ | Created locally | Created locally |

Each developer gets isolated session tracking while sharing the actual work artifacts.

$3

| Feature | What it does |
|---------|--------------|
| User Identity | Auto-detects developer via git user.name |
| Session Directories | .planning/sessions/{user}/ for per-developer state |
| Session Hydration | Rebuilds task progress when resuming work |
| Branch Namespacing | gsd/v{version}-{feature-slug} for milestone isolation |
| Squash Merge | Clean history without GSD micro-commits in main |

$3

Existing solo GSD projects work unchanged:
- No migration required
- STATE.md continues working as before
- Team features are opt-in via .planning/.gitignore

---

Why GSD Exists

GSD is the context engineering layer that makes Claude Code reliable at scale. Describe your idea, let the system extract everything it needs to know, and let Claude Code get to work.

No enterprise roleplay. Just an incredibly effective system for building cool stuff consistently.

GSD-Teams adds the missing piece: multiple developers can use GSD on the same project without conflicts.

---

Who This Is For

- Teams using Claude Code on shared projects
- Solo developers who want team-ready workflows from the start
- Anyone who wants to describe what they want and have it built correctly

---

Getting Started

``bash
npx gsd-teams
`

The installer prompts you to choose:
1. Runtime — Claude Code, OpenCode, Gemini, or all
2. Location — Global (all projects) or local (current project only)

Verify with /gsd:help inside your chosen runtime.

$3

GSD evolves fast. Update periodically:

`bash
npx gsd-teams@latest
`

Non-interactive Install (Docker, CI, Scripts)

`bash


Claude Code

npx gsd-teams --claude --global # Install to ~/.claude/
npx gsd-teams --claude --local # Install to ./.claude/

OpenCode (open source, free models)

npx gsd-teams --opencode --global # Install to ~/.config/opencode/

Gemini CLI

npx gsd-teams --gemini --global # Install to ~/.gemini/

All runtimes

npx gsd-teams --all --global # Install to all directories
`

Use --global (-g) or --local (-l) to skip the location prompt.
Use --claude, --opencode, --gemini, or --all to skip the runtime prompt.

Development Installation

Clone the repository and run the installer locally:

`bash
git clone https://github.com/glittercowboy/get-shit-done.git
cd get-shit-done
node bin/install.js --claude --local
`

Installs to ./.claude/ for testing modifications before contributing.

$3

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.

$3

`
/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/

---

$3

`
/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}-CONTEXT.md

---

$3

`
/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}-RESEARCH.md, {phase}-{N}-PLAN.md

---

$3

`
/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.

Creates: {phase}-{N}-SUMMARY.md, {phase}-VERIFICATION.md

---

$3

`
/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}-UAT.md, fix plans if issues found

---

$3

`
/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.

---

$3

`
/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

---

Team Workflows

GSD-Teams adds workflows for multi-developer collaboration.

$3

Each developer gets isolated session state via git user.name:

`bash


Developer "alice" runs execute-plan

Creates: .planning/sessions/alice/current-plan.md

Developer "bob" runs execute-plan

Creates: .planning/sessions/bob/current-plan.md

`

Sessions are gitignored — no conflicts, no confusion.

$3

For team projects, use milestone-level branches:

`bash


Start milestone on feature branch

git checkout -b gsd/v1.0-user-auth

All GSD work happens here

/gsd:plan-phase 1
/gsd:execute-plan
...

Complete milestone with squash merge

/gsd:complete-milestone

→ Offers: squash merge (recommended) or merge with history

`

Squash merge keeps main history clean — one commit per milestone instead of dozens of GSD micro-commits.

$3

When returning to a project:

`
/gsd:resume-work
`

The system:
1. Detects your user identity
2. Finds your session state (if any)
3. Hydrates task progress from persistent PLAN.md files
4. Shows where you left off

Works whether you're the only developer or one of many.

$3

| Workflow | Solo | Team |
|----------|------|------|
| /gsd:new-project | STATE.md tracked | STATE.md gitignored |
| /gsd:execute-plan | Same | Creates session directory |
| /gsd:progress | Shows position | Shows position + session info |
| /gsd:complete-milestone | Tags release | Offers squash merge |

The core workflow is identical. Team features activate automatically when .planning/.gitignore exists.

---

Why It Works

$3

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 — per-developer in team mode |
| PLAN.md | Atomic task with XML structure, verification steps |
| SUMMARY.md | What happened, what changed, committed to history |
| sessions/{user}/ | Per-developer session state (gitignored) |
| todos/ | Captured ideas and tasks for later work |

Size limits based on where Claude's quality degrades. Stay under, get consistent excellence.

$3

Every plan is structured XML optimized for Claude:

`xml

Create login endpoint
src/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-Cookie
Valid credentials return cookie, invalid return 401

`

Precise instructions. No guessing. Verification built in.

$3

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.

$3

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.

$3

- 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

$3

| Command | What it does |
|---------|--------------|
| /gsd:new-project | Full initialization: questions → research → requirements → roadmap |
| /gsd:discuss-phase [N] | Capture implementation decisions before planning |
| /gsd:plan-phase [N] | 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 |

$3

| 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 |

$3

| Command | What it does |
|---------|--------------|
| /gsd:map-codebase | Analyze existing codebase before new-project |

$3

| 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 |

$3

| Command | What it does |
|---------|--------------|
| /gsd:pause-work | Create handoff when stopping mid-phase |
| /gsd:resume-work | Restore from last session |

$3

| Command | What it does |
|---------|--------------|
| /gsd:settings | Configure workflow agents |
| /gsd:add-todo [desc] | Capture idea for later |
| /gsd:check-todos | List pending todos |
| /gsd:debug [desc] | Systematic debugging with persistent state |
| /gsd:quick | Execute ad-hoc task with GSD guarantees |

^{¹ 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.

$3

| 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) |

$3

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 |

Use /gsd:settings to toggle these, or override per-invocation:
- /gsd:plan-phase --skip-research
- /gsd:plan-phase --skip-verify

$3

| Setting | Default | What it controls |
|---------|---------|------------------|
| parallelization.enabled | true | Run independent plans simultaneously |
| planning.commit_docs | true | Track .planning/ in git |

$3

Control how GSD handles branches during execution.

| Setting | Options | Default | What it does |
|---------|---------|---------|--------------|
| git.branching_strategy | none, phase, milestone | none | Branch creation strategy |
| git.phase_branch_template | string | gsd/phase-{phase}-{slug} | Template for phase branches |
| git.milestone_branch_template | string | gsd/{milestone}-{slug} | Template for milestone branches |

Strategies:
- none — Commits to current branch (default GSD behavior)
- phase — Creates a branch per phase, merges at phase completion
- milestone — Creates one branch for entire milestone, merges at completion

At milestone completion, GSD offers squash merge (recommended) or merge with history.

---

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 gsd-teams to reinstall

Updating to the latest version?
`bash
npx gsd-teams@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 gsd-teams --global
`
This ensures absolute paths are used instead of ~ which may not expand correctly in containers.

$3

To remove GSD completely:

`bash


Global installs

npx gsd-teams --claude --global --uninstall
npx gsd-teams --opencode --global --uninstall

Local installs (current project)

npx gsd-teams --claude --local --uninstall
npx gsd-teams --opencode --local --uninstall
``

This removes all GSD commands, agents, hooks, and settings while preserving your other configurations.

---

Attribution

GSD-Teams is a fork of Get Shit Done by TÂCHES.

The original GSD is an excellent solo development framework. This fork adds team collaboration features while maintaining full backward compatibility with solo projects.

Original project: github.com/glittercowboy/get-shit-done

---

License

MIT License. See LICENSE for details.

---