var() anywhere it takes a token value. So a Chakra system whose values are
Livry’s custom properties rebrands entirely when the stylesheet changes — no provider swap, no
re-render.
Theme integration required: a pair whose library is Chakra UI. It builds tokens.css.
1. Link the stylesheet
2. Build the system
DEFAULT is how a token can be both a value and a group. color.brand and color.brand.500
both exist in plenty of token sets, and a JavaScript object cannot hold a value and children under
one name. DEFAULT is Chakra v3’s own spelling for exactly that — colors.brand.DEFAULT is
addressed as brand.3. Wrap your app
4. Use Chakra normally
Generate it
The portal’s Integration tab generates the wholetheme.ts from your actual Theme: your tokens,
categorised into Chakra’s token groups, with var() values and your real fallbacks.
Copy it once and edit freely. Which Chakra token each variable becomes is your naming decision, and
Livry only guessed — but it stays right for every Variant, because a Variant changes values and
never names.
Semantic tokens
Chakra’s semantic tokens work as usual, and they compose well with Livry: keep the raw values pointing at Livry, and express meaning on top.Decide where meaning lives. Either model semantics in Livry as aliases —
color.fg.accent
aliasing color.brand — so a brand can override the semantic layer, or model them in Chakra as
above, so they are fixed across brands. The first is more flexible; the second is more predictable.
Doing both in the same theme gets confusing quickly.Dark mode
Chakra’s_dark conditions work unchanged, because they select on the DOM rather than on token
values. Point each side at its own Livry token: