My Thoughts on GSD 2

[TigerTugger]

Want to preface by saying a few things:

• I am incredibly grateful for everyone spending their personal time contributing to this project. Seriously. I had absolutely no experience coding other than a couple of comp sci classes in high school and learning through setting up my NAS / VPS / Domain / SMTP/Media libraries / other Unraid stuff. Everything was and still is though just trial and error and breaking and fixing things until somehow it all works out. GSD opened up an entirely new world for me. It allowed me to develop things at an entirely different scale, I went from small simple tasks to building out an entire operating system for my firm- CRM + task management + portfolio management + research section. I've spent 6+ hours a day at least with GSD for the last month or two doing both personal projects and professional projects. Many of the projects are live and being used by myself and many close friends / colleagues daily. I still can't write a line of code.

• I’m not sure what the breakdown is in terms of people with needs closer to mine vs actual developers who operate on a different level. I acknowledge that I am almost certainly in the minority, and a lot of my "issues" are probably user error / my own lack of understanding about how to properly use GSD 2.

• I know GSD 2 is brand new, I'm sure a lot of this is in progress. After watching how GSD 1 evolved I'm sure the devs will get there. I think I see the vision- I was very excited when I saw that GSD had launched and read through the docs. It seemed like a substantial improvement and addressed a lot of problems I ran into with GSD 1. In practice though, at least for me, it's been pretty rough. I wanted to share a few of my issues in case there are others out there struggling with the same stuff / maybe spark a few ideas.

---

My preferred way to work with GSD 1 was with two terminals: essentially an “admin” and an “execution” terminal. I got to this point by realizing that I could progress much faster through phases by discussing the next phase while planning/executing in my execution terminal. Then I realized that I could started managing my todo list, adding new phases, doing bugfixes, using gsd:quick, etc in my second terminal. I understand that there are probably some issues with this revolving around git history. I spent quite a few hours learning more about how git actually worked (mostly due to GSD 2 originally launching to worktree mode by default, me not understanding what that meant, and me making an absolute mess of things haha). A clean git history though wasn't an issue for me. My projects still worked. I would just get my "admin" agent to resolve whatever conflicts were created through a discussion.

Swapping to "none" isolation mode on 2.44 mostly fixed my issues. Then 2.46 came along and completely broke my workflow. I know the idea for this two terminal approach with GSD 2 was there: the docs explicitly call out using /steer etc in a second terminal. The idea of reinforcement is great: with my old workflow, I often had to remember to confirm / get my admin terminal to document what had been done. This could particularly become an issue when the agent directly made changes instead of through skills, but GSD 1 got to a point with gsd:do routing / all of the other commands that were added that it rarely ever caused any real problems. I'm sure a lot of the stuff might not have been "properly" documented and a little bit of reinforcement would have been nice, but in practice after clearing context 99% of the time agents were able to figure everything out quickly.

1. Could some way to “unlock” a terminal from the reinforcement framework be created? I want to go back to having discussions / having a chat with some GSD framework in place but not being forced into the /gsd auto path. I think the GSD devs had this idea- they even mentioned the two terminal workflow with /steer etc, but this is much more limited to what I was able to do in my second terminal in GSD 1. Best of both worlds would be the GSD 1 flexibility combined with a bit more of the “make sure to always document what you do according to these protocols even if the agent does it directly / outside of a specific tool.”

2. Is there some way to migrate back to pre-2.46, or back to gsd 1? 2.47 modifies some files that throws a conflict when reinstalling and trying to run .45. I can't figure out what the implications exactly are to deleting those files, or if 2.45 will even run after those modified files are deleted.

I see the vision with the auto mode, I used it for two days and got a lot done, but I really did get a lot of value out of the old interaction / discussion steps. A lot of the times I have a general idea for a new feature. I often don't have the framework to explain exactly what I'm looking for, or what is technically possible. The discussion feature allowed me to explain the goal, and helped me personally clarify what I would actually want and what was feasible.

3. I know the discuss phase exists in GSD 2, or at least there is a command for it, but I can't figure out how to get auto mode to stop if no discussion exists. I was able to just use the /gsd next command step by step and then manually do the discussion before the next milestone started, but then I have to very closely watch the auto process and it kind of defeats the point.

Maybe it’s just my misunderstanding, but I used the old todo system a ton. The capture / triage is a cool idea, but I used todo’s to essentially document everything I wanted to do. Notice a typo? Todo. Small feature idea? Todo. Large feature idea? Todo. Bugfix I notice? Todo. I would then use the gsd:do routing command (absolute gold) and essentially say “let’s look at my todo’s and knock some of them out.” Sometimes I would create entirely new phases or milestones, sometimes they could just be handled with GSD:quick. With the capture/triage, a bunch of stuff is just considered out of scope of the current milestone and deferred until some undefined point in the future. This is a problem for me because a lot of the things might be very small bug fixes or things I notice that I want immediately implemented because they’re huge QOL. Most of my projects are things I actually use to make my life better on a day to day basis.

4. I don't understand why triage resolves things that are deferred when they haven't actually been done. Maybe I'm just misunderstanding how to use capture/triage, but I don't at all like adding items and not having any control over when they are done. The automated /triage and slotting the items automatically into a future milestone is great, but I wish there was either a classification to assign for things to be handled immediately or some way to manually trigger one of the items being done and then marked as complete.

5. Is it possible to add some command to trigger immediately handling a captured item? Ideally, a batch of them at a time. One thing I was thinking of trying is just creating a very broad "milestone" with the plan / scope of "work towards the goal of handling all outstanding capture items" and then using gsd:quick to assign the various items to that milestone. Not sure whether or not the capture would be marked as completed though after they are done.

6. Is it possible to insert a discussion phase into the /triage command so that I can have some control over what is handled immediately vs deferred?

[mavuio]

Regarding todos, you can always add any pi extension to gsd:

https://pi.dev/packages

this is how I will solve this issue for me

[TigerTugger]

That's huge, thanks so much for sharing. It's funny, I was watching a video a couple of days ago about how flexible pi.dev was, but I guess I didn't put the pieces together that GSD 2 would share the flexibility. I'll explore what packages exist and play around with some customization.

[mavuio]

I think I’ll
just use beans cli and tell the agent to use it

https://github.com/hmans/beans

I used it for agents tracking their work ( not needed with gsd)

, now I’ll use it for tracking my todos in the workspace

[thlandgraf]

The auto-mode-should-stop-without-explicit-sign-off pain (your Q3) is the gap I've been working on from a different angle. The pattern that's worked for me: rather than adding a new pre-auto checkpoint command, treat the spec entity itself as a state machine — every requirement has a status field (draft / review / approved), and the executor refuses to act on anything not in approved. The discussion happens during the review→approved transition because nothing else is allowed to consume it. No second terminal, no /steer, no special command — the status is the gate.

Your capture/triage concern (Q4-6) has the same shape if you flip the model: instead of items being "deferred to some undefined future milestone," they're draft by default and you bulk-approve a subset to let the agent pick them up. That gives you the "handle these immediately" control you're after without inventing a new command — it's just status transitions on existing entities.

Disclosure: I'm the creator of SPECLAN — a VS Code extension that implements this pattern (Goal → Feature → Requirement tree, Markdown files with YAML frontmatter, status lifecycle that gates the AI). Not a GSD replacement, different layer entirely. But the status-as-gate idea works without any specific tool, and as a primitive it might be simpler than per-command flags. https://speclan.net if you want to see how it composes.

[trek-e]

Good call — pi extensions are exactly the right path for todos and other task management features. The extension system is designed so these don't need to live in core GSD-2. pi.dev/packages has a growing catalog.