Welcome to the GSD starship !

From how I learned from the GSD engine code - strategy the answer sounds like this for you - @Lex Christopherson correct me if I am wrong : GSD is designed for linear progression—one milestone, one phase at a time. Here's why and how to work around it: 1. Milestones: One at a time STATE.md and ROADMAP.md track your position. Multiple active milestones would create state confusion. The system assumes: define → build → ship → next milestone. 2. Phases: Sequential by design Same reason—state tracking. Each phase builds on the previous (research informs planning, planning informs execution). BUT—your use case is valid. While Claude runs long tasks, you want to make progress elsewhere. Workarounds: - Use /gsd:add-todo — Capture ideas, decisions, requirements for future phases/milestones. Pull them in later when that phase starts. - Run /gsd:discuss-phase N ahead — Discussion is mostly human input. You can do it early, creates {phase}-CONTEXT.md. Just don't execute out of order. - Keep notes outside .planning/ — Draft your thoughts in a scratch file, feed them into GSD when the phase becomes active. TL;DR: System is linear, but discuss/interview phases are low-risk to do ahead since they're capturing your decisions, not changing code. Just don't run execute phases out of order.

The issue is only the STATE.md that is updated by both actions, if you run in paralel this scenario - it can be corrupted.GSD is not made for paralelism - Solution is discuss-ahead as I analyzed. It is perfect to Get the shit done no ? :)

Worth raising as a GitHub issue. Simple to implement, high value for TDD/quality-focused devs. what you say @Lex Christopherson ?

Great observation! GSD actually works fine for teams today with a simple setup: Solution: 1. Set commit_docs: false in .planning/config.json 2. Add .planning/ to .gitignore Each dev keeps their own local GSD state. Git only tracks the code, not the planning files. PRs merge code—coordination happens through code reviews, not GSD state sync. Workflow: ∙ Each dev works on their branch with their own .planning/ ∙ GSD commits only code (atomic commits per task) ∙ PR review → merge code ∙ After merge, each dev updates their local roadmap as needed GSD stays a personal productivity tool per-dev. Git remains the source of truth for code. No merge conflicts, no new features needed. The “state merge” idea is interesting for the future, but honestly—keeping planning local and code shared might be the simpler, cleaner pattern anyway. Maybe in future can be done there are few solutions for more devs each one with his folder of files or some other directions . But the tool Is cooking ! Amazing