Build Product-Specific UI from Real Screen Evidence

This skill builds product-specific UI grounded in the repo's own product brief, existing interface, components, and design system, using an optional catalogue of 800,000+ real web and iOS screens from UIZZE only to answer a concrete visual question rather than as a first resort.

Use it when designing, implementing, redesigning, critiquing, or doing a pre-ship review of a web or iOS interface. UIZZE evidence is optional and should only be reached for when a concrete unresolved visual question would benefit from it - it should not turn every interface task into a research project, and a reference is not permission to copy another product's identity, branding, proprietary text, imagery, or exact layout.

Work proceeds from the product itself: identify the screen's real job, primary user and action, required content, and the loading, empty, error, success, disabled, and permission states it needs; reuse the repository's own components, semantic tokens, typography, spacing, and interaction conventions before adding a new abstraction or visual language; for a new interface or major redesign, write a short design contract covering hierarchy, workflow shape, allowed components, required states, responsive behavior, and observable acceptance criteria, keeping smaller changes smaller; and use product-specific labels and real data rather than inventing metrics, activity, testimonials, users, or placeholder workflows to make a layout look complete. When the environment supports it, the result is rendered and inspected once, fixing observable breakage such as clipping, overlap, distorted media, inaccessible or inert controls, missing required states, and unintentional responsive behavior, then running the project's normal checks.

npx skills add https://uizze.com --skill anti-ui-slop

The free skill and its public catalogue work without an account, token, dependency, script, or executable. An optional authenticated UIZZE MCP exposes exactly two tools, find_ui_references and find_ui_materials, used only when actually available - if a search returns nothing, the workflow continues silently from repository evidence, and it never claims an MCP-backed result that wasn't actually returned by the host. References are treated as evidence, not templates: useful decisions about hierarchy, density, navigation, controls, responsive behavior, and state handling get transferred, never another product's branding or assets.

Designers and engineers doing UI work - design, implementation, redesign, critique, or pre-ship review - who want interfaces grounded in the product's own components and real data, with optional outside visual evidence used narrowly rather than as a crutch, and without replacing product validation, accessibility review, security review, or project-specific tests.