GET SHIT DONE NG

gsd-ng is a next-generation hard fork of GSD, optimized for Claude Code and GitHub Copilot CLI.

A light-weight and powerful meta-prompting, context engineering and spec-driven development system.

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

npx gsd-ng@latest

Works on Mac and Linux.

How It Works · Commands · Why It Works · User Guide

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.

Getting Started

npx gsd-ng@latest

The installer prompts you to choose your install location (global or local project).

Verify with:

Claude Code: /gsd:help
Copilot CLI: gsd-help (skills format)

Staying Updated

GSD evolves fast. Update periodically:

npx gsd-ng@latest

Non-interactive Install (Docker, CI, Scripts)

npx gsd-ng --runtime claude --global    # Install to ~/.claude/
npx gsd-ng --runtime claude --local     # Install to ./.claude/
npx gsd-ng --runtime copilot --local    # Install for Copilot CLI to ./.github/
npx gsd-ng --runtime copilot --global   # Install for Copilot CLI to ~/.copilot/

Use --runtime claude or --runtime copilot with --global (-g) or --local (-l) to skip the interactive prompts.

Development / Building from Source

Use this when working on a development branch or testing local changes.

1. Clone and checkout branch:

git clone https://github.com/chrisdevchroma/gsd-ng.git
cd gsd-ng
git checkout <branch-name>

2. Install dependencies:

npm install

This installs dev dependencies (esbuild, c8) needed for building and testing.

3. Build hooks:

npm run build:hooks

Copies hook scripts to hooks/dist/. The installer expects built hooks in hooks/dist/, so this step is required before installing.

4. Install locally into your project:

Run from inside the target project directory (not the gsd-ng clone):

node bin/install.js --runtime claude --local
node bin/install.js --runtime copilot --local   # For Copilot CLI

Installs to ./.claude/ (or ./.github/ for Copilot).

5. Run tests:

npm test

6. Run tests with coverage:

npm run test:coverage

Sandbox Mode

Sandbox mode is configured automatically during install. The installer seeds settings.json with sandbox settings and pre-approved permissions for all GSD operations.

To opt out during install, use --no-seed-sandbox-config.

Tip

If GSD ever triggers an approval dialog in sandbox mode, that's a bug -- open an issue.

Alternative: Skip Permissions Mode

If you prefer to skip all permission checks:

claude --dangerously-skip-permissions

This disables all safety checks. Sandbox mode (above) is preferred because it provides the same frictionless experience while maintaining filesystem isolation.

Alternative: Custom Granular Permissions

If you want to customize which commands are allowed, add this to your project's .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(date *)",
      "Bash(git *)",
      "Bash(node *)",
      "Bash(npm *)"
    ]
  }
}

See gsd-ng/gsd-ng/templates/settings-sandbox.json for the complete list of GSD-required commands.

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:

Questions — Asks until it understands your idea completely (goals, constraints, tech preferences, edge cases)
Research — Spawns parallel agents to investigate the domain (optional but recommended)
Requirements — Extracts what's v1, v2, and out of scope
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:

Researcher reads it — Knows what patterns to investigate ("user wants card layout" → research card component libraries)
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:

Researches — Investigates how to implement this phase, guided by your CONTEXT.md decisions
Plans — Creates 2-3 atomic task plans with XML structure
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:

Runs plans in waves — Parallel where possible, sequential when dependent
Fresh context per plan — 200k tokens purely for implementation, zero accumulated garbage
Commits per task — Every task gets its own atomic commit
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:

Extracts testable deliverables — What you should be able to do now
Walks you through one at a time — "Can you log in with email?" Yes/no, or describe what's wrong
Diagnoses failures automatically — Spawns debug agents to find root causes
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.

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.

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.

--verify flag: Enables plan-checking (max 2 iterations) and post-execution verification.

--all flag: Enables all optional stages (discuss + research + verify).

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

Quick Mode Flags

Flag	What it adds
`--discuss`	Lightweight discussion phase, captures decisions in CONTEXT.md
`--research`	Spawns research agent, produces RESEARCH.md
`--verify`	Plan-checking (max 2 iterations) + post-execution verification
`--all`	All of the above (discuss + research + verify)

/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 powerful — but without structured context, results degrade as projects grow. Context gets lost, quality drops, and code stops fitting together.

GSD handles context 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

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>

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:

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.

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 <N>`	Execute all plans in parallel waves, verify when complete
`/gsd:verify-work [N]`	Manual user acceptance testing
`/gsd:research-phase [N]`	Research how to implement a phase (standalone -- usually use /gsd:plan-phase instead)
`/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

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
`/gsd:create-pr`	Create a pull request or merge request from GSD work
`/gsd:squash <phase> [--strategy single\|per-plan\|logical] [--dry-run]`	Squash phase commits into clean history for code review
`/gsd:validate-phase [N]`	Retroactively audit and fill Nyquist validation gaps for a completed phase

Issue Tracking

Command	What it does
`/gsd:import-issues [issue]`	Import external issues from GitHub/GitLab/Forgejo/Gitea as GSD todos
`/gsd:sync-issues [phase]`	Manually sync GSD planning state with external issue trackers
`/gsd:divergence [--refresh] [--init]`	Track upstream fork divergence and triage pending commits

UI & Design

Command	What it does
`/gsd:ui-phase [N]`	Generate UI design contract (UI-SPEC.md) for frontend phases
`/gsd:ui-review [N]`	Retroactive 6-pillar visual audit of implemented frontend code

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 <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 [--verify] [--discuss] [--research] [--all]`	Execute ad-hoc task with GSD guarantees (`--verify` adds plan-checking and verification, `--discuss` gathers context first, `--research` investigates approaches before planning, `--all` enables all optional stages)
`/gsd:health [--repair]`	Validate `.planning/` directory integrity, auto-repair with `--repair`
`/gsd:add-tests <phase> [instructions]`	Generate tests for a completed phase based on UAT criteria and implementation
`/gsd:cleanup`	Archive phase directories from completed milestones
`/gsd:do <description>`	Route freeform text to the right GSD command automatically
`/gsd:note <text> \| list \| promote <N>`	Zero-friction idea capture, list notes, or promote to todos
`/gsd:reapply-patches`	Reapply local modifications after a GSD update
`/gsd:seed-memories`	Detect workspace topology and seed appropriate guardrail memories
`/gsd:stats`	Display project statistics -- phases, plans, requirements, git metrics, and timeline

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

Setting	Options	Default	What it controls
`mode`	`yolo`, `interactive`	`interactive`	Auto-approve vs confirm at each step
`granularity`	`coarse`, `standard`, `fine`	`standard`	Phase granularity — how finely scope is sliced (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

Git Branching

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 your runtime to reload commands/skills
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-ng to reinstall

Updating to the latest version?

npx gsd-ng@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 gsd-ng --runtime claude --global

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

Uninstalling

To remove GSD completely:

# Claude Code - global installs
npx gsd-ng --runtime claude --global --uninstall

# Claude Code - local installs (current project)
npx gsd-ng --runtime claude --local --uninstall

# Copilot CLI - local installs
npx gsd-ng --runtime copilot --local --uninstall

# Copilot CLI - global installs
npx gsd-ng --runtime copilot --global --uninstall

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

License

MIT License. See LICENSE for details.

Claude Code is powerful. GSD makes it reliable.

Name		Name	Last commit message	Last commit date
Latest commit History 1,172 Commits
.github		.github
agents		agents
assets		assets
benchmarks		benchmarks
bin		bin
commands/gsd		commands/gsd
docs		docs
gsd-ng		gsd-ng
hooks		hooks
scripts		scripts
tests		tests
.git-blame-ignore-revs		.git-blame-ignore-revs
.gitattributes		.gitattributes
.gitignore		.gitignore
.prettierignore		.prettierignore
.prettierrc		.prettierrc
CHANGELOG.md		CHANGELOG.md
CONTRIBUTING.md		CONTRIBUTING.md
LICENSE		LICENSE
README.md		README.md
SECURITY.md		SECURITY.md
VERSIONING.md		VERSIONING.md
package-lock.json		package-lock.json
package.json		package.json

Folders and files

Latest commit

History

Repository files navigation

GET SHIT DONE NG

Who This Is For

Getting Started

Staying Updated

Sandbox Mode

How It Works

1. Initialize Project

2. Discuss Phase

3. Plan Phase

4. Execute Phase

5. Verify Work

6. Repeat → Complete → Next Milestone

Quick Mode

Why It Works

Context Engineering

XML Prompt Formatting

Multi-Agent Orchestration

Atomic Git Commits

Modular by Design

Commands

Core Workflow

Navigation

Brownfield

Phase Management

Issue Tracking

UI & Design

Session

Utilities

Configuration

Core Settings

Model Profiles

Workflow Agents

Execution

Git Branching

Troubleshooting

Uninstalling

License

About

Resources

License

Contributing

Security policy

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Uh oh!

Uh oh!

Contributors

Uh oh!

Languages

Packages