Use when working with color naming, color theory, color spaces, color definitions, or any task involving color knowledge - palettes, ramps, gradients, conversions, accessibility, perceptual matching, pigment mixing, print-vs-screen color, CSS color syntax, or historical color terminology. Use this skill whenever the user is choosing, comparing, generating, naming, converting, or explaining colors, even if they do not explicitly ask for "color theory."
A comprehensive knowledge base for color-related work. See references/INDEX.md for 140+ detailed reference files; this skill file contains the essential knowledge to answer most questions directly.
| Task | Use | Why |
|---|---|---|
| Perceptual color manipulation | OKLCH | Best uniformity for lightness, chroma, hue. Fixes CIELAB's blue problem. |
| CSS gradients & palettes | OKLCH or color-mix(in oklab) | No mid-gradient darkening like RGB/HSL |
| Gamut-aware color picking | OKHSL / OKHSV | Ottosson's picker spaces — cylindrical like HSL but perceptually grounded |
| Normalized saturation (0-100%) | HSLuv | CIELUV chroma normalized per hue/lightness. HPLuv for pastels. |
| Print workflows | CIELAB D50 | ICC standard illuminant |
| Screen workflows | CIELAB D65 or OKLAB | D65 = screen standard |
| Cross-media appearance matching | CAM16 / CIECAM02 | Accounts for surround, adaptation, luminance, and viewing conditions |
| HDR | Jzazbz / ICtCp | Designed for extended dynamic range |
| Pigment/paint mixing simulation | Kubelka-Munk (Spectral.js, Mixbox) | Spectral reflectance mixing, not RGB averaging |
| Color difference (precision) | CIEDE2000 | Gold standard perceptual distance |
| Color difference (fast) | Euclidean in OKLAB | Good enough for most applications |
| Video/image compression | YCbCr | Luma+chroma separation enables chroma subsampling |
HSL isn't "bad" — it's a simple, fast geometric rearrangement of RGB into a cylinder. It's fine for quick color picking and basic UI work. But its three channels don't correspond to human perception:
hsl(60,100%,50%)) and fully saturated blue (hsl(240,100%,50%)) have the same L=50% but vastly different perceived brightness. L is a mathematical average, not a perceptual measurement.When HSL is fine: simple color pickers, quick CSS tweaks, situations where perceptual accuracy doesn't matter.
When to use something better:
color-mix(in oklab) (no mid-gradient darkening)Use these degree ranges when generating or constraining colors by hue name. Source: random-display-p3-color by mrmrs / mrmrs.cc.
| Name | Degrees |
|---|---|
| red | 345–360, 0–15 |
| orange | 15–45 |
| yellow | 45–70 |
| green | 70–165 |
| cyan | 165–195 |
| blue | 195–260 |
| purple | 260–310 |
| pink | 310–345 |
| warm | 0–70 |
| cool | 165–310 |
When using colors in a program or CSS, add a semantic layer between raw color values and UI roles.
The examples below are pseudocode, not literal CSS requirements. They express the decision structure an agent should preserve even if the target stack uses different syntax.
Across CSS, JS/TS, Swift, design-token JSON, templates, or pseudocode, default to the same structure:
Raw color literals should usually appear only in palette/reference definitions, conversions, diagnostics, or deliberately one-off examples.
ref.red = #f00semantic.warning = ref.redPseudocode examples:
ref.red := closest('red', generatedPalette)semantic.warning := ref.redsemantic.onSurface := mostReadableOn(surface)Good pattern: palette/reference tokens define available colors; semantic tokens map those colors to roles like surface, text, accent, success, warning, and danger.
If a system can derive a decision from constraints, encode that derivation. Examples: nearest named hue in a generated palette, foreground chosen by APCA/WCAG target, hover state computed from the base token in OKLCH instead of hand-picking a second unrelated hex.
For larger systems, prefer a token graph over a flat token dump: references, semantic roles, derived functions, and scope inheritance. This makes theme changes, accessibility guarantees, and multi-platform export auditable and easier to maintain.
Of ~281 trillion hex color pairs (research by @mrmrs_, computed via a Rust brute-force run):
| Threshold | % passing | Odds |
|---|---|---|
| WCAG 3:1 (large text) | 26.49% | ~1 in 4 |
| WCAG 4.5:1 (AA body text) | 11.98% | ~1 in 8 |
| WCAG 7:1 (AAA) | 3.64% | ~1 in 27 |
| APCA 60 | 7.33% | ~1 in 14 |
| APCA 75 (fluent reading) | 1.57% | ~1 in 64 |
| APCA 90 (preferred body) | 0.08% | ~1 in 1,250 |
APCA is far more restrictive than WCAG at comparable readability. At APCA 90, only 239 billion of 281 trillion pairs work. JPEG compression exploits the same biology: chroma subsampling (4× less color data) is invisible because human vision resolves brightness at higher resolution than color.
Complementary, triadic, tetradic intervals are weak predictors of mood, legibility, or accessibility on their own. Every hue plane has a different shape in perceptual space, so geometric hue intervals do not guarantee perceptual balance.
Organize by character (pale/muted/deep/vivid/dark), not hue. Finding: hue is usually a weaker predictor of emotional response than chroma and lightness — a muted palette often reads as calm across many hues. Relaxed vs intense is driven more by chroma + lightness than hue alone.
Grayscale is a quick sanity check for lightness separation, not an accessibility proof. You still need to verify contrast with WCAG/APCA and consider text size, weight, polarity, and CVD. Same character + varied lightness is often more readable. Same lightness regardless of hue is usually illegible.
60% dominant color, 30% secondary, 10% accent. One color dominates to prevent "three equally-sized gorillas fighting."
| System | Register | Example |
|---|---|---|
| ISCC-NBS | Scientific precision | "vivid yellowish green" |
| Munsell | Systematic notation | "5GY 7/10" |
| XKCD | Common perception | "ugly yellow", "hospital green" |
| Traditional Japanese | Cultural/poetic | "wasurenagusa-iro" (forget-me-not) |
| RAL | Industrial reproducibility | RAL 5002 |
| Ridgway (1912) | Ornithological | 1,115 named colors, public domain |
| CSS Named Colors | Web standard | 147 named colors |
| color-description lib | Emotional adjectives | "pale, delicate, glistening" |
Use color-name-lists npm package for 18 naming systems in one import.
Note: coolors.co does not generate palettes — it picks randomly from 7,821 pre-made palettes hardcoded in its JS bundle.
<poline-palette> web component for interactive controlscolor(t) = a + b*cos(2π(c*t+d)), 12 floats = infinite paletteImageData + Python/TensorFlow perceptual palette embeddings for search-by-color (Google Arts & Culture, Apache 2.0)See references/INDEX.md for the detailed files organized as:
historical/ — Ostwald, Helmholtz, Bezold, Ridgway 1912, ISCC-NBS, Munsell, Albers, Caravaggio's pigments, Moses Harris, Lewis/Ladd-Franklincontemporary/ — Ottosson's OKLAB articles, Briggs lectures, Fairchild, Hunt, CIECAM02, MacAdam ellipses, Pointer's gamut, CIE 1931/standard observer, Pixar Color Science, Acerola, Juxtopposed, Computerphile, bird tetrachromacy, OLO, GenColor paper. Full scrapes: huevaluechroma.com and colorandcontrast.comtechniques/ — All tools above documented in detail, plus: CSS Color 4/5, ICC workflows, Tyler Hobbs generative color, Harvey Rayner Fontana approach, Goethe edge colors as design hack, mattdesl workshop + K-M simplex, CSS-native generation, IQ cosine presets, Erika Mulvenna interview, Bruce Lindbloom math reference, image extraction tools, Aladdin color analysis