Most AI workflow tools want my one-person project to cosplay as a fifty-person engineering org. Sprint ceremonies. Story points. Stakeholder syncs. Retrospectives that nobody reads, written for a "team" that is me and a laptop.
Get Shits Done, by TÂCHES, is the first one I have used that starts from the opposite assumption. The name is a joke and the joke is the positioning: you are one person, you want the thing built, you do not want to run a software company on the side. What it actually ships is a set of slash commands that force your work through spec files on disk before a single line gets written.
I care about it for one reason, and it is not the vibe. It is the only workflow I have tried that treats context rot as an architecture problem instead of a prompting problem.
What context rot actually is
Here is the failure I keep hitting, and I suspect you have hit it too.
Hour one with a coding agent is great. It reads your files, it asks good questions, it writes code that matches your conventions. Hour four is a different model wearing the same name. It forgets a decision you made ninety messages ago. It re-introduces a bug you fixed together. It starts hedging and summarising, telling you what it "would" do instead of doing it. Nothing crashed. The output just quietly got worse.
That is context rot. As the window fills, the useful stuff competes with transcript sludge: tool output, retries, files you opened once, your own thinking-out-loud. The decisions that should be load-bearing sit somewhere in the middle of that pile, and the middle is exactly where attention is weakest.
The tempting fix is a bigger window. That has not worked for me. A bigger window means the same rot arrives later and hits harder, because by the time quality drops I have twice as much unrepeatable conversation to lose.
The workaround is boring: write it down
If the transcript is the thing that rots, stop using the transcript as memory.
That is the whole trick, and it is old. We already solved this for humans. A team does not keep its architecture in one person's head, it keeps it in a doc, because people leave, forget, and go on holiday. An agent forgets every time the window turns over, which is a lot more often than a holiday.
So, GSD makes you produce files: PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md at the project level, then a CONTEXT.md per phase, then plans small enough that one of them fits comfortably in a clean window. Each execution reads the files it needs, does its slice, writes what changed, and dies. Nothing important is stored in a place that decays.
If your agent's memory is the chat log, your project's memory is the chat log. That is the bug.
The loop, command by command
Four commands carry most of the value for me.
There are more commands than this, and honestly I do not use most of them. /gsd:execute-phase runs the plan, /gsd:verify-work checks it, /gsd:progress tells me where I stopped. The rest are ceremony I have not needed yet as one person.
What the plan file has to carry
The difference between a roadmap line and an executable plan is not length, it is whether a stranger could do the work from it. The agent in a fresh window is exactly that stranger.
Phase 2: add auth
Phase 2a: email + password auth decided in discuss-phase: - sessions in an http-only cookie, no localStorage - no social login in v1 (I do not want the consent screens yet) - password reset is phase 2b, out of scope here done when: - sign up, sign in, sign out work end to end - a signed-out user hitting a private route lands on /login - the failing-password test exists and passes
Everything in the right-hand column is a decision I made once. Written down, it costs me nothing to re-supply. Left in the chat, it costs me the whole conversation.
How small is small enough
"Atomic" is the kind of word that sounds like a rule and behaves like a vibe, so here is the version I actually use. A plan is small enough when I can name the finished state in one sentence and list the files it touches on one hand. If I cannot, it is two plans and I have not found the seam yet.
The tell that I got it wrong is always the same. Halfway through execution the agent starts asking me questions that should have been answered in CONTEXT.md, or it goes off and refactors something adjacent because the plan gave it room to. Room in a plan is not freedom, it is ambiguity, and a fresh window fills ambiguity with whatever seems reasonable at the time.
STATE.md is the piece I underrated at first. It is the resume point: what phase I am in, what is done, what is next. It sounds like bookkeeping and it is, but it is the file that lets me close the laptop mid-project on a Tuesday and start again on Saturday without re-deriving my own plan from memory. Before this I would open an old project, read my own code for twenty minutes, and guess at what past me had intended.
The tradeoff nobody advertises
This is not free, and the pitch usually skips the invoice.
You pay up front. The interview before new-project is long. discuss-phase will interrogate you about a phase you thought was obvious. For a two-hour throwaway script the overhead is worse than just talking to the model, and I do exactly that for throwaway scripts.
You also pay in fluency. When the state lives in files, you cannot say "no, the other one" and be understood. The system knows what is written down. If a decision only ever happened out loud, it is gone at the next window boundary, and you get the confident wrong answer that comes from a plan missing a constraint.
Two opposite bets
I wrote about Superpowers a while ago, and the two systems are worth holding side by side, because they answer the same question in opposite directions.
Superpowers keeps things in context and structures them with skills, so the model always has the relevant expertise loaded. GSD keeps almost nothing in context and pushes state onto disk, so the model starts clean every time. One bets on better contents, the other bets on a smaller window.
My read: they are not really rivals. Skills describe how to do a kind of work, specs describe what this particular work is. I would happily run a skill inside an execution window that GSD scoped for me. What I would not do is run a long unstructured session and expect either of them to save it.
The thing both of them agree on, and this is the part I think matters beyond either tool, is that reliability is coming from structure now, not from prompt wording. I have stopped tuning sentences. I spend that time deciding what gets written to a file.
What I still don't know
Honest answer: I have not run this on anything big enough to stress it. My projects are small, solo, and mine, which is the case GSD is built for, so of course it feels good. I do not know how the spec files behave with two people editing them, or over a codebase old enough to have opinions of its own, and I have not measured token cost against just talking to the model.
What I do know is the failure I stopped having. I have not lost an afternoon to an agent quietly forgetting the plan since I started doing this, and that was happening to me weekly.
If you want the other side of the argument, my write-up of Superpowers covers the keep-it-in-context approach, and Soul.md covers the identity-file version of the same instinct.