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:true, retina:true references (pixel-measured, high-res). `query` alone works well — the filters below are optional. A value outside the lists is treated as a HINT (it ranks, it does not exclude), and if the filters together match nothing they relax rather than hand you an empty list. So a near-miss costs you nothing; spelling one exactly is simply more precise. Args: query: free text, e.g. "fintech onboarding", "dark dashboard", "Linear". page_type: one of Billing · Camera / Capture · Changelog · Chat / Assistant · Checkout · Dashboard · Detail · Docs · Editor · Empty State · Feed · Integrations · Landing Page · Log In · Map · Onboarding · Paywall · Player · Pricing · Profile & Account · Search & Results · Settings · Sign Up · Stories. ux_pattern: e.g. "Dark Mode", "Filter & Sorting", "Stats / KPIs", "Data Table", "Command Palette", "Multi-step Form", "Sidebar Navigation", "Bento Grid", "Progressive Onboarding", "Empty State", "Kanban", "Master-Detail", "WYSIWYG". industry: one of AI · Analytics · Communication · Consumer · Creator · Data · Design · Dev Tools · E-commerce · Entertainment · Fintech · Health & Fitness · Productivity · Real Estate · Security · Travel & Local. platform: "Web", "iOS" or "Android" (mobile = official store-listing screens). limit: max results (1-40, default 12). kind: "page" (default, whole screens), "section" (page parts), "recipe" (live-decoded composed patterns: Command Palett

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 + personality. All hex normalized. Deep-decoded products additionally include measured button hover/focus states, a shadow elevation scale (card/overlay/subtle), motion durations + easings, the measured spacing scale, the brand's own CSS custom properties (css_vars), and Icon DNA (icons: style outline/filled/duotone/3d, grid, stroke_weight, corner) — all measured from the live page, not guessed. Match them exactly; pass the domain to generate_asset(style_from=...) to strike icons in this exact style. Your own private BYODS design systems (call list_my_design_systems) resolve first. format: leave empty for the raw token dict. Pass "all" to also get paste-ready DESIGN.md / Tailwind v4 / CSS variables / W3C tokens JSON, or a single format name ("tailwind", "css", "design_md", "tokens", "astryx") to get just that text. "astryx" returns a ready Meta-Astryx defineTheme TypeScript file (measured hover/press states + [light,dark] tuples baked in) — save it and run `npx astryx theme build` for production CSS.

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 first/last decode dates, decode_count and the dated change entries; empty history = measured, stable so far.

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 contains — type ladder, spacing grid, radii, transition timing, container width — grades each against hundreds of live-decoded real products, and returns findings worst-first, each with the value, its percentile, the corpus median and the change to make. It only ever reports what it could genuinely read, and lists what it could not: it sees the source, not the rendered screen, so colour contrast, hover/focus states and runtime-resolved variables are out of reach — for a public URL, get_score(domain) reads those from the live DOM instead. Free and unmetered. Args: code: the CSS and/or markup to audit. Paste the real thing, not a summary.

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 value between p25-p75 is squarely normal; sub-p10 / over-p90 deserves a deliberate reason.

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 CC BY 4.0). To grade specific values of your own design, call validate_design(...). Free.

無需輸入參數。

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" — a token changed and the new value stuck (with the date and before/after). • verdict "unstable" — a value alternates between nights: a live A/B test, rotating content, or a page that renders differently each run. `do_not_hardcode` lists it. Call this BEFORE building against a cached spec, and before baking any measured value into a token file. Pairs with get_design_system(site) — that gives the spec, this gives its shelf life. Args: domain: e.g. "stripe.com", "linear.app" (bare domain, no scheme). Free.

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), and which design tokens move most often across the web. Use it to answer "does anyone actually redesign?", to ground a claim about design churn with a citable measurement, or to spot that a reference you rely on has moved. For one product, call get_design_drift(domain). Args: limit: how many confirmed changes to return (1-40, default 10). Free.

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. Returns the available section types if the requested one isn't found.

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. Args: section_type: e.g. "Hero", "Pricing / Plans", "Testimonial / Social Proof", "Logo Wall", "Feature", "CTA / Sign-up", "Footer", "FAQ", "Stats / Metrics". industry: optional filter, e.g. "AI Tool", "Fintech", "Dev Tools". scheme: optional "dark" or "light" (matches the section's measured background). limit: panel size (1-12, default 8). Returns available section types if the requested one has no matches.

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"). This is measured, not guessed — data no model has seen. Returns the available component types if the requested one isn't found.

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 Vercel's shadowless pill vs Supabase's 6px vs Mercury's 32px) instead of guessing. Args: component_type: e.g. "Button", "Navigation", "Card", "Pricing Card", "Input", "Toggle". industry: optional filter, e.g. "Dev Tools", "Fintech". scheme: optional "dark" or "light" (matches the component's measured background). limit: panel size (1-12, default 8). Returns available component types if the requested one has no matches.

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", "Logo Marquee", "Toast", "Date Picker", "Combobox" — returns the anatomy TREE (each node measured), the MOTION (open/close animation + easing a screenshot can't show), every STATE (empty/results/no-results/keyboard-selected), a webm of it running, and the design tokens. • EFFECTS (open-source WebGL hero backgrounds — Apache/MIT): "Hero Effect" → the shader's full config + fps + install command + license/NOTICE. • MOTION (open-source looping showcase templates — MIT): "Motion Showcase" → the template's full parameter surface + the exact Swiper/anime.js/Motion config + install. Use for "build a <thing> like <product>", e.g. get_recipe("Vercel", "Command Palette") or get_recipe("vanta", "Hero Effect"). A complete, uncopyable, measured build kit. Returns the available types if the requested one isn't found.

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 captured states — so you see that Vercel animates the open where Supabase blurs the backdrop, instead of guessing at the invisible motion/state layer. This is the comparison view; call get_recipe(site, recipe_type) on the one you choose for its full measured anatomy tree, easings, state captures and video. Args: recipe_type: e.g. "Command Palette", "Pricing Table", "Toast", "Data Table", "Multi-step Form". industry: optional filter, e.g. "Dev Tools", "Fintech". scheme: optional "dark" or "light" (matches the recipe's measured overlay background). limit: panel size (1-12, default 8). Returns available recipe types if the requested one has no matches.

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 <product>" instead of many small calls. Your private BYODS systems resolve first.

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 full set), Pro/Lifetime a high one; QA-failed images never count. Returns image_url per subject (1024px transparent PNG) + a zip link.

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 scores, plain-language verdicts, the raw measured evidence chips, and a prioritized fix list — each fix anchored to an evidence index (agent-ready: why + how_to you can apply directly to the codebase). Not scored yet (or refresh=true)? A scan starts (~60-90s) using your account email — call get_score again shortly. Full fix payload requires Pro/Lifetime; everyone gets scores, evidence, verdicts and one complete sample fix.