OKLCH Colors

OKLCH is a perceptually uniform color space where lightness, chroma, and hue are useful design controls. Use it when the project already uses OKLCH, when creating a new color system, or when the user asks for conversion or palette work. Otherwise preserve the project's established tokens and notation: a consistent hex or RGB token system is better than introducing a second color representation for an isolated fix. To explore interactively, visit oklch.fyi.

Quick Reference

Core Principles

1. Use a Perceptual Color Space

• Respect the existing system. Do not convert notation merely because this skill was loaded. Reuse the project's semantic tokens and authoring format unless the task includes a color-system migration.
• Perceptual uniformity. Equal L steps = equal brightness. oklch(0.5 ...) is visually mid. HSL's lightness: 50% varies wildly by hue.
• Stable hue. HSL blue shifts toward purple as lightness changes. OKLCH hue stays constant across the full lightness range.
• Independent chroma. Chroma is an absolute measure of colorfulness that doesn't depend on lightness. HSL saturation does.
• Finite gamut. Not every oklch value maps to a displayable sRGB color. High-chroma values at certain hues will clip; gamut awareness is required.

2. Write and Format OKLCH Consistently

oklch(L C H)
oklch(L C H / alpha)

oklch(0.637 0.237 25.331)
oklch(0.8 0.05 200 / 0.5)

Use three decimal places for L and C and up to three for H. Drop trailing zeros and format -0 as 0. OKLCH is Baseline 2023; when support requirements are unusually broad, check the target project's browser matrix instead of relying on a fixed global-coverage percentage.

3. Measure Contrast, Gamut, and Palette Behavior

Common Mistakes

Review Output Format

Use this format only when the user asks for a standalone color review. When better-interface orchestrates the review, provide domain evidence and findings to that skill and let its output format, severity scale, consolidation rules, cap, and verdict take precedence.

Present the standalone review in two parts.

Findings

Group all confirmed findings by principle. Use a markdown table with Severity, Location, Before, After, and Why columns. Never use separate "Before:" / "After:" lines.

• Severity: HIGH makes content unreadable or assigns a misleading semantic color; MEDIUM creates a noticeable theme, gamut, or consistency failure; LOW is isolated polish.
• Location: cite path/to/file:line. If the artifact has no source files, cite the exact screen and component instead.
• Before / After: show the current value or token and the exact replacement.
• Why: name the violated principle and include measured contrast or gamut evidence when relevant.

Consolidate a repeated systemic issue into one row and list every affected location. Omit principles with no findings.

Verification and Verdict

After the findings:

1. Verification: list the exact checks run and their observed results, including contrast measurements, gamut checks, and both light and dark appearances when applicable. If a check was not run, state what still needs verification.
2. Verdict: Block if any HIGH finding remains, Needs changes if only MEDIUM or LOW findings remain, and Approve only when no actionable findings remain.

When there are no findings, omit the table, state "No actionable color findings", report verification, and end with Approve.