Theming Systemby Owl-Listener

Theming System Skill.

Let one component library change appearance without duplicating its structure.

Design Systems
Theming

Source Review · Theming SystemSKILL.md

Task Design Systems Produces • A three-layer token architecture with override rules. • A theme matrix covering required color, brand, or density modes. • Component coverage and fixed-versus-themeable token guidance. Before You Start Implementation uses the project's token system or platform equivalents; runtime switching must be built and tested.

Editorial summary · source reviewed 2026-10-07 · not a generated example

01 What It Does

Support Multiple Themes Through Tokens

A layered theming architecture for shared components across brands, color modes, and density variants.

Source-based workflowNot an execution benchmark

The Working Approach

Theming System places theme differences in a layered token architecture. Raw palette values feed semantic roles, which then feed component-scoped tokens. Theme overrides primarily change the semantic layer, allowing the same components to serve different brands or color modes.

The source distinguishes themes from simply inverting colors. Dark surfaces, elevation, saturation, and image variants need deliberate treatment. It also lists density as a theme dimension, making the specification relevant beyond color alone.

Expected Deliverables

A three-layer token architecture with override rules.
A theme matrix covering required color, brand, or density modes.
Component coverage and fixed-versus-themeable token guidance.

See the Example Brief

From Brief to Review

01
Separate Token Layers
Identify raw primitives, purpose-based aliases, and component-level references.
02
Map Theme Overrides
Change semantic roles for each requested theme while preserving the component contract.
03
Check the Whole Library
Review every component in every supported theme, including imagery and OS preference behavior.

02 When to Use It

When to Use It

Implementation uses the project's token system or platform equivalents; runtime switching must be built and tested.

A Good Fit

Multi-Brand ProductsUseful when white-label or sub-brand interfaces must share a component library.
More Than Light and DarkProvides a structure for high-contrast or density variants as well.

Limits to Check

Not a Single Palette ExerciseChoosing one set of colors does not establish a maintainable theming architecture.
No Automatic Contrast CertificationEvery actual text, surface, and state combination still needs testing.

Bring These Inputs

Supported ThemesList brands, color modes, contrast modes, and density requirements.
Existing TokensSupply palette, semantic aliases, and component references.
Fixed Brand ElementsIdentify assets or values that must not change between themes.

03 Decisions That Matter

Decisions That Matter

Override at the Right Layer
Semantic aliases avoid scattering brand-specific colors throughout component implementations.
Assets Are Part of a Theme
Images and illustrations may need variants; changing CSS variables alone may not make dark mode coherent.

04 Try a Focused Brief

Try a Focused Brief

The example brief below has not been tested. Check the skill’s setup before using it.

Review the Setup

Use the repository's documented installation route and retain any referenced companion files. This entry describes a focused design method rather than an executable application.

Upstream Source File

https://github.com/Owl-Listener/designer-skills/blob/9a6930cf84a822eb458624bd11c61aac5bbdf224/design-systems/skills/theming-system/SKILL.md

Implementation uses the project's token system or platform equivalents; runtime switching must be built and tested.

Start With One Deliverable

Adapt the scope, source material and constraints in this brief before running the skill.

Example Brief

Use theming-system for a component library shared by two brands in light and dark modes. Define primitive, semantic, and component layers, identify fixed tokens, and show how theme overrides work. Include image variants and a component-by-theme QA matrix without assuming color inversion is sufficient.

Inspect the Result

Check the actual output against these observable criteria.

Component tokens resolve through documented semantic roles.
Themeable and fixed values are distinguished.
The test matrix includes every supported theme.

OpenDesign provides a local design workspace for coding agents. This listing does not mean the skill is bundled or that its external tools, credentials and software dependencies are included.

Download OpenDesign Read the Quickstart

05 Source and License

Source and License

This page describes the pinned source revision linked below. Upstream behavior and requirements can change.

Source Owner: Owl-Listener
Repository: Owl-Listener/designer-skills
Skill File: design-systems/skills/theming-system/SKILL.md
License: MIT
Reviewed Snapshot: 2026-10-07 · 9a6930cf84a8

Editorial Source Summary

A layered theming architecture for shared components across brands, color modes, and density variants.

Original summary by OpenDesign, based on the linked source. Repository stars are a dated popularity signal, not skill usage or a quality score.

06 Questions Before You Start

Questions Before You Start

Where should themes override tokens?

The source places the main overrides at the semantic layer between raw values and component-specific tokens.

Can density be a theme?

Yes. The source includes comfortable, compact, and spacious density alongside color and brand modes.

Does it prescribe one implementation tool?

It lists CSS custom properties, token files, Figma variable modes, and runtime switching rather than mandating one stack.

OpenDesign

Make Room for the Next Design Iteration.

Keep your brief, source material and design work together in a local workspace. Check the skill’s own setup before adding it to your workflow.

Download OpenDesign Browse Design Skills