sprint-workflow

Sprint workflow structures iterative development across six phases—Load Specifications, Architectural Planning, Implementation, Testing, Review & Iteration, and Finalization—each with defined gates and outputs. Use /sprint:new to initialize your first sprint, then /sprint to begin the cycle where agents converge on solutions through controlled iterations.

Convergent diffusion removes completed work from specifications after each phase, keeping your context window focused and preventing noise accumulation. This shrinking specification set maintains clarity across multi-phase sprints while tracking progress through status.md and project-map.md.

Yes. Sprint workflow applies to teams managing backend, frontend, and testing pipelines across Python/FastAPI and Next.js stacks with integrated CI/CD contexts. It handles phase planning, implementation orchestration, and testing coordination across all three technology layers.

Resume from status.md and project-map.md to restore sprint state. Machine-readable reports generated during reviews inform iteration decisions and help diagnose blockers when you hit the five-iteration maximum before requiring user intervention.

Sprints pause after five iterations if blockers persist, requiring user intervention to unblock or adjust approach. This constraint ensures forward progress and prevents infinite loops in multi-phase development cycles.

Sprint workflow coordinates across backend, frontend, and testing pipelines in unified phases, but each team executes against its own deliverables. Phase gates and shared status.md create synchronization points without requiring simultaneous work.