Roadmap

Decompose a product into a sequenced series of plan stubs. When the product is too large for a single plan, the roadmap breaks it into ordered phases with dependency tracking.

When to use

Run /uc:roadmap after discovery or migrate when the product scope spans multiple features that need to be built in a specific order. If you can describe your next piece of work in one sentence, skip the roadmap and go straight to feature planning.

What happens

Read product docs — analyzes your product description, architecture, and requirements to understand the full scope
Build dependency graph — identifies which features depend on which, what must exist before other things can be built
Topological sort — orders the build phases so dependencies are satisfied before dependents
Scaffold plan stubs — creates numbered directories in documentation/plans/ with scope boundaries, objectives, and success criteria

What it produces

ROADMAP.md — the master document showing execution order, dependencies, and phase descriptions
Plan stubs — numbered directories (001-auth, 002-api, etc.) each with a README containing objective, scope, and out-of-scope boundaries

Each stub is a starting point for /uc:feature-mode. When you run feature mode with a stub number, it detects the existing scope and shifts from "discover what to build" to "verify and refine the approach."

How plan stubs work with feature mode

Plan stubs have Status: Stub and Source: Roadmap in their README. When feature mode detects a stub:

The scope boundary is already defined — feature mode verifies and refines rather than discovering
Questions focus on implementation approach and technical decisions, not what to build
The stub's Out of Scope section is a hard boundary — scope won't expand beyond it without your approval

This means the roadmap defines what gets built and in what order, while feature mode defines how each piece gets built.

Dependency ordering rules

The roadmap orders plans based on:

Technical dependencies — what code must exist for other code to work (e.g., auth before user management)
Data dependencies — what data models or APIs must be defined first
Incremental value — earlier phases should deliver usable functionality, not just infrastructure
Risk reduction — high-uncertainty items move earlier to fail fast

Plans with no dependencies between them can be executed in parallel or in any order.

Sizing framework

Each plan stub includes a rough size estimate based on the scope:

Small (1–2 tasks) — focused feature, single component
Medium (3–5 tasks) — multi-component feature, some integration
Large (6–10 tasks) — cross-cutting feature, significant new functionality

If a stub estimates larger than 10 tasks, the roadmap splits it into smaller phases.

What's next

Work through the roadmap in order. For each stub, run /uc:feature-mode {number} to detail it into an executable plan, then /uc:plan-execution to build it.