frontend-designlisted

Build working UI with specific point of view, one justified signature move, and disciplined polish. ## Scope Use for design-led web pages, components, apps, dashboards, and redesigns. Use `figma-to-ui` when exact Figma selection defines target. Skip backend-only work and tiny visual bug fixes with no design judgment. ## Inputs - Product, audience, page job, and primary action. - Existing repository, components, tokens, content, and constraints. - Brand cues, references, accessibility needs, and supported viewports. - Required states, data, routing, and interactions. User and repository own product facts. Use real supplied content. Mark invented sample content. ## Workflow ### Step 1: Ground Brief If brief vague, choose concrete audience and page job from repository context. State assumption. Pull cues from subject world: materials, tools, artifacts, language, rituals, and constraints. Name target feeling at entry, core action, success, and failure. Name trust level. High-stakes flows favor calm feedback, visible state, reversible action, and clear confirmation. ### Step 2: Set Direction Before code, define: - Palette: four to six colors with roles. - Type: display, body, optional utility. - Layout: composition and responsive rule. - Signature: one remembered element. - Risk: one deliberate move and why it fits. - Emotion: target feeling and trust requirement. Reject direction that fits any similar product. Avoid default purple gradients, generic SaaS cards, ornam