Figma Make Kit is transferring variables and tokens to CSS styles file that is full of syntax generic syntax errors like "\ /" and not adding units to variable values such as spacing, font sizing, and other. Therefore no style and tokens are applied using this kit and it is generating problems that needs to be fixed while consuming a lot of Make tokens(credits) while it is a CLEAR BUG.
Solved
Make Kit creating CSS library with syntax errors from Figma variables
Best answer by Jaycee Lewis
Hi tokens.md file.
## Unitless token values
All token values are unitless (e.g., `12`, not `12px`). You must add units yourself when a token needs them — otherwise the browser silently drops the declaration as invalid.
**CSS**
```css
/* tokens.css ships these as unitless numbers */
:root {
--spacing-3: 12; /* means 12px */
--gap-sections: var(--spacing-10); /* alias -> 40, still unitless */
}
/* Avoid: `gap: 12` is invalid; the browser drops it */
.row {
gap: var(--spacing-3);
}
/* Preferred: multiply by 1px so it resolves to a length */
.row {
gap: calc(var(--spacing-3) * 1px);
}
```
**TypeScript**
```tsx
// Avoid: Tailwind arbitrary value resolves to `gap: 12` (invalid)
<div className="gap-[var(--spacing-3)]" />
// Preferred: wrap in calc(); no spaces needed around `*` inside the brackets
<div className="gap-[calc(var(--spacing-3)*1px)]" />
```
## Escaping token names by string context
Token names use `\/` as a namespace separator. The number of backslashes you write depends on whether a JavaScript parser processes the string.
**1. Raw CSS (`.css`) — one backslash**
```css
color: var(--foreground\/primary);
padding: calc(var(--spacing\/4) * 1px);
```
**2. Tailwind classes in a plain JSX string attribute — one backslash**
JSX attribute strings are not JS strings, so the backslash is treated as literal.
```tsx
<div className="text-[var(--foreground\/primary)] p-[calc(var(--spacing\/4)*1px)]" />
```
**3. Any JavaScript string — double the backslash**
JS collapses `\\` to `\`. This covers inline style values, `clsx`/`cn`, variables, and template-literal classNames.
```tsx
<div style={{ color: "var(--foreground\\/primary)" }} />
<div className={cn("text-[var(--foreground\\/primary)]", cond && "...")} />
<div className={`p-[calc(var(--spacing\\/4)*1px)] ${x}`} /> // template literal!
```
> ⚠️ A single backslash inside a template literal or JS string is silently stripped at runtime, so the utility won't apply — grids, spacing, and borders collapse with no error thrown. We recommend plain string classNames so you don't have to double up.I'm happy to pass along any additional feedback to the team. Thanks again! — Jaycee
Hi @zaraket 👋 Thanks for the detailed report. Honestly, this is one of the sharper edges in how Make kits work right now, so you're not wrong for hitting it.
The short version: most of what you're seeing in that styles.css is the documented, expected output of a Figma Make kit—and the piece that makes Figma Make actually apply those values correctly lives in your kit's guidelines.
The \/ characters aren't syntax errors: When a Figma variable name contains a / (for example, --shadow/resting/small/blur), CSS requires a backslash to escape each slash when you reference it. The Figma Make kit docs show this — variable names use special characters and "in CSS you reference them with var() using the exact escaped names from the stylesheet (backslash before each /)," The shadow example shows it live as var(--shadow\/resting\/small\/1\/blur). \/ is valid, intentional escaping.
The unitless values are also by design: Figma Make kits generate the CSS with raw numeric values — spacing, font-size, radius, and more come through as plain numbers (16, not 16px). The docs state: "Most numeric values are unitless… If you write padding: var(--spacer-3) you'll get padding: 16 which is invalid CSS. Always use the calc() pattern." The units are meant to be applied when Figma Make writes the app code, as padding: calc(var(--spacer-3) * 1px). A raw value in the stylesheet is expected.
This is how kit extraction works: In the Figma Make kits FAQ: "Make kits currently don't support full extraction of design tokens. Instead, it pulls a subset of your variables and uses them to generate a global CSS file with raw values… Rather than a 1:1 mapping, you'll get a simplified view of your variables reflected in a single CSS file."
Where the fix lives: Make Kit guidelines. The mechanism that tells Figma Make to wrap values in calc(... * 1px) and use the escaped names is your guidelines.md/tokens.md files. The developer docs put it plainly: "To create polished outputs, Figma Make needs to know how to use the tokens that specify your colors, typography, spacing, radii, etc."—and the best practice is to "explain the quirks of your tokens before anything else" at the very top of the file. If those files are empty or incomplete, Figma Make doesn't know your tokens' quirks, which may produce the broken styling you're describing.
Figma Make reads the guidelines file automatically on every prompt: "so you don't have to re-state standing instructions each time." The credit guidance notes that without guidelines, you may end up paying in repeated correction prompts.
How to update guidelines:
-
Open your Figma Make file > click Code > open the guidelines folder in the file explorer > select
guidelines.md(andtokens.md). -
At the very top, document your token format quirks first. For example: that numeric values are unitless and must use
calc(var(--token) * 1px), and that names with special characters need the escaped form. (The Figma Make kits guide also has a ready-to-adapt example.) More info on how to edit guidelines
A couple of questions to make sure I’m understanding:
-
Are your kit's
guidelines.md/tokens.mdfilled in, or still empty/default? -
Is the broken styling in the
styles.cssfile itself (expected raw values), or in the app code Figma Make generates that's meant to consume those tokens?
Those two questions will tell us where things stand. If your guidelines.md / tokens.md are empty or default, that's likely the cause,. Adding the token quirks should resolve the styling and help with token usage. If they're already filled in and you're still seeing broken output, let me know. Thank you for the additional details. — Jaycee
Hello
Thank you for the detailed explanation and for clarifying that the escaped variable names (\/) and unitless numeric values are currently expected behavior within Figma Make Kits. I appreciate the transparency around how the current system works.
Regarding your questions, find be the corresponding answers:
guidelines.mdis filled automatically using Make Kit guidelines automatic generation.- The broken styling is in the
styles.cssbut is affecting any product using my generated Make it.
That said, my concern is less about whether these outputs are technically valid and more about why the responsibility for interpreting them is placed on the user when the entire pipeline originates from the Figma ecosystem itself.
Figma already knows:
-
the original design tokens and variables,
-
their semantic meaning (spacing, typography, radius, shadows, etc.),
-
their expected units,
-
and the naming hierarchy from which the exported CSS is generated.
Given that Figma Make Kits are generated directly from Figma design systems, it seems reasonable to expect that Figma Make would automatically understand and consume those generated artifacts without requiring manual documentation in guidelines.md or tokens.md. In other words, the kit should ideally be self-describing and immediately usable by the AI that Figma itself provides.
My main concern is the current workflow implication. If the AI fails to correctly interpret Figma-generated CSS and users have to spend additional prompts or Figma Make credits to repeatedly correct styling issues or explain token quirks, then users are effectively paying to work around a limitation in the platform's own export mechanism. I do not think spending AI credits to compensate for a Figma-generated output issue is an acceptable user experience (I spend all my enterprise monthly limit “4500credits” trying to fix it).
Wouldn't it make more sense for Figma Make to automatically apply these rules internally—such as understanding that numeric design tokens require unit application and that escaped token names should be referenced correctly—rather than relying on users to manually encode this knowledge in guidelines files?
From a product perspective, this seems like an opportunity for Figma Make to provide a much more seamless experience, especially since both the design token source and the AI code generation system are part of the same ecosystem.
I'd be interested to know whether there are plans on the roadmap to automate this process further and reduce the need for manual guideline maintenance.
Thank you again for the clarification.
Hi, @zaraket 👋 Thanks for the thoughtful follow up. I'll take your feedback about Figma Make automatically applying token units and escaping rules internally, rather than relying on manually maintained guidelines to my internal resources. For the remaining issue, before I move us to support can you help me with two questions, please?
- What's at the top of your
guidelines.md? Specifically: does it explicitly state that numeric values are unitless and must be wrapped ascalc(var(--token) * 1px), and that special-character names need the escaped form? - Where exactly is the styling breaking — in the
styles.cssfile itself (where raw unitless values are expected), or in the app code Figma Make generates?
Thanks! — Jaycee
Hello once again
I answered your questions in my last reply.
let me elaborate more:
- Here is what’s available at
guidelines.md:
Before hardcoding a color, spacing, radius, font-size, or any other style value, check the kit's stylesheet (imported per `setup.md`) for a CSS custom property that fits — e.g. `--primary-button`, `--text-default`, `--spacer-md`. Use the property via `var(--name)` (or the matching Tailwind utility, if the kit defines one) rather than a raw hex / px / rem value. Hardcoded values bypass the kit's theming and break dark mode, re-skinning, and any future token changes.
- While for styling, it is actually breaking in both, rendering in the same Make Kit file and using the same Kit in another product creation Figma Make files.
Hi tokens.md file.
## Unitless token values
All token values are unitless (e.g., `12`, not `12px`). You must add units yourself when a token needs them — otherwise the browser silently drops the declaration as invalid.
**CSS**
```css
/* tokens.css ships these as unitless numbers */
:root {
--spacing-3: 12; /* means 12px */
--gap-sections: var(--spacing-10); /* alias -> 40, still unitless */
}
/* Avoid: `gap: 12` is invalid; the browser drops it */
.row {
gap: var(--spacing-3);
}
/* Preferred: multiply by 1px so it resolves to a length */
.row {
gap: calc(var(--spacing-3) * 1px);
}
```
**TypeScript**
```tsx
// Avoid: Tailwind arbitrary value resolves to `gap: 12` (invalid)
<div className="gap-[var(--spacing-3)]" />
// Preferred: wrap in calc(); no spaces needed around `*` inside the brackets
<div className="gap-[calc(var(--spacing-3)*1px)]" />
```
## Escaping token names by string context
Token names use `\/` as a namespace separator. The number of backslashes you write depends on whether a JavaScript parser processes the string.
**1. Raw CSS (`.css`) — one backslash**
```css
color: var(--foreground\/primary);
padding: calc(var(--spacing\/4) * 1px);
```
**2. Tailwind classes in a plain JSX string attribute — one backslash**
JSX attribute strings are not JS strings, so the backslash is treated as literal.
```tsx
<div className="text-[var(--foreground\/primary)] p-[calc(var(--spacing\/4)*1px)]" />
```
**3. Any JavaScript string — double the backslash**
JS collapses `\\` to `\`. This covers inline style values, `clsx`/`cn`, variables, and template-literal classNames.
```tsx
<div style={{ color: "var(--foreground\\/primary)" }} />
<div className={cn("text-[var(--foreground\\/primary)]", cond && "...")} />
<div className={`p-[calc(var(--spacing\\/4)*1px)] ${x}`} /> // template literal!
```
> ⚠️ A single backslash inside a template literal or JS string is silently stripped at runtime, so the utility won't apply — grids, spacing, and borders collapse with no error thrown. We recommend plain string classNames so you don't have to double up.I'm happy to pass along any additional feedback to the team. Thanks again! — Jaycee
Thank you
Thank YOU
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.