Design Gate

Turn "which design lens applies here?" into a small, evidence-based routing decision, then run only the selected lenses and merge their findings into one verdict. This skill is the routing authority. It does not invent a second review method or call a council.

For the workflow stage boundaries and the practical skills that follow this gate, read shared/references/workflow-stage-routing.md.

Workflow

1. Identify the stage and the surfaces from the plan, Slice Contract, or changed scope. In to-tasks, this is the one routing pass for the slice. Before implementation, use the inherited lens flags; re-route only when the slice's design surface changed.
2. Select lenses from the routing table. Multiple rows can match; cap at three. Keep the three most central to the change's risk. No matching row on a local change means no gate.
3. Run each selected lens as a parallel read-only reviewer. Give it the plan or design problem, the files and boundaries in scope, and this gate response: verdict, blocking_findings, advisory_findings, and required_changes. This response replaces a lens's standalone edit or implementation route.
4. Merge. Any revise with a concrete, load-bearing finding makes the gate verdict revise. Cosmetic or speculative findings are advisory.
5. On revise, state the required plan changes as a short numbered list. When lenses expose a real unresolved trade-off, set verdict: revise, set decision_required, and stop. Never call models-consensus from this skill. The user may invoke it separately when more opinions are useful.

Routing table