theminglisted

# Theming A theme system keeps component roles stable while their values change. Components reference semantic tokens such as `--color-bg`, `--color-text`, and `--color-focus`; supported light, dark, or branded modes remap those roles without rewriting components. This skill builds that system. The hard part isn't the control — it is tuning each supported mapping in context. Dark is not inverted light, an authored high-contrast theme is not forced colors, and no mode earns an accessibility claim without measurement. ## The decision order 1. **Semantic tokens first.** Define roles (`--color-bg`, `--color-surface-1/2` (`-3` if elevation needs it), `--color-text`, `--color-text-muted`, `--color-border`, `--color-primary`, `--color-primary-hover`, `--color-primary-ink`, `--color-accent`, `--color-accent-ink`, `--color-success`, `--color-error`, `--color-warning`, `--color-info`, `--color-focus` — the canonical contract names). Components use these only. (Palette comes from `color-system`.) 2. **Choose the product baseline.** Start with the application's default supported mode; it may be light, dark, or brand-specific. Set structure and role relationships there. 3. **Tune every additional mapping**, never invert it — for dark, a surface *ramp* (each elevation step lighter, not shadowed), comfortable text contrast on dark surfaces, and accents retuned for the surrounding lightness. (Depth in `references/surfaces-and-elevation.md` + `color-and-contrast.