The Build Loop — From Idea to Committed Code
/route: Pick the Right Depth Before You Start
Not Every Task Deserves a PRD
Fixing a typo should not walk brief → PRD → architecture. Building a new product should. /route is the front door that decides where to enter the pipeline by scoring two things: the task's complexity (1–10, using /todo's canonical rubric) and its architectural reach.
| Tier | Scale | Entry point |
|---|---|---|
| 0 Trivial / bugfix | one known change, no new design | /do {task} |
| 1 Feature | several stories inside the existing architecture | /todo {feature} then /run-todo |
| 2 Module | a new feature area in an existing project | /create:module {name} |
| 3 Epic / greenfield | new product, needs real requirements and architecture | /create:new-project (or /onboard for existing code) |
Architectural reach is the primary axis. A complexity-5 request is Tier 1 if it fits the existing architecture and Tier 2 if it is a new feature area. A "feature" that introduces a new ADR is Tier 3, not Tier 1.
Routing Is Not a Bypass
/route picks an entry point; it never passes --yolo and never edits gate state. Every phase it skips is named in the report and logged to the daily log. Downstream commands keep their own hard gates.
Never route deep work shallow to save time. Under-routing ships a product on a stub PRD — the exact failure the planning pipeline exists to prevent. When a request sits between tiers, go shallower only if it adds no new architectural decision and no new public contract.
A request is complexity 5 but introduces a brand-new architectural decision (a new ADR). Which tier?