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 five pieces and, by mid-2026, four 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. It also 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.
