Design UI

Take UI work from product brief to verified render. Treat direction, design-system definition, implementation, and visual QA as one lifecycle. Keep private comparison and scoring private; share decisions, artifacts, concise audit findings, and evidence.

Route the request

1. Inspect the brief, repository instructions, existing DESIGN_SYSTEM.md, routes, components, assets, product language, target platforms, and references.
2. Maintain a requirement ledger covering users, primary jobs, business goal, explicit requirements, flows, states, viewports, accessibility, content, constraints, and assumptions.
3. Choose the correct entry point:
   • No firm visual system: begin with creative-direction exploration.
   • Existing approved design system: treat it as binding and proceed to implementation or review. Do not force a new exploration unless redesign is requested or the system is materially incomplete.
   • Design-system-only request: complete direction selection and DESIGN_SYSTEM.md, then stop.
   • Implementation request with a selected target and direction: proceed through implementation and rendered iteration.
   • Review-only request: inspect the rendered interface and report findings; do not modify files unless the user requests changes.
4. Resolve low-risk ambiguity with a stated assumption. Ask at most three concise questions only when answers would materially change the product direction.

When external references are needed or requested, read references/reference-research.md completely before researching. Use Pinterest as the default visual-discovery source, supplement it with original product evidence for flows and states, and preserve the user's supplied references and approved direction. Do not make new research a prerequisite for a small change or a review with sufficient existing evidence.

Phase 1: Choose a creative direction