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, these things are immediately available in your Figma file:

• —Color variables: One variable per semantic color token, organized 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.
• —Effect and paint styles: Shadow and blur tokens become effect styles, and gradient tokens become paint styles, both published to your file's style library and bound automatically on the components that use them. Borders sync as variable-aliased strokes with a dash pattern.

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 colors, 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 colors 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 color, 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.

Colors can carry an alpha channel. When a color 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 color to 8-digit automatically when you add alpha.

Translucent palettes hold a fixed color 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 colors show a checkerboard behind them so you can read the transparency at a glance.

Each color palette is generated from a lightness curve: a line that decides how quickly a color 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 color 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 Motion Builder generates a complete set of motion foundation tokens in one action: a duration ramp, named easing curves, and ready-made transition composites. To open it, click the add button in the Foundation column and choose Motion from the group type picker.

Simple mode

Simple mode shows two choices. Speed feel controls the overall pacing: Standard suits most products, Snappy suits dense or data-heavy UIs, and Relaxed suits marketing sites or rich animation. Easing style is either Material (Material Design 3 spatial curves, expressive and physically grounded) or Classic CSS (the browser-native ease-in/ease-out equivalents, safe for all audiences). A live preview plays sample enter, exit, and move animations with your chosen settings so you can feel the result before creating.

Advanced mode

Advanced mode exposes the full controls: choose from three duration presets (Standard, Snappy, or Relaxed) and then edit the individual step values in milliseconds; pick the easing family or enter custom cubic-bezier values per direction; and toggle whether transition composites are generated alongside the foundation tokens. Switching back to Simple mode is lossless.

The builder creates everything in one undoable change: five named duration tokens at motion.duration.*, three directional easing tokens at motion.easing.*, and (when enabled) fifteen transition composites at motion.transition.<speedGroup>.<direction>. You can customise the root group name if you need more than one motion system in one project.

The system is built so you change a decision once, in one place, and it propagates everywhere. Edit a foundation color 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.

Text styles are the named typographic roles your components use: Heading 1, Body Default, Caption, Code, and so on. They differ from typography foundation tokens (which store raw values like font families and sizes) in that they describe a complete typographic intent and can vary per breakpoint.

Using the Text Style Wizard

Click the add button in the Text Styles column and choose Generate a set to open the wizard. It creates a full cohesive set of styles in one action. You choose a display font and a body font (with live previews), a type scale (modular ratio and step count), how many heading levels and body variants to include, and whether to add caption and code styles. The wizard shows exactly which styles it will create and their computed sizes before you commit.

The Mono role automatically generates a Code style. Font sizes have a 10px floor. If you enable responsive sizing, each style can have different sizes at different breakpoints, shown in the preview with a tier selector. If style names already exist, the wizard offers to skip or rename the conflicting ones.

Adding a single style

Choose "Add a custom style" from the same chooser to add one style manually. This is useful for one-off additions after a wizard run. You set the font family, weight, size, line height, and letter spacing directly, with a per-tier sizing map for responsive control.

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.