Mozaika

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.

See how the BEST products each build the same hard pattern — one call, cross-product, each with its measured anatomy tree + motion. Use before building any complex pattern: compare_recipes("Command Palette") returns a ranked panel (one per product) of real command palettes, each with its open animation, backdrop, radius, row-rhythm and captured states — so you see how Vercel (cmdkScaleIn) vs Supabase (backdrop-blur) vs Tailwind each solve it, instead of guessing at the invisible motion/state layer. 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.

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", "Finance", "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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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)).

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.

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.

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.

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).

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.

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). Args: query: free text, e.g. "fintech onboarding", "dark dashboard", "Linear". page_type: e.g. "Landing Page", "Dashboard", "Pricing & Subscription", "Checkout". ux_pattern: e.g. "Onboarding", "Dark Mode", "Filter & Sorting", "Stats". industry: e.g. "AI Tool", "Finance", "Analytics", "Fashion". 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 Palette, Navbar, Login, Data Table, Hero Effect...) or "component" (measured single components). section_type: narrows by type, e.g. kind="section" + "Pricing / Plans" / "Testimonial / Social Proof" / "Hero", or kind="recipe" + "Login" / "Navbar" / "Data Table" / "Hero Effect".

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.