Phase Sizing

#The Granularity Dial

GSD supports coarse granularity (1-3 plans per phase, bigger phases) and fine granularity (5-10 plans per phase, smaller phases). Neither is universally correct — the right size depends on the complexity and familiarity of the work.

The granularity dial controls how much context each plan execution consumes and how quickly you can recover if a plan goes wrong.

#Coarse Granularity — When It Works

Best for:

• Familiar patterns you’ve done before — “add a CRUD endpoint” when you’ve done many. The planner can write specific, actionable tasks without research.
• Small, well-understood features with no architectural unknowns. You know the shape of the solution before planning starts.
• Work where action sections are focused — if a task’s action fits in one paragraph, the executor can complete it at peak quality within the context budget.

Rule of thumb: if a plan’s action section fits in one focused paragraph, coarse is fine.

#Fine Granularity — When It’s Worth It

Best for:

• Architectural decisions with long-term consequences — authentication strategy, data model design, service boundaries
• New domains where the planner needs research before it can write accurate tasks
• Work touching multiple independent subsystems — the interactions between subsystems create complexity that benefits from explicit plan boundaries
• Any phase where a mistake in plan 01 would invalidate plans 02-05 — finer granularity means smaller mistakes with smaller blast radius

#The 2-3 Task Rule

Each plan should have 2-3 tasks. If a plan has 5+ tasks, it’s two plans. If a plan has 1 tiny task, it should be combined with a related task.

This rule exists to keep each plan within ~50% context budget. The executor reads the plan, reads referenced files, implements, verifies, and commits. That workflow consumes context. A 5-task plan often overruns the budget and the last tasks get lower quality.

#Practical Signal

If the agent starts skipping verification steps or producing incomplete implementations halfway through a plan, the plan is too large. Split it and restart from the incomplete task.

The signal is usually subtle: shorter responses, missed edge cases, verification steps marked “done” without evidence. If you’re seeing any of these, split the plan.