Deriving a Dark Theme

A dark theme is derived from a finished light theme by re-binding roles to steps, never by mirroring the pixels. The ink/canvas pair does flip — the near-white step becomes the near-black one — but elevation does not: a raised surface is lighter than its page in both themes, so a mechanical inversion yields black cards floating on grey, and is the most common way a dark mode ends up wrong without anyone naming why. The default posture is that dark mode is optional: Benji Taylor's site carries exactly two prefers-color-scheme rules and both sit inside embedded demos, so the site itself has none. Commit or build it properly; half-built is the worst of the three. This skill maps an existing set into the second theme — color picks the values and owns contrast, and this skill never picks a brand hue. surfaces owns the elevation ladder within a theme (shadow recipes, nested radii, hairlines); this skill owns expressing that same ladder as surface lightness once shadows stop reading.

Find the theme switch before writing a single token. Read whether the project flips a [data-theme] attribute, a .dark class, prefers-color-scheme, or a provider such as next-themes, and put every dark value behind that exact mechanism. If a numbered variable scale already flips at one root selector, add to it. Never introduce a second switching mechanism, and never answer a dark-mode bug with per-component dark: overrides on top of a variable system built to make them unnecessary.

Quick Reference

The Derivation Order

Each step depends on the one above it.