Documentation.

The Zaklad Figma plugin is how your design system gets into Figma. Install it from the Figma Community, open it inside Figma, and enter your project API key to connect and pull the latest tokens.

To get your API key, open your project and go to Settings (the gear icon in the top right), then the Figma tab. Generate a key there and paste it into the plugin. After that, pulling updates takes one click from inside Figma.

After syncing, five things are immediately available in your Figma file:

• —Color variables: One variable per semantic color token, organised per theme. Each theme you have configured (light, dark, brand variants, accessibility modes, or anything else) becomes a separate variable mode. Variables are available directly in fill and stroke pickers.
• —Typography text styles: Every text style in your project lands directly in Figma's text inspector: heading sizes, body copy, captions, mono, and all XS–XL size steps. Font family, size, weight, line height, and letter spacing all come from your tokens. No manual setup needed.
• —Spacing and radius variables: All spacing and border-radius tokens as Figma number variables. Use them on auto-layout gaps, padding, and corner radius fields.
• —Icons: Your icon set lands in the Assets panel as ready-to-use components.
• —Components: Your full component library appears in the Assets panel, including all the variants and states you configured in the platform.

Everything synced is available directly in the file the plugin ran in. Text styles appear in the text inspector, color variables appear in fill and stroke pickers, and components and icons are in the Assets panel. To apply a color variable, select an element, open the fill picker, switch to the variable tab, and choose the semantic token you want: for example, color.bg.default for a surface background.

Variables are reactive. Once a token is applied to a fill or stroke, switching the theme on a frame (by changing its variable mode in the right panel) automatically updates every element inside it that uses a token. You do not need to manually reapply colors when switching between light, dark, or any other theme.

Components include an XS–XL size property that you can override per instance from the right panel. You can also set a master size for the whole canvas in the plugin, which becomes the default all components inherit unless individually overridden.

Most design tools require you to maintain each theme as a complete copy of every token. Change one value in your base theme and you have to find and update it in every other theme manually. On a system with multiple themes and hundreds of tokens, that maintenance burden compounds quickly and inevitably leads to drift.

Zaklad uses inheritance instead. Every theme is based on a parent and only stores the values where it genuinely differs. The bulk of tokens are inherited automatically. Change a border radius in your base theme and every child theme picks it up immediately, because none of them override it. Only the intentional differences need to exist.

Inheritance can go as many levels deep as you need. A typical setup might look like: one core brand at the top, then a child theme per product or brand, then light and dark variants within each, and then accessibility modes (high contrast, and so on) as children of those. Or it could be as simple as just light and dark. The structure is entirely up to you.

The hard, manual part of a design system is rarely the design. It is everything after: turning the colours, type, and spacing you decide on into something developers can actually install, keeping it in sync as it changes, and versioning it so nothing breaks downstream. That pipeline normally needs engineers, and it is the single biggest reason design systems stall. The platform does it for you.

When you publish a release, your tokens, typography, and components are transformed into a production-ready developer package and a Figma library from the same source, with no handoff and no translation step in between. The thing designers usually export, document, and hope is interpreted faithfully is instead generated directly from what you built.

Versioning works a little differently across the two outputs:

• —Developer package: every release is versioned automatically. Each publish gets its own version number, so developers upgrade deliberately and can pin to an earlier version if they ever need to.
• —Figma, free plan: your library always reflects the latest state. Each time you pull from the plugin you get the current system, not a pinned version.
• —Figma, paid plans: you can pin a Figma file to a specific published release, so Figma and the developer package stay locked to matching versions. You can still publish your own library versions inside Figma on top of that if you want Figma-native version control as well.

You can edit colours in whichever notation you think in. The picker offers four: oklch, hcl, rgba, and hex. These are input and display formats only. They change how a value is shown and typed, not how it is stored, so switching from OKLCH to HEX never changes the colour, only its notation.

We recommend OKLCH. It is perceptually uniform: equal numeric steps in lightness produce equal visual steps to the eye, so a palette built in OKLCH looks evenly spaced rather than bunching up in the midtones. Hue also stays consistent as lightness changes, and it has native CSS support. HCL is a perceptually uniform alternative that can shift hue slightly in blues and purples at the extremes. RGBA and HEX are widely understood but not perceptually uniform, so equal numeric steps do not produce equal visual changes.

Colours can carry an alpha channel. When a colour is less than fully opaque it is stored as an 8-digit hex value (#RRGGBBAA), where the last two digits are the opacity. OKLCH and RGBA both expose an alpha control in the picker; plain 6-digit HEX has no transparency, so the editor promotes a colour to 8-digit automatically when you add alpha.

Translucent palettes hold a fixed colour and vary only the opacity across their steps, rather than varying lightness. They are the right tool for overlays, scrims, hover and pressed states, and any surface that needs to tint whatever sits behind it. Swatches for translucent colours show a checkerboard behind them so you can read the transparency at a glance.

Each colour palette is generated from a lightness curve: a line that decides how quickly a colour moves from its lightest step to its darkest. A gentle curve keeps the light end airy; a steeper one drops into shadow faster. Because every step follows one shared curve, the palette stays perceptually even instead of clustering.

You can reshape this curve from any foundation colour group: open the group menu and choose Edit curve. The editor lets you drag the curve, set how many steps the palette has, and adjust chroma (saturation) and hue. Changing the curve regenerates every step in that palette at once, so you tune the whole ramp in one place rather than hand-picking each shade.

The system is built so you change a decision once, in one place, and it propagates everywhere. Edit a foundation colour and every semantic token that references it, every component that uses those semantic tokens, every theme, and every Figma variable updates together. You never hunt down each usage by hand.

The same is true for sizing. Spacing and radius steps are computed from a single base value, so nudging the base reflows the entire scale proportionally. For designers this means a brand refresh is a handful of edits, not an audit of hundreds of values.

For the full picture of how the layers chain together, foundation to semantic to component, see the Token System tab.

Once part of your system is settled, you can lock it to prevent accidental edits. Lock a token group, a text style, an icon set, a font family, or a component from its lock icon, and its add, edit, delete, and reorder controls are hidden until you unlock it. Locks are saved with the project, so they persist across sessions and apply for everyone on the team.

Locks are also respected by AI. A connected assistant can read a locked item but can never modify it, so locking is a reliable guardrail whether the next edit comes from a person or a tool. Read more in the MCP & AI tab.

Every project generates a DESIGN.md file: a single plain-prose document describing your full design system. Resolved token values per theme, typography specs, spacing scale, component anatomy. It is regenerated automatically on every change, so it is always current.

It is useful for handing to any AI tool at the start of a session, sharing with developers as a design brief, or onboarding new team members. Read more in the MCP & AI tab.