Design Style Mirror

/design-mirror

Capture the visual design language of any website and apply it to the user's existing codebase -- colors, typography, spacing, layout rhythm, component shapes, and overall aesthetic.

What This Skill Does

1. Capture -- gather visual and structural evidence of the inspiration site
2. Extract -- identify the full design system: colors, fonts, spacing scale, border radii, shadows, component patterns
3. Analyze -- study the screenshot visually and the CSS structurally to understand the design language
4. Apply -- translate that design system into the user's existing codebase (their framework, their components)

You are not copying content or functionality. You're understanding the design language -- the palette, the type scale, the card shapes, the hover states, the overall aesthetic feel.

Important: This skill is for design inspiration and learning -- extracting publicly visible design tokens (colors, fonts, spacing) to inform the user's own UI work. Always use it respectfully and in accordance with the terms of service of the referenced sites.

Step-by-Step Process

Step 1: Capture the Inspiration Site

Ask the user to provide, in whatever combination they can:

• A screenshot of the inspiration site (upload the image) -- for visual analysis
• The page HTML/CSS (paste the page source, or copy relevant <style> blocks and stylesheet contents from browser DevTools) -- for structural CSS extraction
• At minimum, the URL and a description of what they like about it

Both inputs are valuable: the screenshot drives visual analysis; the CSS drives token extraction.

Step 2: Analyze the Design System

Analyze both inputs:

Visual analysis (screenshot): identify:

• Primary, secondary, accent colors
• Background colors (page bg, card bg, surface hierarchy)
• Typography: font families visible, size hierarchy (h1 -> body -> caption)
• Layout: centered/constrained-width? Grid? Sidebar?
• Card/container shapes: border radius size, shadow style (hard, soft, none, colored)
• Button styles: pill, rectangle, ghost, gradient?
• Navigation: sticky? Glass/blur effect? Dark or light?
• Overall mood: dark, light, minimal, brutalist, glassmorphism, corporate, startup?

CSS analysis (pasted HTML/CSS): extract from <style> tags and inline styles:

• CSS custom properties (:root { --color-... }) -- publicly declared design tokens
• Font imports (@import from Google Fonts, etc.)
• Tailwind config if present
• Repeated class patterns that reveal the spacing scale

Step 3: Build the Design Token Map

Produce a structured design token map before touching any code:

DESIGN TOKENS FROM [site]
==========================
Colors:
  --bg-primary: #0a0a0f      (page background)
  --bg-surface: #13131a      (card/panel background)
  --text-primary: #ffffff
  --text-muted: #8888aa
  --accent: #7c3aed          (primary CTA color)
  --accent-hover: #6d28d9
  --border: rgba(255,255,255,0.08)

Typography:
  --font-heading: 'Inter', sans-serif
  --font-body: 'Inter', sans-serif
  font-scale: 12/14/16/20/24/32/48px
  heading-weight: 700
  body-weight: 400

Spacing:
  base-unit: 8px
  scale: 4/8/12/16/24/32/48/64px

Borders & Shadows:
  --radius-sm: 6px
  --radius-md: 12px
  --radius-lg: 20px
  --shadow: 0 4px 24px rgba(0,0,0,0.4)

Special effects:
  glass-blur: backdrop-filter: blur(16px)
  gradient: linear-gradient(135deg, #7c3aed, #2563eb)

Show this token map to the user before proceeding. It's the foundation -- if it's wrong, the output will be wrong.

Step 4: Understand the User's Codebase

Before writing any code, ask the user to paste the relevant parts of their codebase:

• What framework? (React, Vue, Next.js, plain HTML?)
• What styling approach? (Tailwind, CSS modules, styled-components, plain CSS?)
• Where are global styles defined? (globals.css, theme.ts, tailwind.config.js?)
• What components need restyling? (ask if unclear)

Do not rewrite everything -- surgical precision. Apply the design tokens to the existing structure.

Step 5: Apply the Design

Deliver the changes as code artifacts the user can drop into their project. The application strategy depends on their stack:

If Tailwind: an updated tailwind.config.js with the new color palette, font family, border radius scale, plus custom CSS variables for anything Tailwind cannot handle natively.

If CSS/CSS Modules: a :root variables block for globals.css, plus updated component stylesheets using the new variables.

If styled-components/Emotion: an updated theme object, replacing hardcoded color/spacing values with theme tokens.

In all cases:

• Apply colors, typography, and spacing globally first
• Then tackle component-level details (buttons, cards, nav) one at a time
• Preserve all existing functionality and layout structure -- only visual properties change
• Add any special effects (glass blur, gradients, animations) that define the inspiration site's character

Step 6: Show the Before/After

After delivering changes, clearly present:

• Which files should be modified
• The design token mapping (source -> what you set it to)
• Any special effects added
• What the user should check visually (hover states, dark/light mode, mobile)

Remind them to check their dev server. Offer to iterate on specific components.

Key Principles

Design language, not markup. The inspiration site's HTML structure and content are theirs. You're extracting the design language -- how colors relate, how spacing flows, what gives the site its character -- to apply as the user's own creative foundation.

Design tokens first, code second. Rushing to apply colors before understanding the full system leads to inconsistent results. Always build the token map first.

Ask about scope. "Apply the design everywhere" vs "just make the homepage feel like it" vs "only restyle the navbar" are very different jobs. Clarify before proceeding.

Don't break what works. The user's components work. Only change visual properties. If a change might break layout, err on the side of caution and flag it.

Iterative is fine. It's often better to get the foundation right (colors, type, spacing) and let the user review before tackling component-level details.

What to Do When...

The site uses a design system (Material, shadcn, etc.): identify it, tell the user, and ask if they want to adopt the same system or just extract the visual tokens.

The CSS is minified/obfuscated: fall back to the screenshot and visual analysis. You can still extract colors, spacing, and shapes from visual inspection.

The user can only provide a URL and no screenshot or CSS: ask them to take a full-page screenshot in the browser and to copy the page source or key styles from DevTools; without either, you can only work from their verbal description.

The user's codebase uses a component library (shadcn, Chakra, MUI): apply the design by customizing the library's theme/config rather than overriding individual components.

Multiple pages need to match: use the homepage for overall design tokens, but offer to analyze inner pages (e.g., /pricing, /docs) if the user wants to match a specific page's look.

Usage

/design-mirror $ARGUMENTS