GSD: Running Phases in Parallel

The default GSD workflow is sequential: discuss a phase, plan it, execute it, move to the next. But GSD supports running phases in parallel at the system level — and the guardrails that make this safe are built into the architecture, not into any single command. This post covers what runs in parallel, what doesn’t, and why. If you’re new to GSD, start with the original post and What’s New for context.

The lifecycle stages

A quick recap. Each phase goes through three stages:

1. Discuss — interactive session where you make design decisions. Produces CONTEXT.md.
2. Plan — autonomous agent that creates task breakdowns. Produces PLAN.md files in .planning/phases/XX/.
3. Execute — autonomous agent that implements the plan. Modifies codebase files and commits.

In the default workflow, these run one at a time: discuss phase 1, plan phase 1, execute phase 1, discuss phase 2, and so on. But each stage has different isolation requirements, and GSD enforces those independently.

How each stage handles parallelism

Not all stages are created equal. Each has a different isolation mechanism — or deliberately lacks one.

Discussions: sequential

Only one discussion runs at a time. GSD enforces this with a sliding window: only the next undiscussed phase is surfaced, regardless of how many phases are ready. This is intentional — discussions are where you shape the approach, and splitting your attention across multiple phase decisions at once leads to worse outcomes.

Planning: parallel, directory-isolated

Multiple planners can run simultaneously. They don’t need git worktree isolation because planners don’t touch codebase files — each one writes PLAN.md, RESEARCH.md, and related artifacts to its own .planning/phases/XX-name/ directory. Two planners running for different phases write to different directories with no overlap.

Execution: parallel, worktree-isolated

Executors modify codebase files, so they need real isolation. Each executor spawns in its own git worktree — a separate working directory backed by the same git object database. This means two executors can modify different files without interfering with each other’s filesystem state.

Within a phase, plans are grouped into dependency waves. Waves execute sequentially. Agents within a wave run in parallel, each in their own worktree. Cross-plan dependencies are verified before each wave starts — if a wave-2 plan references an artifact from wave 1, GSD checks that it actually exists before proceeding.

Parallel executors commit with --no-verify to avoid pre-commit hook contention (think cargo.lock or package-lock.json races). The execute-phase workflow validates hooks once after all agents in a wave complete. Commits from different worktrees land on the same branch and auto-integrate — no manual merge step.

Dependency awareness

GSD checks phase dependency relationships before allowing parallel work. If phase 3 depends on phase 2, it won’t allow executing both simultaneously — phase 3 waits until phase 2 completes. Independent phases run freely.

This applies across stages too. You can plan phase 5 while phase 3 is executing, as long as 5 doesn’t depend on 3. The dependency graph filters what’s safe to run in parallel, so only independent work overlaps.

---

There are two ways to run phases in parallel. You can do it yourself — open separate terminals, run /gsd:plan-phase 5 in one while /gsd:execute-phase 3 runs in another — and the guardrails described above keep things safe. Or you can use /gsd:manager, which presents a dashboard and compounds parallel actions into a single dispatch, but comes with tradeoffs: no control over discussion flags, context accumulation from inline discussions, and a tendency to skip optional workflow steps. Either way, the system-level guardrails — sequential discussions, directory-isolated planning, worktree-isolated execution, and dependency-aware scheduling — apply.