What's New in GSD: March 2026
Autonomous pipelines, cross-AI review, UI design contracts, workstreams, and a recommended workflow — the highlights from GSD v1.23 through v1.28.
GSD shipped six minor releases in three weeks — v1.23 through v1.28. I went through the changelogs so you don’t have to. If you’re new to GSD, start with the original post for how the system works, or the follow-up for verification layers and edge cases. This post covers what changed since.
Advancing through phases
Before v1.23.0, the --auto flag on /gsd:discuss-phase had a bug: it chained the entire discuss → plan → execute pipeline for a single phase. That was convenient — you could discuss a phase, walk away, and come back when the next discussion was ready. But it was unintentional, and the flag’s actual purpose is simpler: skip interactive discussion questions by picking recommended defaults.
/gsd:autonomous was introduced in this period, but it’s not a direct replacement for the old chain behavior. Autonomous runs all remaining phases end-to-end — but it doesn’t stop at discussion points. Instead, it handles discussions for you via “smart discuss,” which presents grey area decisions as batch tables where you accept recommendations or override individual questions. That’s useful if you want to hand off everything, but it means you’re not driving the discussions yourself.
If you want to discuss each phase interactively and then let planning and execution run, there’s no single-command replacement for the old chain behavior yet. After discussing, you run /gsd:plan-phase N then /gsd:execute-phase N, and come back for the next discussion when execution finishes.
Discussion improvements
The discussion phase picked up three flags that make it more configurable.
--analyze adds a trade-off analysis table before each question — two or three options with pros, cons, and a recommended approach based on codebase context. Useful when you want to make an informed decision without researching the options yourself.
--batch groups questions into batches of two to five instead of asking them one at a time. The default is single questions, which explains why discussions can feel slow. You can specify the batch size with --batch=N, or let it default to four.
--text replaces interactive menus with plain-text numbered lists. Required for remote SSH sessions where the TUI menus don’t render, but also useful if you just prefer typing numbers.
UI pipeline
GSD now has frontend-specific workflow stages. /gsd:ui-phase runs after discussion but before planning — it generates a UI-SPEC.md design contract that locks spacing, typography, color, and copywriting decisions before the planner creates tasks. This prevents the ad-hoc styling decisions that lead to design debt during execution. A researcher agent reads upstream artifacts and a checker agent validates the spec against six quality dimensions.
The scope is per-phase, not per-project — each frontend phase gets its own UI-SPEC.md. GSD automatically recommends running it when it detects a UI-heavy phase, so you don’t have to remember which phases need it.
/gsd:ui-review runs after implementation. It’s a retroactive six-pillar visual audit of the implemented frontend code, producing a graded assessment scored one through four per pillar — catching the gap between what was specified and what was actually built.
Cross-AI review
/gsd:review invokes external AI CLIs — Gemini, Claude (in a separate session), or Codex — to independently review your phase plans. Each produces structured feedback compiled into REVIEWS.md, which you can feed back into planning with /gsd:plan-phase --reviews. An interesting approach to catching blind spots: the same plan reviewed by different models with different strengths and failure modes.
Workstreams
GSD already runs tasks in parallel within a phase — waves handle that. But in a single roadmap, you can only be at one lifecycle stage at a time: discussing, planning, or executing a given phase. You can’t discuss the dashboard approach while the API is mid-execution.
/gsd:workstreams adds lifecycle-level parallelism. Each workstream gets its own roadmap, requirements, state, and phases — while sharing the project-level config and codebase map. One Claude Code instance can be in discussion for the dashboard workstream while another is executing the API workstream. Separate conversations, separate plans, separate progress. The lifecycle: create a workstream, switch to it, run the normal GSD workflow, and complete when done to archive it. All GSD commands accept the --ws <name> flag, and the scope chains automatically through the workflow.
Workstreams share the same git working tree, so if two workstreams modify the same files, you’ll deal with conflicts like any parallel development. Where this works well is when the workstreams cover different areas of the codebase — a backend API and a frontend dashboard, a v1.1 feature set and an urgent bugfix release, or an experimental refactor that you want to track without blocking the main roadmap.
For multi-repo projects there’s a separate concept: /gsd:new-workspace. It creates a directory containing git worktrees (or clones) of multiple repos, with a single .planning/ directory managing all of them as one GSD project — one roadmap, one set of phases, one orchestration across repos. Workstreams are for parallel work within one repo. Workspaces are for pulling multiple repos into one managed project.
Capturing ideas: notes, todos, and seeds
It turns out /gsd:add-todo is more useful than it looks. Todos are cross-referenced during discussion — the discuss-phase workflow matches pending todos against the current phase’s scope and surfaces relevant ones automatically.
/gsd:note is the zero-friction layer below todos. Notes are timestamped files you can list or promote to structured todos when you’re ready. They’re not consumed by other workflows — they’re a scratch pad.
/gsd:plant-seed goes further. Seeds are forward-looking ideas with trigger conditions — “surface this when we start the notifications milestone” or “revisit when the auth rewrite is done.” /gsd:new-milestone scans seeds and presents matches when trigger conditions are met. Seeds don’t rely on you remembering to look at them.
The three serve different purposes: notes are standalone capture. Todos are automatically cross-referenced during discussion. Seeds are automatically surfaced at milestone boundaries. Each step up the ladder is more integrated into the GSD process.
Working outside the roadmap
The original post covered debug, quick, insert-phase, and verify-work for work that doesn’t fit the main workflow. The spectrum has filled in since — and the interesting part is how it scales.
/gsd:fast is zero process. No subagents, no plan files, no state tracking. Pass it a task description and it does the work inline. Typo fixes, config changes, small refactors.
/gsd:quick spawns a planner and executor with atomic commits and state tracking. The flags are what make it interesting: --discuss adds a discussion phase, --research spawns a research agent, and --full enables plan checking and verification. Despite the name, --full doesn’t include discussion or research — each flag is independent. Stack all three with quick --discuss --research --full for the complete GSD pipeline on a task that doesn’t belong in your roadmap.
/gsd:debug is for when something is broken. It runs a systematic investigation using the scientific method — gathering symptoms, forming hypotheses, testing them — with persistent state that survives /clear so you can resume across context resets.
/gsd:insert-phase adds unplanned work as a decimal phase (e.g., 6.1) between existing phases when the work does belong in the roadmap.
/gsd:map-codebase spawns four parallel agents that produce seven structured documents about your codebase: stack, architecture, structure, integrations, conventions, testing, and concerns. /gsd:new-project already offers to run this when it detects existing code, but it’s also a standalone command — useful after significant changes or when GSD’s understanding feels stale.
Shipping
/gsd:ship handles the PR lifecycle end-to-end: checks that verification passed, pushes your branch, generates a PR body from the planning artifacts, and creates the PR via gh.
How branches get created is controlled by the branching_strategy setting. none (the default) keeps everything on whatever branch you’re on. phase creates a branch per phase automatically. milestone creates one branch for the entire milestone.
GSD commits planning artifacts to git by default (commit_docs: true), which means your PRs will include .planning/ file changes alongside code. For private repos or teams that want the planning trail in the repo, that’s fine. If you’d rather keep planning local, set commit_docs: false and gitignore .planning/ — your branches and PRs stay clean, and planning lives on your machine only.
There’s also /gsd:pr-branch, which creates a clean branch by filtering out planning-only commits. For most workflows, committing planning to the repo or keeping it local covers the need — but pr-branch exists if you want both planning in git and clean PR diffs.
When things go wrong
/gsd:forensics is a read-only post-mortem for when a workflow fails. It analyzes git history, .planning/ artifacts, and file system state to detect anomalies like stuck loops, missing artifacts, or crash interruptions. Every finding is grounded in evidence.
/gsd:health --repair checks .planning/ directory integrity and fixes what it finds — missing files, invalid configurations, orphaned plans. Useful when things feel off structurally but nothing has actually failed yet.
Between sessions
/gsd:pause-work creates a .continue-here.md handoff file capturing your complete work state — current phase, what’s done, what’s remaining, active decisions, and blockers. It commits everything as WIP so nothing is lost.
/gsd:resume-work picks up where you left off. It restores context from STATE.md and any checkpoints, shows you where things stand, and routes to the next action. Useful when you come back the next day, switch machines, or start a fresh context window mid-phase.
Convenience commands
/gsd:do is a natural language router — describe what you want and it dispatches to the right command. Useful when you know the intent but not which slash command handles it.
/gsd:next reads your project state and invokes whatever comes next. Useful when you’re switching between projects and don’t want to check where you left off.
Six releases in three weeks is a lot to keep up with. I wrote up a recommended workflow that reflects all of these additions — I’ll keep it updated as things change.
Written with AI assistance. How that works →
Found this useful?
Get notified when I publish something new. No spam, unsubscribe anytime.