Summary
Queued-milestone discussion can spend too long re-reading generic project context and scouting before it gets to the actual context-writing step, even when the operator already knows the intended milestone scope.
What I observed
For queued future milestones, I could reach the queued-milestone picker and select a pending milestone successfully.
After that, the discuss flow often spent multiple turns on generic rediscovery (reading protocol files, neighboring milestone files, project files) before it got to an actionable depth check or write step.
In practice, that makes it hard to quickly enrich queued milestone contexts while the current active milestone is still executing.
Expected
There should be a fast path for queued milestone discussion when the operator already has the intended milestone scope and wants to seed or finalize the context efficiently.
Examples of acceptable behavior:
- treat provided milestone clarification as authoritative seed context
- limit scouting to only what is needed to check for obvious conflicts
- move quickly to a depth summary / confirmation / write step
Actual
The discuss flow tends to over-investigate and burns too much time on generic rediscovery before writing the queued milestone context.
Why this matters
Queued milestone discussion is most useful when done alongside an active milestone:
- current milestone keeps executing in auto mode
- future milestones get better context in parallel
That only works if the queued discuss path is efficient and respects already-supplied scope.
Notes that may help debug
This looks more like a workflow/UX issue than a parsing bug.
Relevant areas:
src/resources/extensions/gsd/guided-flow.tssrc/resources/extensions/gsd/prompts/guided-discuss-milestone.mdsrc/resources/extensions/gsd/prompts/discuss.md
A useful improvement would be an explicit mode such as:
- "Discuss queued milestone from provided scope"
- or a prompt/runtime rule that says: if the operator provides concrete milestone intent, do only bounded verification and then write the context.
Summary
Queued-milestone discussion can spend too long re-reading generic project context and scouting before it gets to the actual context-writing step, even when the operator already knows the intended milestone scope.
What I observed
For queued future milestones, I could reach the queued-milestone picker and select a pending milestone successfully.
After that, the discuss flow often spent multiple turns on generic rediscovery (reading protocol files, neighboring milestone files, project files) before it got to an actionable depth check or write step.
In practice, that makes it hard to quickly enrich queued milestone contexts while the current active milestone is still executing.
Expected
There should be a fast path for queued milestone discussion when the operator already has the intended milestone scope and wants to seed or finalize the context efficiently.
Examples of acceptable behavior:
Actual
The discuss flow tends to over-investigate and burns too much time on generic rediscovery before writing the queued milestone context.
Why this matters
Queued milestone discussion is most useful when done alongside an active milestone:
That only works if the queued discuss path is efficient and respects already-supplied scope.
Notes that may help debug
This looks more like a workflow/UX issue than a parsing bug.
Relevant areas:
src/resources/extensions/gsd/guided-flow.tssrc/resources/extensions/gsd/prompts/guided-discuss-milestone.mdsrc/resources/extensions/gsd/prompts/discuss.mdA useful improvement would be an explicit mode such as: