Theming System
Define a three-layer token architecture so one component library supports light, dark, high-contrast, and white-label brand themes without forked CSS.
Overview
Theming System is an agent skill most often used in Build (also Ship for contrast and legibility checks) that designs token-mapping architectures for multi-brand, multi-mode component libraries.
Install
npx skills add https://github.com/owl-listener/designer-skills --skill theming-systemWhat is this skill?
- Three-layer token stack: global palette, semantic aliases (theme override point), and scoped component tokens
- Color modes (light, dark, high contrast, dimmed) plus brand, white-label, seasonal, and density themes
- Dark-mode guidance beyond inversion: elevation via surface brightness, desaturated colors, illustration variants
- Implementation paths: CSS custom properties, per-theme token files, Figma variable modes, runtime switching
- Best-practice rule: test every component in every theme and document themeable vs fixed tokens
- 3-layer token architecture (global, semantic, component)
- 4+ color mode types including high contrast and dimmed
Adoption & trust: 572 installs on skills.sh; 1.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have shared components but ad-hoc colors and one-off dark styles that break when you add a second brand or accessibility mode.
Who is it for?
Solo builders shipping a design system or multi-tenant SaaS who need dark mode, high contrast, and brand variants from one codebase.
Skip if: Teams that only need a single static palette with no component library or no plan to support OS-driven theme switching.
When should I use this skill?
You need theming architecture for brand variants, dark mode, high-contrast, or token mapping across a component library.
What do I get? / Deliverables
You leave with a tokens-first theme map, override rules at the semantic layer, and a checklist to validate every component across modes before shipping.
- Layered token architecture spec
- Theme type matrix (modes, brands, density)
- Themeable vs fixed token documentation
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Theming is where visual product identity is encoded before and alongside UI implementation—canonical shelf is Build because tokens and component overrides ship with the frontend. Frontend subphase covers design-system delivery: semantic aliases, component tokens, and CSS custom properties that every screen consumes.
Where it fits
Map semantic color tokens before building a clickable prototype so brand variants stay consistent.
Implement CSS custom properties and per-theme files aligned to the three-layer token model.
Validate contrast and legibility in high-contrast and dark modes before release.
Align seasonal or sub-brand theme overrides with store screenshots and marketing surfaces.
How it compares
Use for systematic token layers and theme types—not for one-off CSS color swaps in a single page.
Common Questions / FAQ
Who is theming-system for?
Indie and solo frontend builders, design-system owners, and agent-assisted coders implementing multi-mode UI with Claude Code, Cursor, or similar agents.
When should I use theming-system?
During Build when structuring tokens for a new app; before white-label or seasonal brand launches; when adding dark or high-contrast modes; and during Ship when verifying legibility and contrast across themes.
Is theming-system safe to install?
It is documentation and design guidance without shell or network permissions in the skill itself—review the Security Audits panel on this Prism page before adding any parent designer-skills package to your agent.
SKILL.md
READMESKILL.md - Theming System
# Theming System You are an expert in flexible theming architectures for multi-brand, multi-mode design systems. ## What You Do You design theming systems allowing one component library to support multiple visual themes through token mapping. ## Architecture - **Layer 1**: Global tokens (raw palette) - **Layer 2**: Semantic tokens (purpose-driven aliases) — themes override here - **Layer 3**: Component tokens (scoped) ## Theme Types - Color modes: light, dark, high contrast, dimmed - Brand themes: primary, sub-brands, white-label, seasonal - Density: comfortable, compact, spacious ## Dark Mode Considerations - Don't just invert — reduce brightness thoughtfully - Use lighter surfaces for elevation (not shadows) - Desaturate colors for dark backgrounds - Test text legibility carefully - Provide image/illustration variants ## Implementation CSS custom properties, token files per theme, Figma variable modes, runtime switching. ## Best Practices - Tokens-first: themes emerge from overrides - Test every component in every theme - Respect OS theme preferences - Document themeable vs fixed tokens