> ## Documentation Index > Fetch the complete documentation index at: https://docs.frontic.com/llms.txt > Use this file to discover all available pages before exploring further. # Design Library The **Design Library** holds your brand as tokens — colors, typography, corners, borders, shadows, and logos — as one published source of truth that everything Frontic builds reads from. Find it at **Library → Brand** in the admin app. The Design Library is in **Preview** and rolling out gradually. The reason it exists: agents are good at design and bad at remembering. Told "use our brand blue", an agent will produce a blue, then a slightly different blue next week. Tokens remove the guess. The [Experience Designer](/designer/overview) can only reference brand tokens — a hardcoded brand color, font, or corner radius fails its build — so every experience is on-brand by construction rather than by review. ## Getting a brand Two ways to start. **Recommended.** Derives your brand from your live shop — colors, fonts, corners, and logos, grounded in what it already looks like. Begin with quiet Frontic defaults and shape every token by hand. Either way you can change everything afterwards. A token that's never been touched is marked as using the Frontic default, so it's easy to see what came from your shop and what's still a placeholder. ## What's in it ### Colors Colors are grouped by what they're *for*, not by what they look like: | Group | Covers | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **Commerce** | The commerce-specific roles: add-to-cart, checkout, promotional surfaces, discounts and was-prices, "new in" badges, price text | | **Surfaces** | Backgrounds, cards, elevation | | **Actions** | Primary and secondary actions | | **Accents** | Hover and selected states | | **Edges & focus** | Borders, inputs, focus rings | | **Feedback** | Positive, warning, destructive, info | The Commerce group is the one that's unique to Frontic, and it's the reason experiences come out looking like commerce rather than like a landing-page template. An add-to-cart button is styled from the `buy` token even when `buy` and your primary action currently resolve to the same color — so when you restyle later, the two move independently and the storefront stays correct. Every color slot has a **foreground partner**: the color of content sitting on it. The editor checks contrast between the pairs and tells you the ratio and whether it passes AA, so a brand decision that would make text unreadable is caught while you're making it, not after it ships. Colors can be organized into folders and renamed. A token can also **reference** another token instead of carrying its own value — useful when three roles should always move together. References that can't be resolved block publishing. ### Typography Three roles: **Body**, **Headings**, and **Code**. Each is either a system stack or a custom family, and each carries a full font-family stack rather than a single name. Text styles sit on top — named sizes that ride the scale, so a style either pairs its line height and weight onto a scale step or defines its own. ### Shape **Base radius** drives the whole `sm`–`xl` scale. Set it to 0 and everything goes sharp at once. **Borders** and **shadows** are named styles rather than loose values: a border carries a width and a style, a shadow carries one or more layers. Naming them is what lets an agent pick "the card shadow" instead of inventing one. ### Logos Three slots — **Desktop**, **Mobile**, and **Favicon** — pulled from your shop during [Initialize](/context-base/initialize). They're read-only in the Library. ## Draft and published The Library edits a **draft**. Nothing an agent builds with changes until you publish it. * Edits save to the draft as you make them, and the header shows how many tokens differ from the published brand * **Publish** creates a new version and makes it the live brand * Connected experiences pick the new brand up **on their next build** — publishing a brand never changes anything for shoppers on its own That last point matters. Publishing a brand is not a deploy. A live experience keeps rendering with the brand it was built against until someone rebuilds and republishes it, which means you can revise your brand without a storefront-wide visual change landing unannounced. ### Version history Every publish is kept. Restoring an earlier version creates a **new draft** from it rather than making it live, so a restore is something you look at before it counts. **Reset brand** goes further back: it restores the original result from Initialize and discards every edit and import since. Published versions stay in history either way. ## Exporting The **Export** dialog gives you the brand in three shapes: | Format | Use it for | | ------------------- | ------------------------------------------------------------------------------------------------------ | | **Tailwind CSS v4** | Drop-in replacement for your `theme.css`, imported at the top of your global stylesheet | | **CSS variables** | Framework-agnostic custom properties — reference tokens as `var(--color-background)` in any stylesheet | | **Brand artifact** | The resolved artifact publishing writes, with every reference flattened to a plain value | This is how the brand reaches a storefront [Studio](/studio/frontic-studio) built, or a codebase that predates Frontic — export once, and your own frontend and your experiences share the same values. ## Related Derive the brand from your live shop in one pass. The surface that builds exclusively from these tokens. The styleguide rule — what each color is *for* in this shop. The component library the token names follow.