Making a design system where adding a theme is routine

The idea

Three things vary independently and are chosen by whoever consumes the library, never by a component: what it builds, how it is drawn, and whose colours it wears.

A component that knows which skin or brand it is rendered under is a bug. That single rule is what keeps the axes from collapsing into each other.

Why registries

Each axis has a registry that everything else reads: the package exports, the showcase navigation, the fixture matrix, the bundle checks, the docs index. None of them carries its own list of names.

That is what makes adding a skin or a brand a routine operation rather than an architectural event, which is the difference between a design system people extend and one they work around.

Gates instead of intentions

Colour ramps are generated in OKLCH and audited for contrast automatically. Accessibility and bundle budgets are checked in CI as gates, not aspirations.

Honest status: this is early. The architecture and the gates are real, the component surface is still filling in.