better-colors

Topics in the source

• Colors
• Match the project's color system
• A system is ramps, not colors
• Every step has a job
• Name primitives by hue, semantics by role
• Use a token only in its role
• Hold the hue across the ramp
• One color, one meaning

This skill builds and audits color systems. It generates ramps, maps their steps to roles and token names, converts notation and measures rendered contrast pairs. Never report a contrast value you did not measure, and never estimate a color you could compute. Notation, a tinted neutral and a gradient's interpolation space are project choices, not findings. A broken role mapping, a failing pair and an out-of-gamut step are findings. Perceived lightness throughout means OKLCH L, from 0 to 1. Whether a pair is required to pass belongs to better-accessibility. Surfaces, shadows and icon color belong to better-ui. Reuse the project's tokens and notation. A consistent hex system beats hex with oklch() scattered through it. For a new system, oklch() is the best default, because its numbers behave the way the ramp rules below describe. Everywhere else, a color library produces the same ramp in the project's own notation (color-formats.md). One neutral ramp, one accent ramp and only the status ramps the product actually renders. A warning ramp nothing imports is maintenance for zero pixels. A second accent hue earns its place only when two things must be distinguishable at a glance. Otherwi

This is an excerpt. Refer to the complete source and its current requirements.