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

What is GSD Core

GSD Core is a context-engineering and spec-driven development framework that drives AI coding agents (Claude Code, Codex, Antigravity CLI, Kimi CLI, Copilot, Cursor, and more) through a disciplined phase loop. It solves context rot — the quality degradation that accumulates as an AI fills its context window — by running all heavy research, planning, and execution work in fresh-context subagents while keeping your main session lean.

This is a fork of TheRocketCodeMX/gsd-core (MIT), maintained by TheRocketCode and published as @therocketcode/gsd-core. It keeps everything upstream offers and adds the greenfield discovery spine and testing methodology described below.

What this fork adds

On top of gsd-core's phase loop, this fork adds a connected product → domain → architecture → tests discovery spine, plus concrete test-infrastructure know-how.

Greenfield discovery — each step feeds the next:

/gsd:discover-product — define what to build and why: real demand vs. interest, the narrowest wedge, the four product risks, outcome-framed → PRODUCT-BRIEF.md
/gsd:model-domain — lightweight DDD: ubiquitous language + core/supporting/generic subdomain distillation → DOMAIN-MODEL.md
/gsd:recommend-architecture — a two-axis recommendation (domain-logic ladder × deployment topology) that avoids over- and under-engineering, captured as an ADR → ADR-NNNN.md
/gsd:testing-strategy — derives the test shape from the architecture (rich core → unit tests; CRUD-over-DB → integration tests), with coverage-as-floor + mutation testing → TEST-STRATEGY.md

Testing know-how the agent consults while writing tests: Testcontainers, parallel-safe DB isolation, authenticate-once / multi-role auth, synthetic test data, E2E tiering, and flaky-test avoidance.

The payoff: one complexity assessment made during discovery parameterizes both the architecture and the test strategy — a single thread from "what are we building" to "how do we test it."

Durable knowledge across the whole project — the context capability:

/gsd:context (seed · scout · flush · master) — the knowledge lifecycle on top of GSD's fresh-subagent model. Right after roadmap approval the orchestrator seeds quality-stamped phase capsules (<N>-CONTEXT.md) and a bounded MASTER-CONTEXT.md index: verified facts each anchored path:line, locked decisions with their why, cross-repo seams, phase-scoped pitfalls. Capsules are treated as evidence — grown in append-only layers (later layers supersede, nothing is deleted), verified at birth and re-verified by gsd-tools context verify (a failed anchor is annotated [STALE], never silently trusted). A calm context-pressure hook nudges a knowledge flush at high usage (never a panic save), and the standing first act after any compaction is re-anchoring from the MASTER index + active capsule. Elicitation Q&A is captured to append-only discussion logs so the reasoning behind each decision survives distillation. Doctrine: plans are perishable; context is durable — front-load the knowledge, never the plans.

How it works

Each milestone repeats the same five-step loop, one phase at a time:

Discuss — capture implementation decisions before anything is planned
Plan — research, decompose, and verify the plan fits a fresh context window
Execute — run plans in parallel waves; each executor starts with a clean 200k-token context
Verify — walk through what was built; diagnose and fix before declaring done
Ship — create the PR, archive the phase, repeat for the next one

Quickstart

npx @therocketcode/gsd-core@latest

The installer prompts for your runtime (Claude Code, OpenCode, Antigravity CLI, Kimi CLI, Kilo, Codex, Copilot, Cursor, Windsurf, and more) and whether to install globally or locally. The installer is required for cross-runtime compatibility — do not copy files from agents/ or commands/ directly.

On another runtime or without Node.js? See Install on your runtime.

Once installed, start a new project or onboard an existing repo:

/gsd-new-project   # greenfield project
/gsd-onboard       # existing codebase

New here? Follow Your first project for a guided walkthrough from install to first shipped phase, or Onboarding an existing codebase for brownfield setup.

Installing & updating

How you get the latest version depends on what you already have installed:

Nothing installed yet — run the Quickstart command once:
```
npx -y @therocketcode/gsd-core@latest --claude --global   # or --local for a single project
```
After that you're on the self-update path below.
Already have this package (@therocketcode/gsd-core) — just run /gsd-update in your session. The package coordinate is baked into the install, so a SessionStart check surfaces a banner ("GSD update available: X → Y. Run /gsd:update.") and /gsd-update pulls the new version. No special command, no reinstall.
Coming from the original upstream GSD (@therocketcode/gsd-core / get-shit-done) — its /gsd-update points at the upstream package and will never find this fork (different npm coordinate). Switch with a one-time install using the Quickstart command above. The installer overwrites the same-named /gsd-* files, re-points the baked identity at this fork (so future /gsd-update works), and the bundled legacy-cleanup removes superseded upstream hooks and stale update-check caches. After that, the self-update path applies.

Documentation

What's new in 1.7.0 → docs/whats-new-1.7.0.md

Tutorials — learning by doing:

How-to guides — task-focused recipes:

Reference — authoritative facts:

Explanation — concepts and design decisions:

Full index: docs/README.md. Other languages: 日本語 · 한국어 · Português · 简体中文.

Why it works

Most AI-coding setups fail at scale because context bloat silently degrades output quality, there is no shared memory between sessions, and nothing verifies that code actually works. GSD Core solves all three: heavy work runs in fresh subagents, structured artifacts like STATE.md and CONTEXT.md survive session boundaries, and the verify step walks through what was built and generates fix plans before a phase is declared done. See docs/explanation/context-engineering.md for the full reasoning.

Troubleshooting? See docs/how-to/recover-and-troubleshoot.md.