GSD · open-gsd, the community continuation of TÂCHES’ original · as of September 30, 2026
In GSD, the session you talk to never touches the code
AI output gets worse as its context window fills. GSD’s answer is to keep your conversation lean and the plan on disk, and to hand every piece of research, planning, building and checking to a fresh agent, so one person can build a whole product over days without the AI losing track of what was decided.
This guide is written by EnsoDynamics, which makes the Enso Method. We compare our method with others as fairly as we can, and we recommend another method when it fits you better.
Two philosophies at a glance
GSD
Beat context rot by keeping the plan on disk and giving every step a fresh agent, so one founder can build a whole product phase by phase.
The Enso Method
Plan the whole product too, but for the people who decide, wherever they are, with requirements kept true for the life of the system.
Where they differ
- The developer at the keyboard decides Someone who isn’t at the keyboard decides GSD sits at the “The developer at the keyboard decides” end; the Enso Method sits at the “Someone who isn’t at the keyboard decides” end.
- Specs serve one change Specs live as long as the system GSD sits in the middle; the Enso Method sits at the “Specs live as long as the system” end.
- Stops and asks Decides, records it, keeps going GSD sits in the middle; the Enso Method sits at the “Decides, records it, keeps going” end.
- Passing tests are enough Every requirement proven against real systems GSD sits toward “Every requirement proven against real systems”; the Enso Method sits at the “Every requirement proven against real systems” end.
What they share
- One change at a time The whole body of work up front GSD sits at the “The whole body of work up front” end; the Enso Method sits at the “The whole body of work up front” end.
- Starts from a prompt Intent written down first GSD sits at the “Intent written down first” end; the Enso Method sits at the “Intent written down first” end.
Neither end of a line is the right one. Every comparison uses the same lines, so you can compare across methods.
A fresh mind for every task
“This is not a workaround for context rot. It is a structural solution.” GSD’s design notes name the problem it was built around: as a session fills up, the model quietly contradicts decisions it agreed to and forgets requirements stated an hour ago.
So in GSD, “the orchestrator — your main session — never touches source files.” It spawns a researcher, a planner, a plan checker, builders and a verifier, each starting clean with only what its task needs. Their decisions go into files, so the next agent, or tomorrow’s session, reads them instead of remembering them.
Around that sits a clear view of who it is for. GSD plans “for ONE person (the user) and ONE implementer (Claude)”, and deletes anything that “sounds like corporate PM theater”. Its original author: “I’m a solo developer. I don’t write code — Claude Code does.”
One roadmap, then a loop per phase
- Define the project. GSD asks what you want to build, researches the domain, writes requirements with IDs, and maps every one to exactly one phase of a roadmap.
- Discuss. Before each phase it finds the “gray areas” and asks how you want them handled.
- Plan. Fresh agents research, plan and check. Every requirement and every decision you made must appear in a plan.
- Execute. Plans run in parallel waves, each builder in its own clean context and git worktree, committing task by task.
- Verify and ship. A separate verifier checks the goal against the code, you test what it can’t, and GSD opens the pull request.
The builder’s rule shows what using it is like: “Users NEVER run CLI commands. Users ONLY visit URLs, click UI, evaluate visuals, provide secrets.”
Built for a founder with a product in their head
GSD fits someone who owns the idea and wants a whole product built in phases over days or weeks. You can steer each phase, or run /gsd-autonomous and let it work through every remaining phase on its own.
Its makers name the price: the phase loop “introduces real friction”, and parallel agents cost more than one. Users say the same, most often about tokens; for small changes it offers /gsd-quick and /gsd-fast. It suits you less if other people make the product decisions, or if you need help past the pull request.
Where the Enso Method made a different call
The two share more than most pairs: both define the whole body of work before building, cut it into slices that each get a fresh context, and keep decisions in files rather than chat. They part ways on three things.
Who answers the questions research can’t settle
GSD
You do. Before each phase it asks about the choices that “could go multiple ways”, or, in autonomous mode, proposes answers for you to accept.
The Enso Method
It researches, picks the best-supported answer, and sends business questions to their owners as written proposals while the build continues.
Choose by situation: if you are the founder, GSD keeps every call yours. If the people who decide aren’t in the chat, the Enso Method keeps building without them.
What the requirements are for
GSD
“All Active requirements are hypotheses until shipped and validated.” Each milestone’s requirements are archived when it closes, and a short project summary carries on.
The Enso Method
The requirements and design are the source of truth, amended before every change, for the life of the system.
Choose by situation: GSD’s documents stay light and never go stale. The Enso Method’s take upkeep, and pay off when someone asks, years later, what the system is supposed to do.
What proves a phase works
GSD
A verifier that distrusts the builder’s report checks the code, then walks you through what it couldn’t prove: “Here’s what should happen. Does it?”
The Enso Method
Every acceptance criterion needs a test, and integrations are proved against real systems, not mocks. Your part is reading the diff.
Choose by situation: GSD puts your own eyes on the product every phase. The Enso Method aims for proof that holds when you aren’t there to click.
Where GSD shines
- A whole milestone from one command.
/gsd-autonomousdiscusses, plans, builds and verifies each phase, then closes the milestone. On Claude Code, the Enso Method needs you to start each phase. - Nothing silently dropped. Every requirement maps to a phase, every decision to a plan, and gates stop when one goes missing.
- A verifier built to doubt. It treats the builder’s summary as a claim, and marks behavior no test exercised as unproven rather than passing it.
- Existing codebases. It maps an unfamiliar repo into seven documents before planning. The Enso Method has no equivalent.
How the Enso Method differs, and why
GSD and the Enso Method both plan the whole body of work before building; they differ on who is in the room. GSD is built for a founder who answers each phase’s questions and tests the result. The Enso Method is built for building software for other people: open questions go to their owners as written proposals while the build continues, the requirements are kept current for the life of the system, and each requirement is proven by tests against real systems.
Get started
GSD Core is free and open source (MIT) and runs in Claude Code, Codex, Cursor, Copilot, OpenCode and about a dozen other agents. Install it with npx @opengsd/gsd-core@latest, not the older, deprecated get-shit-done-cc package; instructions are in the README at github.com/open-gsd/gsd-core.