Mozaika

Search real product UI screens for design reference. Use this BEFORE designing any page/component so your output matches how the best-designed products actually solve the problem. Returns structured metadata (description, UX patterns, UI elements, colors, palette) plus an image_url. Section/component/recipe hits also carry `measured` and `retina` booleans — prefer measured:t

List the distinct sections of a page (hero, pricing cards, testimonial/feedback, footer, ...) so you can emulate a specific part. Each section links back to its page (parent_slug) and the product's design system (call get_design_system(site)).

List real product user flows (ordered screen journeys) — e.g. signup→dashboard, browse→checkout. Use to understand how a whole journey is structured before building it. Returns flow summaries; call get_user_flow(slug) for the full ordered screens.

Get one user flow with its ordered steps, each including full screen metadata and image_url. Returns an error dict if the flow is not found.

Get full metadata + image_url for a single screen by slug.

Get a product's full, LLM-verified design system so you can match its exact look. Use this for "design like <product>" (e.g. site="Linear", "Stripe", "Figma"). Returns (default): color_scheme; colors with named roles (background, text, primary, secondary, accent, link, button_bg, button_text); fonts + font_roles; type_scale; spacing; primary/secondary button; framework + personali

Measured design CHANGE HISTORY for a live-decoded domain — the Decode Ledger. Token-level diffs between deep decodes over time: "radius 4px→8px", "primary hover #4032C8→#0A2540", "motion dominant 150ms→200ms", each dated. Use it to see how a product's design system is EVOLVING (no screenshot library can backfill this). site = a domain ("stripe.com") or product name. Returns

When the user says a screen looks generic, cheap or off and you need to know WHY — paste the code and get numbers back. This is the one tool here that reads YOUR work instead of someone else's product. Give it the component's CSS, or the JSX/HTML with its class attributes (Tailwind utilities are read on the default scale), or both. It measures what the paste actually contain

Grade YOUR design values against the measured corpus (hundreds of real products, decoded live — not opinions). Pass whichever metrics you have; each returns its percentile, the corpus median/p25/p75 and a verdict. Use this to anti-slop-check your own output BEFORE shipping: "body 13px = p6 (median 16px) — too small" or "radius 24px = p97 — much rounder than real products". A

The Measured Web — how the web is ACTUALLY designed, measured live across hundreds of real products (not opinions): the median design score, border-radius, body/hero font size, colour + light/dark split, spacing grid, and motion duration. Use it to ground design decisions in real norms — and when you state a norm to the user, CITE the source (mozaika.design/measured, free under

Has this product's design system CHANGED since it was decoded — and which of its numbers are safe to hard-code? Mozaika re-measures the most-referenced products from the live DOM every night and keeps a dated ledger, so this answers what a screenshot never can: • verdict "held" — nothing moved for N consecutive nights; the spec is still accurate. • verdict "shifted

What actually changed in the web's design systems lately — the nightly Drift Ledger feed. Mozaika re-measures ~100 of the most-referenced products every night and records a dated row per product even when nothing moved, so this is a real time series, not a guess: how many products held every token, which ones shipped a change that stuck (with before/after values and the date), an

Get one product's specific section fully specified — its decoded spec + reference image_url + the parent product's design tokens — in a single call. Use this for "build a <section> like <product>", e.g. get_section("Linear", "Pricing / Plans"). Deep-decoded products' design_tokens also carry measured button hover/focus states, shadows and motion — measured live, not guessed.

See how the BEST products each solve the same section — one call, cross-product. Use before designing any section: e.g. compare_sections("Pricing / Plans") returns a ranked panel (one per product) of real pricing sections, each with its reference image_url, pixel-measured spec (bg/text/accents/contrast/scheme/columns/alignment/ whitespace) and the product's core design tokens.

Get one product's UI component fully specified — its anatomy read from the LIVE DOM (exact padding / height / border_radius / border / box_shadow / font_weight / letter_spacing / transition + the real :hover state) plus a reference image_url and the product's design tokens, in a single call. Use this for "build a <component> like <product>", e.g. get_component("Linear", "Button")

See how the BEST products each build the same UI atom — one call, cross-product, each with its anatomy read from the live DOM. Use before building any component: compare_components("Button") returns a ranked panel (one per product) of real buttons, each with measured padding / radius / border / shadow / weight / hover — so you see the real divergence (Linear's pill+shadow vs Ve

The universal BUILD-KIT fetcher — the measured spec + code to reproduce a piece of UI. `recipe_type` selects which library across three families (all agent-ready through this one call): • COMPONENTS (decoded live from a real product's DOM — Mozaika's wedge): "Command Palette", "Dropdown Menu", "Dialog / Modal", "Login", "Data Table", "Onboarding Tour", "Navbar", "Lo

See how the BEST products each build the same hard pattern — one call, cross-product. Use before building any complex pattern: compare_recipes("Command Palette") returns a ranked panel (one per product), each entry carrying the at-a-glance layer you pick a reference by — overlay radius, whether it ships a shadow, backdrop filter, the open-motion string and the names of the capt

Pull an entire product as an agent-ready build kit: the full multi-format design system (tokens + DESIGN.md/Tailwind/CSS/JSON), every curated page, every section grouped by type (with spec + image_url), plus any user flows. Deep-decoded products' tokens also carry measured button states, shadows, motion and the brand's own custom properties. Call this once for "clone/build like <pr

List YOUR private design systems (BYODS) — the sites you decoded into your own/your team's scope. Each item has name + slug; pass the slug/name to get_design_system or get_product to build against it. Returns an empty list if you have none (or aren't authenticated).

Get a ready-made AI-generated icon pack (12 consistent icons) — e.g. a house style like 'clay-starter' / 'line-minimal-starter', or a pack generated in the MEASURED style of a decoded brand. Free and unmetered. Each image is a 1024px transparent PNG you can download and use directly (full commercial rights). Unknown slug → lists available packs.

Generate ON-BRAND icons with AI: subjects (1-12 short nouns, e.g. ["settings gear", "credit card"]) rendered in ONE consistent style. style_from is either a decoded domain ("stripe.com" — the icons match that brand's MEASURED style: accents, stroke, corners) or a house style key ("skeuomorph"). INCLUDED with your account — free accounts get a real daily allowance (enough for a

Design Score: a 0-100 design audit MEASURED from the site's live DOM (real WCAG contrast pairs, detected type ladder, spacing grid, forced hover states, motion) — scored against the whole measured-web corpus ("top N% of M systems"). Free to read. Use it to audit the site YOU are building or any competitor: returns dimension scores (typography/color/spacing/motion), UI+UX headline