Imported from AlexandreBanhos/faceglow-project (customize/skills/get-shit-done/SKILL.md). Install upstream with npx skills add AlexandreBanhos/faceglow-project --skill get-shit-done. Copyright stays with the author.

GET SHIT DONE

English · Português · 简体中文 · 日本語 · 한국어

A light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code, OpenCode, Gemini CLI, Kilo, Codex, Copilot, Cursor, Windsurf, Antigravity, Augment, Trae, and Cline.

Solves context rot — the quality degradation that happens as Claude fills its context window.

npm version npm downloads Tests Discord X (Twitter) $GSD Token GitHub stars License

npx get-shit-done-cc@latest

Works on Mac, Windows, and Linux.

GSD Install

"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 shit done."

Trusted by engineers at Amazon, Google, Shopify, and Webflow.

Why I Built This · How It Works · Commands · Why It Works · User Guide

[!IMPORTANT]

Welcome Back to GSD

If you're returning to GSD after the recent Anthropic Terms of Service changes — welcome back. We kept building while you were gone.

To re-import an existing project into GSD:

1. Run /gsd-map-codebase to scan and index your current codebase state
2. Run /gsd-new-project to initialize a fresh GSD planning structure using the codebase map as context
3. Review docs/USER-GUIDE.md and the CHANGELOG for updates — a lot has changed since you were last here

Your code is fine. GSD just needs its planning context rebuilt. The two commands above handle that.

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.

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.

Built-in quality gates catch real problems: schema drift detection flags ORM changes missing migrations, security enforcement anchors verification to threat models, and scope reduction detection prevents the planner from silently dropping your requirements.

v1.34.0 Highlights

• Gates taxonomy — 4 canonical gate types (pre-flight, revision, escalation, abort) wired into plan-checker and verifier agents
• Shell hooks fix — hooks/*.sh files are now correctly included in the npm package, eliminating startup hook errors on fresh installs
• Post-merge hunk verification — reapply-patches detects silently dropped hunks after three-way merge
• detectConfigDir fix — Claude Code users no longer see false "update available" warnings when multiple runtimes are installed
• 3 bug fixes — Milestone backlog preservation, detectConfigDir priority, and npm package manifest

Getting Started

npx get-shit-done-cc@latest

The installer prompts you to choose:

1. Runtime — Claude Code, OpenCode, Gemini, Kilo, Codex, Copilot, Cursor, Windsurf, Antigravity, Augment, Trae, Cline, or all (interactive multi-select — pick multiple runtimes in a single install session)
2. Location — Global (all projects) or local (current project only)

Verify with:

• Claude Code / Gemini / Copilot / Antigravity: /gsd-help
• OpenCode / Kilo / Augment / Trae: /gsd-help
• Codex: $gsd-help
• Cline: GSD installs via .clinerules — verify by checking .clinerules exists

[!NOTE] Claude Code 2.1.88+ and Codex install as skills (skills/gsd-*/SKILL.md). Older Claude Code versions use commands/gsd/. Cline uses .clinerules for configuration. The installer handles all formats automatically.

[!TIP] For source-based installs or environments where npm is unavailable, see docs/manual-update.md.

Staying Updated

GSD evolves fast. Update periodically:

npx get-shit-done-cc@latest

# Claude Code
npx get-shit-done-cc --claude --global   # Install to ~/.claude/
npx get-shit-done-cc --claude --local    # Install to ./.claude/

# OpenCode
npx get-shit-done-cc --opencode --global # Install to ~/.config/opencode/

# Gemini CLI
npx get-shit-done-cc --gemini --global   # Install to ~/.gemini/

# Kilo
npx get-shit-done-cc --kilo --global     # Install to ~/.config/kilo/
npx get-shit-done-cc --kilo --local      # Install to ./.kilo/

# Codex
npx get-shit-done-cc --codex --global    # Install to ~/.codex/
npx get-shit-done-cc --codex --local     # Install to ./.codex/

# Copilot
npx get-shit-done-cc --copilot --global  # Install to ~/.github/
npx get-shit-done-cc --copilot --local   # Install to ./.github/

# Cursor CLI
npx get-shit-done-cc --cursor --global      # Install to ~/.cursor/
npx get-shit-done-cc --cursor --local       # Install to ./.cursor/

# Windsurf
npx get-shit-done-cc --windsurf --global    # Install to ~/.codeium/windsurf/
npx get-shit-done-cc --windsurf --local     # Install to ./.windsurf/

# Antigravity
npx get-shit-done-cc --antigravity --global # Install to ~/.gemini/antigravity/
npx get-shit-done-cc --antigravity --local  # Install to ./.agent/

# Augment
npx get-shit-done-cc --augment --global     # Install to ~/.augment/
npx get-shit-done-cc --augment --local      # Install to ./.augment/

# Trae
npx get-shit-done-cc --trae --global        # Install to ~/.trae/
npx get-shit-done-cc --trae --local         # Install to ./.trae/

# Cline
npx get-shit-done-cc --cline --global       # Install to ~/.cline/
npx get-shit-done-cc --cline --local        # Install to ./.clinerules

# All runtimes
npx get-shit-done-cc --all --global      # Install to all directories

Use --global (-g) or --local (-l) to skip the location prompt. Use --claude, --opencode, --gemini, --kilo, --codex, --copilot, --cursor, --windsurf, --antigravity, --augment, --trae, --cline, or --all to skip the runtime prompt. Use --sdk to also install the GSD SDK CLI (gsd-sdk) for headless autonomous execution.

Clone the repository, build hooks, and run the installer locally:

git clone https://github.com/gsd-build/get-shit-done.git
cd get-shit-done
npm run build:hooks
node bin/install.js --claude --local

The build:hooks step is required — it compiles hook sources into hooks/dist/ which the installer copies from. Without it, hooks won't be installed and you'll get hook errors in Claude Code. (The npm release handles this automatically via prepublishOnly.)

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

Recommended: Skip Permissions Mode

GSD is designed for frictionless automation. Run Claude Code with:

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.

If you prefer not to use that flag, add this to your project's .claude/settings.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

Assumptions Mode: Prefer codebase analysis over questions? Set workflow.discuss_mode to assumptions in /gsd-settings. The system reads your code, surfaces what it would do and why, and only asks you to correct what's wrong. See Discuss Mode.

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 → Ship → Complete → Next Milestone

/gsd-discuss-phase 2
/gsd-plan-phase 2
/gsd-execute-phase 2
/gsd-verify-work 2
/gsd-ship 2                  # Create PR from verified work
...
/gsd-complete-milestone
/gsd-new-milestone

Or let GSD figure out the next step automatically:

/gsd-next                    # Auto-detect and run next step

Loop discuss → plan → execute → verify → ship until milestone complete.

If you want faster intake during discussion, use /gsd-discuss-phase <n> --batch to answer a small grouped set of questions at once instead of one-by-one. Use --chain to auto-chain discuss into plan+execute without stopping between steps.

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 by default
• Separate tracking — Lives in .planning/quick/, not phases

--discuss flag: Lightweight discussion to surface gray areas before planning.

--research flag: Spawns a focused researcher before planning. Investigates implementation approaches, library options, and pitfalls. Use when you're unsure how to approach a task.

--full flag: Enables all phases — discussion + research + plan-checking + verification. The full GSD pipeline in quick-task form.

--validate flag: Enables plan-checking + post-execution verification only (the previous --full behavior).

Flags are composable: --discuss --research --validate gives discussion + research + plan-checking + verification.

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

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:

<task type="auto">
  <name>Create login endpoint</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    Use jose for JWT (not jsonwebtoken - CommonJS issues).
    Validate credentials against users table.
    Return httpOnly cookie on success.
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify>
  <done>Valid credentials return cookie, invalid return 401</done>
</task>

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.

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:

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

Workstreams

Multi-Project Workspaces

UI Design

Navigation

Brownfield

Phase Management

Session

Workstreams

Code Quality

Backlog & Threads

Utilities

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

Core Settings

Model Profiles

Control which Claude model each agent uses. Balance quality vs token spend.

Switch profiles:

/gsd-set-profile budget

Use inherit when using non-Anthropic providers (OpenRouter, local models) or to follow the current runtime model selection (e.g. OpenCode /model).

Or configure via /gsd-settings.

Workflow Agents

These spawn additional agents during planning/execution. They improve quality but add tokens and time.

Use /gsd-settings to toggle these, or override per-invocation:

• /gsd-plan-phase --skip-research
• /gsd-plan-phase --skip-verify

Execution

Agent Skills

Inject project-specific skills into subagents during execution.

Skills are injected as <agent_skills> blocks in agent prompts, giving subagents access to project-specific knowledge.

Git Branching

Control how GSD handles branches during execution.

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.

Security

Built-in Security Hardening

GSD includes defense-in-depth security since v1.27:

• Path traversal prevention — All user-supplied file paths (--text-file, --prd) are validated to resolve within the project directory
• Prompt injection detection — Centralized security.cjs module scans for injection patterns in user-supplied text before it enters planning artifacts
• PreToolUse prompt guard hook — gsd-prompt-guard scans writes to .planning/ for embedded injection vectors (advisory, not blocking)
• Safe JSON parsing — Malformed --fields arguments are caught before they corrupt state
• Shell argument validation — User text is sanitized before shell interpolation
• CI-ready injection scanner — prompt-injection-scan.test.cjs scans all agent/workflow/command files for embedded injection vectors

[!NOTE] Because GSD generates markdown files that become LLM system prompts, any user-controlled text flowing into planning artifacts is a potential indirect prompt injection vector. These protections are designed to catch such vectors at multiple layers.

Protecting Sensitive Files

GSD's codebase mapping and analysis commands read files to understand your project. Protect files containing secrets by adding them to Claude Code's deny list:

1. Open Claude Code settings (.claude/settings.json or global)
2. Add sensitive file patterns to the deny list:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/secrets/*)",
      "Read(**/*credential*)",
      "Read(**/*.pem)",
      "Read(**/*.key)"
    ]
  }
}

This prevents Claude from reading these files entirely, regardless of what commands you run.

[!IMPORTANT] GSD includes built-in protections against committing secrets, but defense-in-depth is best practice. Deny read access to sensitive files as a first line of defense.

Troubleshooting

Commands not found after install?

• Restart your runtime to reload commands/skills
• Verify files exist in ~/.claude/skills/gsd-*/SKILL.md (Claude Code 2.1.88+) or ~/.claude/commands/gsd/ (legacy)
• For Codex, verify skills exist in ~/.codex/skills/gsd-*/SKILL.md (global) or ./.codex/skills/gsd-*/SKILL.md (local)

Commands not working as expected?

• Run /gsd-help to verify installation
• Re-run npx get-shit-done-cc to reinstall

Updating to the latest version?

npx get-shit-done-cc@latest

Using Docker or containerized environments?

If file reads fail with tilde paths (~/.claude/...), set CLAUDE_CONFIG_DIR before installing:

CLAUDE_CONFIG_DIR=/home/youruser/.claude npx get-shit-done-cc --global

This ensures absolute paths are used instead of ~ which may not expand correctly in containers.

Uninstalling

To remove GSD completely:

# Global installs
npx get-shit-done-cc --claude --global --uninstall
npx get-shit-done-cc --opencode --global --uninstall
npx get-shit-done-cc --gemini --global --uninstall
npx get-shit-done-cc --kilo --global --uninstall
npx get-shit-done-cc --codex --global --uninstall
npx get-shit-done-cc --copilot --global --uninstall
npx get-shit-done-cc --cursor --global --uninstall
npx get-shit-done-cc --windsurf --global --uninstall
npx get-shit-done-cc --antigravity --global --uninstall
npx get-shit-done-cc --augment --global --uninstall
npx get-shit-done-cc --trae --global --uninstall
npx get-shit-done-cc --cline --global --uninstall

# Local installs (current project)
npx get-shit-done-cc --claude --local --uninstall
npx get-shit-done-cc --opencode --local --uninstall
npx get-shit-done-cc --gemini --local --uninstall
npx get-shit-done-cc --kilo --local --uninstall
npx get-shit-done-cc --codex --local --uninstall
npx get-shit-done-cc --copilot --local --uninstall
npx get-shit-done-cc --cursor --local --uninstall
npx get-shit-done-cc --windsurf --local --uninstall
npx get-shit-done-cc --antigravity --local --uninstall
npx get-shit-done-cc --augment --local --uninstall
npx get-shit-done-cc --trae --local --uninstall
npx get-shit-done-cc --cline --local --uninstall

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

Community Ports

OpenCode, Gemini CLI, Kilo, and Codex are now natively supported via npx get-shit-done-cc.

These community ports pioneered multi-runtime support:

Star History

License

MIT License. See LICENSE for details.

Claude Code is powerful. GSD makes it reliable.