Claude Skill

dark-mode-converter

Convert a light-only site or app to a real dark mode -- semantic token mapping, elevation-based surfaces, recalibrated shadows and imagery -- not a naive inversion. Handles Tailwind, CSS variables, and styled-components, plus the toggle, persistence, and no-flash boot.

LLM Mart · 0 points · 0 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download onewave-ai-claude-skills-dark-mode-converter-97b5147.zip · 2 KB

onewave-ai/claude-skills 298 49 forks MIT Updated 5d ago

Part of onewave-ai/claude-skills — 67 skills

Install

skills CLI npx skills add https://github.com/OneWave-AI/claude-skills/tree/main/dark-mode-converter

Claude Code

claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install onewave-ai-claude-skills@llmmart

Git git clone https://github.com/OneWave-AI/claude-skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole onewave-ai/claude-skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Dark Mode Converter

Build dark mode the way design-mature products do: as a second theme with its own logic, not the light theme with colors flipped. Inversion fails because dark UIs work differently -- elevation is communicated by lighter surfaces instead of shadows, saturated colors vibrate on dark backgrounds, and pure black plus pure white is glare, not contrast.

Workflow

Tokenize first. Inventory every color in the codebase. If colors are hardcoded in components, lift them into semantic tokens before converting -- bg.base, surface, surface.raised, text.primary, text.muted, border, accent, states. A dark mode built on raw hex replacements breaks on the next feature. (If tokens exist, audit for strays with the same sweep.)
Design the dark palette by role, following dark-UI physics: base is dark gray, never #000 (#0f1115-#1a1d23 territory, or tinted toward the brand hue); elevation gets lighter as surfaces rise (base -> card -> popover each a step up); text is off-white, never #fff (#e8eaed-ish, ~87% white) with muted steps; accents desaturate and lighten 1-2 steps so they do not vibrate; borders drop to low-alpha whites; shadows go darker and tighter or yield to surface-lightness entirely. Verify every text/surface pair at WCAG AA minimum.
Wire the mechanism per stack: Tailwind dark: with class strategy (v4: @variant dark), or a [data-theme="dark"] block redefining the custom properties. Add the toggle with three states (light/dark/system), localStorage persistence, prefers-color-scheme default, and the no-flash inline script in <head> that sets the class before first paint.
Handle the hard parts -- the places naive conversions die: images and illustrations with baked-in white backgrounds (swap variants, add a subtle surface behind them, or CSS-filter logos where acceptable); charts and data-viz palettes (need their own dark series colors); form controls and color-scheme: dark so native inputs, scrollbars, and autofill match; embedded third-party widgets (map themes, iframes); email templates and open-graph images that never inherit the theme; focus rings that vanish on dark.
Audit pass. Screenshot-walk the key routes in both modes (or list them for the user to check): look for stranded light surfaces, double-borders where shadows used to separate, unreadable muted text, and accent buttons that lost their punch. Output dark-mode-report.md: token map (light -> dark by role), files touched, contrast table, and remaining items needing design eyes.

Rules

Semantic tokens or nothing. dark:bg-gray-800 sprinkled across 90 components is a maintenance debt, not a theme -- centralize the mapping.
Never pure black base, never pure white text. Reserve those for moments, not defaults.
Elevation flips: light mode says "higher" with shadow, dark mode says it with a lighter surface. Convert the logic, not just the colors.
Accents recalibrate, brand does not change: adjust lightness/saturation to sit on dark, but the brand hue survives (check contrast of brand-on-dark and flag genuine conflicts for the user rather than silently shifting hue).
Both modes are first-class from now on: every report includes the rule that new components define both themes' tokens or fail review.
Test system-preference switching live -- the system setting must react to OS changes without reload.

Quick Commands

"Convert this project to dark mode" -- full workflow
"Tokenize my colors first" -- step 1 standalone
"Just design the dark palette" -- step 2 from existing tokens
"Dark mode audit" -- step 5 against an existing implementation

Files (claude-skills)

SKILL.md 4 KB

---
name: dark-mode-converter
description: Convert a light-only site or app to a real dark mode -- semantic token mapping, elevation-based surfaces, recalibrated shadows and imagery -- not a naive inversion. Handles Tailwind, CSS variables, and styled-components, plus the toggle, persistence, and no-flash boot.
tools: Read, Glob, Grep, Write, Edit, Bash
model: inherit
---

# Dark Mode Converter

Build dark mode the way design-mature products do: as a second theme with its own logic, not the light theme with colors flipped. Inversion fails because dark UIs work differently -- elevation is communicated by lighter surfaces instead of shadows, saturated colors vibrate on dark backgrounds, and pure black plus pure white is glare, not contrast.

## Workflow

1. **Tokenize first.** Inventory every color in the codebase. If colors are hardcoded in components, lift them into semantic tokens before converting -- `bg.base`, `surface`, `surface.raised`, `text.primary`, `text.muted`, `border`, `accent`, states. A dark mode built on raw hex replacements breaks on the next feature. (If tokens exist, audit for strays with the same sweep.)
2. **Design the dark palette** by role, following dark-UI physics: base is dark gray, never `#000` (`#0f1115`-`#1a1d23` territory, or tinted toward the brand hue); elevation gets *lighter* as surfaces rise (base -> card -> popover each a step up); text is off-white, never `#fff` (`#e8eaed`-ish, ~87% white) with muted steps; accents desaturate and lighten 1-2 steps so they do not vibrate; borders drop to low-alpha whites; shadows go darker and tighter or yield to surface-lightness entirely. Verify every text/surface pair at WCAG AA minimum.
3. **Wire the mechanism** per stack: Tailwind `dark:` with `class` strategy (v4: `@variant dark`), or a `[data-theme="dark"]` block redefining the custom properties. Add the toggle with three states (light/dark/system), `localStorage` persistence, `prefers-color-scheme` default, and the no-flash inline script in `<head>` that sets the class before first paint.
4. **Handle the hard parts** -- the places naive conversions die: images and illustrations with baked-in white backgrounds (swap variants, add a subtle surface behind them, or CSS-filter logos where acceptable); charts and data-viz palettes (need their own dark series colors); form controls and `color-scheme: dark` so native inputs, scrollbars, and autofill match; embedded third-party widgets (map themes, iframes); email templates and open-graph images that never inherit the theme; focus rings that vanish on dark.
5. **Audit pass.** Screenshot-walk the key routes in both modes (or list them for the user to check): look for stranded light surfaces, double-borders where shadows used to separate, unreadable muted text, and accent buttons that lost their punch. Output `dark-mode-report.md`: token map (light -> dark by role), files touched, contrast table, and remaining items needing design eyes.

## Rules

- Semantic tokens or nothing. `dark:bg-gray-800` sprinkled across 90 components is a maintenance debt, not a theme -- centralize the mapping.
- Never pure black base, never pure white text. Reserve those for moments, not defaults.
- Elevation flips: light mode says "higher" with shadow, dark mode says it with a lighter surface. Convert the logic, not just the colors.
- Accents recalibrate, brand does not change: adjust lightness/saturation to sit on dark, but the brand hue survives (check contrast of brand-on-dark and flag genuine conflicts for the user rather than silently shifting hue).
- Both modes are first-class from now on: every report includes the rule that new components define both themes' tokens or fail review.
- Test system-preference switching live -- the `system` setting must react to OS changes without reload.

## Quick Commands

- "Convert this project to dark mode" -- full workflow
- "Tokenize my colors first" -- step 1 standalone
- "Just design the dark palette" -- step 2 from existing tokens
- "Dark mode audit" -- step 5 against an existing implementation