---
name: figma-variables-tokens
description: "Set up Figma Variables — modes for light/dark, semantic tokens, scoping, and code-export to CSS/Tailwind. Builds a production Figma Variables system: collections + modes (light/dark/brand), primitive → semantic token layering, scoping, aliasing, and the export pipeline to CSS custom properties / Tailwind config / design-token JSON. The bridge between design and code that keeps both in sync."
license: MIT
---

# Figma Variables & Tokens

Stand up a real, multi-tier Figma Variables system and wire it to your codebase. This skill structures collections, modes, and aliased semantic tokens the way a design-system team actually maintains them, then generates the export artifacts your frontend consumes. It's for designers who own a design system and the frontend engineers who have to keep CSS, Tailwind, and Figma from drifting apart.

## When to use it

- You're migrating from raw color/number styles to Figma Variables and need a sane primitive→semantic layering.
- You want light/dark (and optionally brand or density) handled through **modes** on a collection instead of duplicated frames.
- Your tokens live in Figma but your code has hand-maintained CSS variables, and the two keep diverging.
- You need a repeatable export to W3C design-token JSON, CSS custom properties, or a `tailwind.config` theme.

## How it works

The skill builds two collections: a **Primitives** collection (`color/blue/500`, `space/4`, `radius/md`) with one mode, and a **Semantic** collection (`bg/surface`, `text/default`, `border/subtle`) with `Light` and `Dark` modes whose values **alias** primitives via `figma.variables.setVariableValue` references. It applies **scoping** so a color token only appears in fill pickers, a radius token only in corner-radius fields, etc., and sets **code syntax** per variable (Web/Android/iOS) so exports carry the right names.

Token data is read through the REST `GET /v1/files/:key/variables/local` (Enterprise) or the Plugin API (`figma.variables.getLocalVariableCollectionsAsync`). The skill normalizes that into W3C `$value`/`$type`/`$ref` JSON, then transforms it — Style Dictionary–style — into `:root` / `[data-theme="dark"]` CSS blocks and a Tailwind `theme.extend` map pointing at the CSS vars.

## Example

```bash
curl -fsSL --create-dirs -o ~/.claude/skills/figma-variables-tokens/SKILL.md https://claudeskil.com/skills/figma-variables-tokens/SKILL.md

# After connecting your file:
> Build a primitive + semantic token system with light/dark modes,
  scope the color tokens to fills/strokes, and export to
  tokens.json, src/styles/tokens.css, and tailwind.config.js
```

Resulting CSS:

```css
:root { --bg-surface: var(--color-white); --text-default: var(--color-gray-900); }
[data-theme="dark"] { --bg-surface: var(--color-gray-950); --text-default: var(--color-gray-50); }
```

## Tips & gotchas

- **Alias, don't hardcode.** Semantic tokens should reference primitives so a palette change ripples everywhere. Raw hex in a semantic token is the #1 maintenance trap.
- Modes are **per collection**. Don't put light/dark on the primitives collection — keep primitives single-mode and let semantics flip.
- The local-variables REST endpoint is **Enterprise-only**; on other plans the export runs through the Plugin API instead.
- Set **code syntax names** early — renaming a variable later doesn't auto-update existing exports.

## FAQ

**Does this support nested/component variable bindings?**
It exports the variable definitions and aliases. Bindings on layers stay in Figma; the code side consumes the generated CSS/Tailwind names.

**Can I round-trip edits from code back to Figma?**
Export is one-directional by default (Figma → code). Writing back requires the Plugin API and is treated as a separate, explicit step.

**W3C JSON or Style Dictionary format?**
It emits W3C `$type`/`$value` JSON, which Style Dictionary 4 consumes directly if you prefer your own build.
