Live demo

1 · Input Seed or prompt

A hex seed + algorithm (deterministic), or prose like "calm forest, soft corners" via an optional LLM.

2 · Source skin.json

The reviewable source of truth — algorithm, seed, knobs. skins:refine edits knobs; never hand-edit the artifact.

3 · Artifact tokens.css

skins:rebuild re-emits the full token contract (light + dark) from the source. This is what the site loads.

skins:generate Swap one tokens.css (tenant, domain, locale)

Theme the site

Theming a Semitexa site is not a refactor — it is choosing which token values load. Because every primitive and component only ever speaks --ui-* tokens, re-theming touches zero components.

1bin/semitexa skins:generate balanced "#2f5e52" --name=moss --write

bin/semitexa skins:generate balanced "#2f5e52" --name=moss --write

How it applies

The theme system selects a skin for a (tenant, domain, locale) context and loads its tokens.css last, so it wins the cascade. Light and dark are two value sets of one contract, toggled by data-skin-mode. Pick the algorithm that fits the brand (balanced, glass, brutalist) and tune with knobs; generate or refine iteratively.

This very showcase is the proof: the same templates render moss here and terracotta on framework.semitexa.test — one tokens.css swapped for another, no per-site override.

When identity lives in tokens, theming is data, not code: re-skin by swapping a file, support multi-tenant by a lookup, and never touch a component. Next: ship an interactive component.

1# generate a skin from a seed colour2bin/semitexa skins:generate balanced "#2f5e52" --name=moss --write

# generate a skin from a seed colour
bin/semitexa skins:generate balanced "#2f5e52" --name=moss --write

1# the theme resolver picks it per (tenant, domain, locale) and loads tokens.css last2# every primitive + component repaints — no component edits

# the theme resolver picks it per (tenant, domain, locale) and loads tokens.css last
# every primitive + component repaints — no component edits

How it works

Generate a skin (skins:generate <algorithm> "<hex>" --name=<slug> --write), then the theme system selects it for a (tenant, domain, locale) context and loads its tokens.css last. Light and dark are two value sets of one contract, toggled by data-skin-mode. This showcase is the proof: the same templates render moss here and terracotta on framework.semitexa.test — one tokens.css swapped for another.

Why it matters

When identity lives in tokens, theming is data, not code: re-skin by swapping a file, support multi-tenant by a lookup, and never touch a component. The maintenance tax of a hand-themed UI disappears.