designpowers Routing Contract

designpowers routes design operating-layer guidance inside the existing frontend skill. It is not a replacement for /frontend, /visual-qa, /ulw-plan, /start-work, /review-work, or any OpenAgent skill, and it must not create a second planner, builder, verification harness, or orchestration API.

Phase Routing

User intent or workflow phase	Load or instruct	Required handoff from designpowers
Ambiguous or multi-step web UI request; any request needing a plan	/ulw-plan plus this reference's lane-a-direction.md	Provide design discovery prompts, target users, inclusive personas, taste direction, open owner decisions, and design debt policy as planning inputs.
Approved plan execution; continuing an OpenAgent plan	/start-work plus lane-b-execution.md	Keep execution under Boulder/ledger discipline and include current design-state constraints in worker assignments.
Building, styling, redesigning, auditing, or performance-checking a web UI	frontend design + perfection; add lane-b-execution.md when designpowers context affects implementation	Preserve the frontend DESIGN.md gate, design/perfection routing, React tooling, real-browser checks, and implementation standards.
Screenshots, visual regressions, clone fidelity, layout quality, alpha/CJK checks, or design QA	/visual-qa plus lane-c-review.md	Run objective evidence capture before design judgment and feed the same artifacts into persona/accessibility/heuristic review.
Final implementation approval, QA my work, review changes, or significant completed implementation	/review-work plus lane-c-review.md and lane-d-memory.md	Include the design brief, state file path, visual artifacts, unresolved design debt, and accessibility-debt acknowledgements as review inputs.

Planning Through /ulw-plan

When planning is needed, designpowers supplies design-specific context and lets /ulw-plan own the plan artifact. Do not write a separate design plan. The Prometheus plan should receive:

• product or page goal;
• primary tasks and user journeys;
• inclusive personas and assistive or cognitive constraints;
• taste direction, anti-references, and brand/design-system constraints;
• content tone and plain-language requirements;
• motion, responsive, and adaptive-interface requirements;
• verification expectations: frontend checks, visual QA artifacts, persona walkthroughs, and review-work sign-off;
• explicit Must Not Have constraints, including prohibited bridge/canvas tooling.

Execution Through /start-work

When a plan is approved or selected, /start-work remains the orchestrator. designpowers only enriches worker prompts with design context from .omo/frontend-design/state.md and the selected plan. Worker prompts should carry:

• the exact plan checkbox and files in scope;
• design-state constraints that affect the task;
• required frontend design and perfection loading for UI implementation;
• required /visual-qa loading for rendered visual proof;
• the design debt rule: unresolved accessibility debt cannot disappear into a summary.

Direct implementation outside /start-work is not part of this routing contract when a Prometheus plan is active.

UI Build Through Frontend design And perfection

The frontend skill owns actual UI build quality. designpowers may point it at:

• user taste and anti-reference notes;
• target personas and task success criteria;
• content tone, error-state, loading-state, and empty-state expectations;
• cognitive accessibility and adaptive preference requirements;
• design token and design-system constraints.

designpowers must not replace the frontend DESIGN.md gate, taste routing, React tooling, Lighthouse 100 workflow, browser QA, or performance discipline.

Visual Checks Through /visual-qa

/visual-qa owns objective rendered evidence. Run it before accepting visual or design-quality claims. designpowers adds design judgment only after that evidence exists:

• accessibility review with WCAG plus cognitive accessibility concerns;
• heuristic review of task flow and feedback states;
• synthetic persona walkthroughs against the same build;
• debt capture for unresolved design or accessibility gaps.

The same build must satisfy objective visual evidence and design judgment, unless remaining gaps are explicitly recorded and accepted by the user.

Final Review Through /review-work

Use /review-work as the final gate for significant implementation work. The review packet should include:

• original goal and design constraints;
• changed files and diff;
• .omo/frontend-design/state.md path when used;
• frontend design/perfection verification outputs;
• /visual-qa artifact paths;
• persona walkthrough results;
• design debt entries and any explicit accessibility-debt acknowledgement.

designpowers does not approve its own work. It prepares design context so /review-work can evaluate whether the delivered UI satisfies the full request.

Prohibited Routes

The following are guardrails only: framesmith, Figma bridge tooling, figma-bridge, canvas adapters, and canvas_evaluate are not available integration paths. Do not add scripts, hooks, a scheduler, fake direct calls, or a competing planner/build harness.