What Open GSD is, the Git-Ship-Done loop for coding agents
Open GSD[1] is an open-source toolkit for steering coding agents (Claude, Copilot, Cursor and friends) without losing the thread of a project. The name sums up its method: "Git. Ship. Done." This article covers the problem it tackles, how its workflow loop works, and how mature it actually is, because not everything it promises ships today.
Key takeaways
- Open GSD fights context rot: the quality drop an agent suffers as its context window fills up.
- It structures work into five repeating steps: discuss, plan, execute, verify and ship.
- The heavy work (research, planning, execution) runs in fresh-context subagents so the main session stays lean.
- The core is two mature pieces:
gsd-core, a workflow engine for your editor, andgsd-pi(version 1.5.0), a standalone terminal agent. - It is free software under the MIT license and installs from npm.
The problem it solves
Anyone who has run an agent through a long session knows the pattern: it starts sharp and, as its context window fills, it begins to forget decisions, repeat work or wander off. The docs call this "context rot." It is not a one-off glitch, it is the cost of piling too much information into a single conversation.
Open GSD starts from that observation. Instead of cramming everything into one session, it splits work into phases and runs each task in a subagent that starts with a clean context. The session you talk to stays light; the heavy lifting happens elsewhere and comes back summarised. The site puts it this way:
"Open GSD keeps agentic work from dissolving into context bloat: explicit plans, clean execution contexts, real verification, and git history that tells the truth." — opengsd.net
The workflow loop
The method runs five steps that repeat for each project phase:
- Discuss: capture implementation decisions before anything is planned.
- Plan: research, decompose the task, and check the plan fits a fresh context window.
- Execute: plans run in parallel waves and each executor starts with a clean context.
- Verify: walk through what was built, diagnose and fix before declaring anything done.
- Ship: open the pull request, archive the phase and move to the next.
If that sounds familiar, it is the same discipline behind other skills-and-subagents patterns. What Open GSD adds is packaging it with more than 60 ready-made commands.
The tools
The project splits into several pieces and, by mid-2026, most are usable (not just a couple, as at the start):
| Piece | What it is | Status |
|---|---|---|
gsd-core |
The workflow engine for your editor: research, plan, execute, verify and ship | Available |
gsd-pi |
The standalone terminal agent (version 1.5.0): Git worktrees, project memory under .gsd/, and an optional web UI |
Available |
gsd-browser |
Deterministic browser automation, with assertions and traces | Available |
gsd-cursor |
A plugin for the Cursor marketplace | Available |
gsd-cloud |
A hosted workspace, with a daemon that runs on your machine | In development |
gsd-pi is the fastest way in: it is described as a meta-prompting, context-engineering and spec-driven development system, and it routes whichever model provider you configure. Try it with a single command:
npx @opengsd/gsd-pi@latest
My take
I like the approach, partly because it is the one we already follow here: if you have built an agent with the Anthropic SDK or a RAG on Postgres, you know the bottleneck is not the model, it is holding focus for hours. Isolating each task in a worktree and its own context is sensible and hardly new, but having it packaged with commands and project memory saves real work. I tried it on a small project, and the difference shows most on long sessions: the plan is written down and each executor starts fresh, so you are not constantly reminding the agent what was already decided.
The honest part: although the catalogue has grown, the core is still gsd-core and gsd-pi, and it assumes your team already has access to a model provider, because Open GSD routes whichever one you give it rather than bundling its own. For small, one-off changes the ceremony is overkill; for long agent sessions it earns its place.
Frequently asked questions
How is it different from just using an agent?
A plain agent keeps everything in one conversation, which degrades as it fills. Open GSD splits the work into phases and runs each task in a subagent with a clean context, so the main session never saturates. In exchange it adds structure: for a small change it can be overkill.
Does it cost anything?
No. gsd-core and gsd-pi are free software under the MIT license and install from npm. What you do need is access to a model provider (OpenAI, Anthropic or another), because Open GSD bundles none of its own.
Which editors and agents does it fit?
gsd-core plugs into your editor and gsd-pi lives in the terminal, so it works with Claude, Copilot, Cursor and whatever flow you already use. The gsd-cursor plugin also brings it to the Cursor marketplace.
Conclusion
Open GSD does not invent a new technique, it brings order to one that already works: plan small, execute in clean contexts, and verify before closing. With an MIT license and a one-command install, the cost of trying it is low. It is worth a look if you work with coding agents day to day.
