Skip to content
/

GET SHIT DONE (GSD)

get-shit-done · open-gsd/get-shit-done-redux · ★ 943 · last commit 2026-05-26

Prevent AI context rot by keeping the orchestrator lean (~15% context) and running all implementation in parallel fresh 200k-token subagent contexts.

Best whenContext window engineering is a first-class engineering concern — the orchestrator should never exceed 15% context usage.
Skip ifLetting the main context window fill up, Running implementation in the same context as planning
vs seeds
taskmaster-ai(both decompose work into phases/plans and execute with agents), but GSD treats context window budget as its primary des…
Primitive shape 112 total
Commands 66 Subagents 33 Hooks 13
00

Summary

GET SHIT DONE (GSD) — Summary

GET SHIT DONE is a meta-prompting, context engineering, and spec-driven development system originally published by glittercowboy and now maintained under the open-gsd organization as get-shit-done-redux. The framework's core problem statement is "context rot" — the quality degradation that occurs as an AI fills its context window — and it solves this by keeping the orchestrator's context lean (~15%) and running all implementation work in fresh subagent contexts of up to 200k tokens. The system centers on six commands: gsd-new-project, gsd-discuss-phase, gsd-plan-phase, gsd-execute-phase, gsd-verify-work, and gsd-ship. It ships as an npm package (@opengsd/get-shit-done-redux) with 66+ commands, 33 named agents, and 13 JS/shell hooks. The execution model uses "wave-based parallelization" — plans within a phase are grouped by dependency depth and executed in parallel waves, with each executor getting a completely fresh 200k-token context. A --quick mode bypasses discussion; --interactive mode executes sequentially for pair-programming style.

Compared to seeds, GSD is closest to taskmaster-ai (both use milestone/phase decomposition and produce plan files) but diverges by: (1) emphasizing context window engineering as its primary design concern; (2) running executors in completely fresh parallel contexts rather than a single agent; (3) shipping a gsd-tools CLI binary for local context SDK operations; and (4) targeting multiple AI tools (Claude Code, Gemini CLI, Codex, Copilot, Cursor, Kilo, Windsurf) rather than being Cursor-primary.

01

Overview

GET SHIT DONE — Overview

Origin

Originally created by glittercowboy/TÂCHES. The original repo (glittercowboy/get-shit-done) now redirects to open-gsd/get-shit-done-redux following a continuity transition in May 2026, after trust and ownership concerns around the former upstream — including a meme-coin rug-pull incident publicly associated with the original ecosystem. The open-gsd team took over active maintenance.

The npm package is @opengsd/get-shit-done-redux (v1.0.0, 943 stars on the Redux repo; the original had 63,706 stars).

Philosophy

"A light-weight meta-prompting, context engineering, and spec-driven development system for Claude Code, OpenCode, Gemini CLI, Kilo, Codex, Copilot, Cursor, Windsurf, and more."

"Solves context rot — the quality degradation that happens as your AI fills its context window."

The framework's central insight: subagents with fresh contexts outperform a single agent with a degraded context. The orchestrator stays at 15% context budget; all real work happens in fresh 200k-token subagent contexts.

Key Manifesto Excerpts

From the README:

"Plans run in parallel waves. Each executor gets a fresh 200k-token context. Each task gets its own atomic commit. Walk away, come back to completed work with a clean git history."

"Your main context window stays at 30–40%. The work happens in the subagents."

"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." (user testimonial)

Security Notice

The README documents a continuity transition:

"In May 2026, maintainers published a continuity announcement and migrated active development to open-gsd/get-shit-done-redux after trust and ownership concerns around the former upstream, including a meme-coin rug-pull incident publicly associated with that ecosystem."

The team completed an internal security audit and an independent review pass; no known active exploit was found in tracked source.

02

Architecture

GET SHIT DONE — Architecture

Distribution

  • Type: npm package (@opengsd/get-shit-done-redux)
  • Install: npx @opengsd/get-shit-done-redux@latest
  • License: MIT
  • Language: JavaScript/TypeScript (tooling), Markdown (prompts)
  • Version: 1.0.0

Directory Structure (installed into ~/.claude/get-shit-done/)

commands/gsd/         ← 66+ slash commands
agents/               ← 33 named agents
hooks/                ← 13 JS/shell hook scripts
get-shit-done/
  bin/                ← gsd-tools CLI binary
  workflows/          ← Workflow reference files loaded via @-syntax
  references/         ← Context files (ui-brand.md, mandatory-initial-read.md)
  templates/          ← Phase/plan templates
  contexts/           ← Project context files
sdk/                  ← GSD SDK for CLI operations

Per-Project State Files (.plans/)

.plans/
  <phase-N>/
    CONTEXT.md        ← Discuss-phase decisions
    RESEARCH.md       ← Phase research output
    PLAN.md           ← Executable plan with tasks
    SUMMARY.md        ← Post-execution summary
    VERIFICATION.md   ← Verify-work output

Required Runtime

  • Node.js >= 18
  • Claude Code (primary) or compatible AI tool

Target AI Tools

Claude Code, Gemini CLI, OpenCode, GitHub Copilot (VS Code), Cursor, Windsurf, OpenAI Codex, Kilo, Amp, and more. The framework has explicit runtime_note blocks in commands that handle Copilot's vscode_askquestions API difference vs Claude Code's AskUserQuestion.

Cross-Tool Architecture

Commands include runtime detection:

<runtime_note>
**Copilot (VS Code):** Use `vscode_askquestions` wherever this workflow
calls `AskUserQuestion`. They are equivalent.
</runtime_note>

This makes most commands compatible with any AI tool that can read markdown commands from ~/.claude/.

03

Components

GET SHIT DONE — Components

Commands (66+ in commands/gsd/)

Core six-command loop:

Command Purpose
gsd:new-project Project init: questions → research → requirements → roadmap
gsd:discuss-phase Capture design decisions for a specific phase
gsd:plan-phase Research → create PLAN.md → verify loop
gsd:execute-phase Wave-based parallel execution with fresh subagent contexts
gsd:verify-work Walk through what was built; diagnose failures → fix plans
gsd:ship Commit, tag, PR, archive phase

Selected additional commands:

  • gsd:map-codebase — Analyze stack, architecture, conventions
  • gsd:complete-milestone, gsd:new-milestone — Milestone lifecycle
  • gsd:quick — Lightweight single-shot execution
  • gsd:audit-milestone, gsd:audit-fix — Post-execution auditing
  • gsd:secure-phase — Security hardening pass
  • gsd:ui-phase, gsd:ui-review — UI-specific phases
  • gsd:spec-phase — Spec-first phase variant
  • gsd:ultraplan-phase — Deep planning mode
  • gsd:spike — Exploratory spike workflow
  • gsd:tdd — TDD-enforced variant of execute-phase
  • gsd:workstreams — Parallel workstream management
  • gsd:pr-branch — PR creation workflow
  • gsd:code-review — Code review pass
  • gsd:settings, gsd:config — Configuration management

Agents (33)

Agent Role
gsd-executor Executes PLAN.md files atomically; creates per-task commits; handles deviations
gsd-planner Creates PLAN.md from CONTEXT.md + RESEARCH.md
gsd-plan-checker Verifies PLAN.md against quality criteria
gsd-phase-researcher Researches phase domain; writes RESEARCH.md
gsd-verifier Post-execution verification; writes VERIFICATION.md
gsd-roadmapper Creates project roadmap from requirements
gsd-code-reviewer Code quality review
gsd-security-auditor Security-focused review pass
gsd-ui-auditor, gsd-ui-checker, gsd-ui-researcher UI-specific agents
gsd-debugger, gsd-debug-session-manager Debug workflows
gsd-doc-writer, gsd-doc-classifier, gsd-doc-synthesizer, gsd-doc-verifier Documentation agents
gsd-codebase-mapper Analyzes codebase structure
gsd-domain-researcher, gsd-ai-researcher, gsd-advisor-researcher Research variants
gsd-eval-planner, gsd-eval-auditor Evaluation workflow
gsd-pattern-mapper Architecture pattern analysis
gsd-nyquist-auditor Sampling-theory-inspired code coverage auditor
gsd-assumptions-analyzer Extracts hidden assumptions
gsd-code-fixer Targeted code repair agent
gsd-project-researcher Full-project research
gsd-integration-checker Integration point verification
gsd-intel-updater Update project intelligence
gsd-framework-selector Technology selection agent
gsd-research-synthesizer Merges research from multiple agents
gsd-user-profiler User persona analysis

Hooks (13 JS/shell scripts)

Script Purpose
gsd-phase-boundary.sh Enforces phase transition rules
gsd-workflow-guard.js Prevents out-of-order command execution
gsd-prompt-guard.js Blocks disallowed prompts
gsd-read-guard.js Guards sensitive file reads
gsd-read-injection-scanner.js Scans for prompt injection in read operations
gsd-session-state.sh Manages session state
gsd-statusline.js Displays phase status in terminal
gsd-context-monitor.js Monitors context window usage
gsd-validate-commit.sh Validates commit messages
gsd-check-update.js Update checker
gsd-check-update-worker.js Update check worker
gsd-graphify-update.sh Knowledge graph update hook
gsd-update-banner.js Update notification banner

CLI Binary

  • gsd-tools binary (get-shit-done/bin/gsd-tools.cjs) — SDK operations for querying project context
  • get-shit-done-redux binary — installer/setup

Templates and References

  • Per-phase workflow files: ~/.claude/get-shit-done/workflows/*.md (loaded via @-syntax)
  • Reference files: mandatory-initial-read.md, ui-brand.md
05

Prompts

GET SHIT DONE — Prompt Excerpts

Excerpt 1: plan-phase.md — Objective and Research-Only Mode

Source: commands/gsd/plan-phase.md

---
name: gsd:plan-phase
description: Create detailed phase plan (PLAN.md) with verification loop
argument-hint: "[phase] [--auto] [--research] [--skip-research] [--view] [--gaps] [--skip-verify]
  [--prd <file>] [--ingest <path-or-glob>] [--ingest-format <auto|nygard|madr|narrative>]..."
---
<objective>
Create executable phase prompts (PLAN.md files) for a roadmap phase with integrated research
and verification.

**Default flow:** Research (if needed) → Plan → Verify → Done

**Research-only mode (`--research-phase <N>`):** Spawn `gsd-phase-researcher` for phase `N`,
write `RESEARCH.md`, then exit before the planner runs. Useful for cross-phase research, doc
review before committing to a planning approach, and correction-without-replanning loops where
iterating on research alone is dramatically cheaper than re-spawning the planner.

**Orchestrator role:** Parse arguments, validate phase, research domain (unless skipped),
spawn gsd-planner, verify with gsd-plan-checker, iterate until pass or max iterations.
</objective>

Prompting technique: XML <objective> wrapper with bold-label flow variants. The <execution_context> block uses @-syntax to load workflow files without inlining them, keeping the command prompt lean.


Excerpt 2: execute-phase.md — Context Budget and Orchestrator Role

Source: commands/gsd/execute-phase.md

---
name: gsd:execute-phase
description: Execute all plans in a phase with wave-based parallelization
---
<objective>
Execute all plans in a phase using wave-based parallel execution.

Orchestrator stays lean: discover plans, analyze dependencies, group into waves, spawn subagents,
collect results. Each subagent loads the full execute-plan context and handles its own plan.

Context budget: ~15% orchestrator, 100% fresh per subagent.
</objective>

<execution_context>
@~/.claude/get-shit-done/workflows/execute-phase.md
@~/.claude/get-shit-done/references/ui-brand.md
</execution_context>

Prompting technique: Context budget as a first-class constraint in the objective block. @-syntax for reference files keeps the command prompt under the token budget while still loading full workflow instructions.


Excerpt 3: gsd-executor.md — Agent Role and Documentation Lookup

Source: agents/gsd-executor.md

---
name: gsd-executor
description: Executes GSD plans with atomic commits, deviation handling, checkpoint protocols,
and state management. Spawned by execute-phase orchestrator or execute-plan command.
tools: Read, Write, Edit, Bash, Grep, Glob, mcp__context7__*
color: yellow
---

<role>
You are a GSD plan executor. You execute PLAN.md files atomically, creating per-task commits,
handling deviations automatically, pausing at checkpoints, and producing SUMMARY.md files.

Spawned by `/gsd:execute-phase` orchestrator.

Your job: Execute the plan completely, commit each task, create SUMMARY.md, update STATE.md.

@~/.claude/get-shit-done/references/mandatory-initial-read.md
</role>

<documentation_lookup>
When you need library or framework documentation, check in this order:
1. If Context7 MCP tools (`mcp__context7__*`) are available: use them.
2. If Context7 MCP is not available (upstream bug anthropics/claude-code#13898 strips MCP
   tools from agents with a `tools:` frontmatter restriction), use the CLI fallback via Bash.
</documentation_lookup>

Prompting technique: Fallback documentation strategy embedded in agent definition, acknowledging a known upstream Claude Code bug with a specific issue reference. The mcp__context7__* tool pattern shows dynamic MCP tool access.

09

Uniqueness

GET SHIT DONE — Uniqueness

Differs From Seeds

GSD is most similar to taskmaster-ai (both decompose work into phases/plans and execute them with agents), but diverges materially: GSD treats context window management as a first-class engineering concern rather than a secondary consideration — the orchestrator explicitly budgets ~15% context and all implementation runs in fresh 200k-token subagent contexts. Where taskmaster uses a single MCP server with 37 tools, GSD uses 33 named agents with domain specialization. GSD also targets 9+ AI tools explicitly with per-tool compatibility shims, while taskmaster was designed Cursor-first.

Compared to openspec (command+skill mirror pattern), GSD has far more commands (66+) but no skills — all behavior is slash-command initiated, making it explicit-invocation-only with no autonomous skill activation.

Positioning

  • "Meta-prompting and context engineering" framing (vs. "spec-driven development")
  • First-class concern: preventing context rot through structural isolation
  • Broad AI-tool compatibility as a core design goal
  • Community-governed after original creator's ecosystem issues

Notable Patterns

  1. Context budget as a constraint: The "~15% orchestrator, 100% fresh per subagent" is stated numerically in the objective block — unusual among all seeds
  2. Wave-based parallelism: Tasks are dependency-analyzed and run in parallel waves per phase
  3. GSD SDK: A gsd-tools CLI binary for programmatic context access — the only framework in this batch with a query-focused SDK binary
  4. gsd-nyquist-auditor: An agent named after Nyquist sampling theory for code coverage auditing — the most idiosyncratic agent name in the corpus
  5. Cross-tool shims: Built-in vscode_askquestionsAskUserQuestion compatibility

Observable Failure Modes

  1. Complexity of 66+ commands: The command surface is larger than any seed framework — discoverability is a real problem
  2. Provenance concerns: The security transition creates adoption friction for risk-sensitive teams
  3. No built-in compaction: Fresh contexts prevent context rot but don't compact within a subagent session
  4. Dependency analysis brittleness: Wave grouping depends on plan file structure — malformed PLAN.md files could incorrectly sequence tasks

Cross-References

  • Explicitly compares itself to SpecKit, OpenSpec, and Taskmaster in user testimonials
  • The gsd-nyquist-auditor and gsd-eval-planner/gsd-eval-auditor suggest influence from formal evaluation methodologies
04

Workflow

GET SHIT DONE — Workflow

Core Six-Command Loop

new-project → discuss-phase N → plan-phase N → execute-phase N → verify-work N → ship N
                                                                     ↓ if failures
                                                               diagnose → fix plans → execute again
                    ↑ repeat for each phase until milestone done
complete-milestone → new-milestone

Phase Artifacts

Command Input Output Artifact
gsd-new-project User answers + codebase Roadmap, CONTEXT.md
gsd-map-codebase Codebase Project intelligence files
gsd-discuss-phase N Phase summary + user decisions CONTEXT.md
gsd-plan-phase N CONTEXT.md + RESEARCH.md PLAN.md with wave-ordered tasks
gsd-execute-phase N PLAN.md code changes + per-task commits
gsd-verify-work N code changes + PLAN.md VERIFICATION.md + fix plans
gsd-ship N verified code PR + milestone archive

Approval Gates

  1. After new-project — user reviews roadmap before phasing
  2. After discuss-phase — user reviews CONTEXT.md before planning
  3. After plan-phase — plan verification loop (up to N iterations with gsd-plan-checker)
  4. After verify-work — user decides whether to re-execute failed items or accept
  5. PR review (external, on GitHub) before merge

Wave-Based Execution

The execute-phase command groups plan tasks into dependency waves:

  • Wave 1: tasks with no dependencies
  • Wave 2: tasks depending only on Wave 1
  • Wave N: tasks depending on Wave N-1

Tasks in the same wave execute in parallel (each in a fresh subagent context). The --wave N flag can execute only a specific wave for staged rollout or quota management.

Execution Flags

  • --wave N — Execute only wave N
  • --gaps-only — Execute only gap-closure plans (from verification failures)
  • --interactive — Sequential execution with user checkpoints (no subagents)
  • --tdd — TDD-enforced execution variant
  • --skip-research — Skip research phase in plan-phase
  • --prd <file> — Use a PRD instead of discuss-phase output

Plan-Phase Verification Loop

plan-phase runs a verify loop after generating PLAN.md:

  1. Spawn gsd-plan-checker to validate the plan
  2. If checker finds issues, iterate (up to max iterations)
  3. If plan passes checker: present to user

Context Budget Management

The orchestrator maintains ~15% context usage by:

  • Loading workflow files via @-syntax references (not inline)
  • Delegating all work to subagents with fresh 200k contexts
  • Monitoring context via gsd-context-monitor.js hook
06

Memory Context

GET SHIT DONE — Memory & Context

State Storage

File-based, per-project, in .plans/.

Per-Phase Files

File Purpose
.plans/<phase-N>/CONTEXT.md Decisions from discuss-phase; fed into plan-phase
.plans/<phase-N>/RESEARCH.md Phase research output from gsd-phase-researcher
.plans/<phase-N>/PLAN.md Executable plan with wave-ordered tasks
.plans/<phase-N>/SUMMARY.md Post-execution summary written by gsd-executor
.plans/<phase-N>/VERIFICATION.md Verify-work output with pass/fail per task

Project Intelligence Files

Created by gsd-map-codebase, loaded into every session:

  • Architecture descriptions
  • Stack and convention documentation
  • Dependency graphs

Persistence

  • Scope: project-level, git-tracked
  • All .plans/ files are markdown, human-readable and diffable
  • Plans survive session boundaries since they're on-disk files

Context Window Engineering

The framework explicitly manages context budgets:

  • Orchestrator commands load workflows via @-syntax file references (not inlined)
  • Subagents start fresh — they don't inherit orchestrator conversation history
  • gsd-context-monitor.js hook monitors context usage and can warn when approaching limits

Session Handoff

  • gsd-resume-work command re-establishes context from .plans/ files
  • gsd-progress shows current phase and task completion
  • mandatory-initial-read.md is loaded by each agent at startup

Compaction

  • No explicit compaction mechanism built in (unlike superpowers or spec-driver)
  • Context rot is addressed structurally by keeping orchestrator lean and using fresh subagents

GSD SDK

  • gsd-tools CLI binary provides local context queries
  • gsd-sdk query init.execute-phase pattern loads context per command
  • Enables programmatic access to project state outside the conversation

Cross-Session Continuity

  • .plans/ directory is the authoritative record
  • gsd-session-state.sh hook script persists session metadata
  • gsd-extract-learnings command captures insights for future phases
07

Orchestration

GET SHIT DONE — Orchestration

Multi-Agent Pattern

Yes — parallel-fan-out within each phase. The execute-phase orchestrator analyzes plan task dependencies, groups them into waves, and spawns one executor subagent per task in parallel (up to all tasks in a wave).

  • Orchestration pattern: parallel-fan-out (wave-based)
  • Coordinator: execute-phase command (~15% context budget)
  • Workers: gsd-executor agents (one per plan task, fresh 200k context each)

Wave-Based Execution

Phase plans → dependency analysis → Wave 1 (parallel) → Wave 2 (parallel) → ... → merge

Tasks with no mutual dependencies execute simultaneously. The --wave N flag enables staged execution.

Agent Spawn Mechanism

  • Executors are spawned via Claude's Agent tool (allowed-tools: [..., Agent])
  • Each spawned agent gets a fresh context loaded with the specific plan file + references
  • The <files_to_read> block in each subagent definition specifies context loading

Subagent Isolation

  • No git-worktree or container isolation per task
  • Each executor gets a fresh conversation context (no shared memory)
  • Tasks produce commits before the orchestrator collects results

Research Phase Parallelism

The plan-phase command also uses parallel research:

  • gsd-domain-researcher, gsd-phase-researcher, and specialist researchers can run in parallel
  • gsd-research-synthesizer merges their outputs into a unified RESEARCH.md

Plan Verification Loop

After plan generation:

  1. gsd-plan-checker reviews the plan for quality
  2. If issues found, gsd-planner is re-spawned (up to max iterations)
  3. Human sees the final plan after checker passes

Execution Mode

  • Default: parallel-fan-out (wave-based)
  • --interactive flag: sequential, in-place, no subagents (pair-programming mode)
  • --gaps-only: re-executes only failed items from VERIFICATION.md

Multi-Model

No explicit multi-model routing in command definitions. The gsd-executor agent definition includes mcp__context7__* tool access for documentation lookup, but the underlying LLM is whatever the user has configured.

Consensus

None. The plan-checker is a gating review, not consensus. Verify-work is a validation pass, not adversarial review.

Prompt Chaining

Yes — CONTEXT.md feeds into PLAN.md generation; PLAN.md feeds executor agents; SUMMARY.md feeds verify-work; VERIFICATION.md feeds gap-closure re-execution. Each stage's output is the next stage's primary input.

08

Ui Cli Surface

GET SHIT DONE — UI / CLI Surface

CLI Binary

Yes — two binaries:

Binary Path Purpose
get-shit-done-redux bin/install.js Installer/setup
gsd-tools get-shit-done/bin/gsd-tools.cjs GSD SDK local context queries

The gsd-tools binary provides programmatic access to project context (e.g., gsd-sdk query init.execute-phase pattern used inside commands to load context files).

Local UI

None. No web dashboard or TUI.

IDE Integration

The framework targets multiple AI tools:

  • Claude Code — primary
  • GitHub Copilot (VS Code)vscode_askquestions compatibility shim built into all commands
  • Gemini CLI — listed as supported
  • OpenAI Codex — listed as supported
  • Cursor, Windsurf, Kilo, Amp, OpenCode — listed as supported

Commands are stored in ~/.claude/get-shit-done/ but the cross-tool compatibility is handled via runtime detection blocks in each command file.

Observability

  • gsd-statusline.js hook — displays phase status in terminal
  • gsd-context-monitor.js hook — monitors and reports context window usage
  • gsd-progress command — shows current milestone/phase/task status
  • gsd-stats command — usage statistics
  • .plans/ directory — human-readable audit trail of all phases

Commit Discipline

  • gsd-validate-commit.sh hook — validates commit message format
  • Each executor creates one commit per plan task (atomic commits)
  • gsd-ship creates the PR with AI-generated description

Update Management

  • gsd-check-update.js and gsd-check-update-worker.js hooks check for package updates
  • gsd-update-banner.js displays update notifications
  • gsd-graphify-update.sh updates the knowledge graph representation

Related frameworks

same archetype · same primary tool · same memory type

claude-mem (thedotmack) ★ 78k

Background worker service captures every tool call as an observation, AI-compresses sessions, and auto-injects relevant past…

pi (badlogic/earendil) ★ 55k

A minimal, hackable, multi-provider terminal coding agent that adapts to your workflows via npm-installable TypeScript Extensions…

Agent Skills (Addy Osmani) ★ 46k

Encodes senior-engineer software development lifecycle as 23 auto-routed skills and 7 slash commands for any AI coding agent.

wshobson/agents Plugin Marketplace ★ 36k

Single Markdown source for 83 domain-specialized plugins that auto-generates idiomatic artifacts for five AI coding harnesses.

TabbyML/Tabby ★ 34k

Self-hosted AI coding assistant server (alternative to GitHub Copilot) with admin dashboard, RAG-based completions, and multi-IDE…

Compound Engineering ★ 17k

Make each unit of engineering work compound into easier future work via brainstorm→plan→execute→review→learn cycles.