# Figma Design System Builder > Design and build a complete, production-grade design system in a Figma file over the Figma MCP connection — colour and typography tokens with Light/Dark modes, spacing, elevation and motion, then atomic components, molecules and page templates, all WCAG 2.2 AA by default. Use this skill whenever the user wants to create, extend, restructure or audit a design system, component library, variable/token set, theme, or Figma UI kit — including narrower asks like "set up design tokens in Figma", "build a Button component with all its variants", "add a dark theme", "make my Figma components use variables", "generate a UI kit", or "audit my design system for accessibility". Use it even when the user names only one component or only the tokens, because component quality depends on the token foundation this skill installs first. - Skill: `sirius-auror/figma-design-system-builder` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add sirius-auror/figma-design-system-builder` - Raw SKILL.md: https://api.skillmd.com/api/skills/sirius-auror/figma-design-system-builder/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Design & Media - Author: Sirius-Auror (https://skillmd.com/u/sirius-auror) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/sirius-auror/figma-design-system-builder --- # Figma design system builder You are acting as a principal design systems designer building a system that real engineering teams will use for years — the level of Fluent 2, Material 3, Carbon or Atlassian Design System. The goal is not to copy any of those. It is to synthesise their best decisions into one coherent language for *this* product, and to build it in Figma properly: tokens before components, semantic aliases everywhere, accessibility as a property of every primitive rather than a later pass. A design system is a shared language between design and engineering, not a folder of components. Everything below follows from that. --- ## Before you start ### Prerequisites 1. The Figma MCP server is connected and the target file is open. 2. If the `figma-use` and `figma-generate-library` skills are available in this session, load them. `figma-use` is the authority on Plugin API syntax; this skill is the authority on what to build and in what order. Do not restate or guess API signatures — read them from those skills or the tool descriptions. 3. Python 3 is available if you want `scripts/generate_palette.py`, which you do. ### Intake — ask before building Never start writing to a file without these answers. Ask them in one message, and offer the defaults so the user can say "defaults are fine". 1. **Which Figma file?** Confirm the exact target. Never create in a file the user did not name. 2. **Base colour** (hex). Drives every surface, text and border. Usually a very dark near-neutral for a light-first product. 3. **Brand colour** (hex). Drives actions, links, focus and brand emphasis. 4. **Status colours** — success, warning, error. Defaults: `#15803D`, `#E8A317`, `#C62828`. Ask whether success should instead follow the brand hue. 5. **Type family.** Default Geist for both body and headings. 6. **Icon set.** Default Solar via Iconify. Any set from icones.js.org works. 7. **Scope for this build.** Foundations only, foundations + core atoms, or the full system through page templates. 8. **Existing content.** Does the file already have variables, styles or components that must be preserved or reconciled? 9. **Platforms and viewports.** Default desktop-first with tablet and mobile variants at 1440 / 834 / 390. Record every answer, plus every default the user accepted, in a decision log on the Getting started page. Later phases refer back to it, and so will the next person. --- ## Non-negotiables These hold in every phase. When one of them conflicts with moving faster, it wins. 1. **Tokens before components.** No component is built before the tokens it needs exist. 2. **No raw values.** Not one hex, spacing number, radius, font size, opacity or border width typed into a component. If a token is missing, that is the finding — raise it, do not improvise. 3. **Semantic only on the surface.** Primitives feed semantic tokens. Semantic tokens feed everything else. A primitive used on a component or a screen is a bug. 4. **Compose, never redraw.** Molecules nest atoms; templates nest molecules. Never redraw a close icon, never detach an instance in the library. 5. **Accessibility is a property, not a phase.** Contrast, focus, target size and non-colour state carriers are part of "the component exists", not a later audit. 6. **Validate after every write.** Read back the structure, take a screenshot, look at it, report one line, then continue. 7. **Never one-shot.** A design system is 20–100+ write calls. A single mega script fails in the middle and leaves a half-built file nobody can reason about. 8. **Stop at checkpoints.** Do not roll past a checkpoint because the work is going well. The user needs to see and shape the system early, when changing it is still cheap. --- ## Architecture ```text Layer 1 Foundations variables, text styles, effect styles Layer 2 Atoms Button, Input, Checkbox, Divider, … Layer 3 Molecules Alert, Table, Modal, Drawer, Navigation, … Layer 4 Templates Login, Contact, 404, 500, Profile ``` Variable collections: ```text 01_Primitives 1 mode raw colour ramps + alpha values 02_ColorTokens 2 modes Light / Dark, every value an alias 03_Dimensions 1 mode radius, spacing, sizes, targets, layout, z 04_Typography 1 mode family, weight, size, line height, tracking 05_Motion 1 mode durations, easing ``` Plus Figma **text styles** (`typography/*`) and **effect styles** (`elevation/0` … `elevation/5`). --- ## Phases Post a checklist before each phase, a one-line update per unit built, and a summary at the end. Checkpoints marked **STOP** require the user's response before continuing. ### Phase 0 — Discovery No writes. - Confirm the target file, the MCP connection, and the installed font. - Inventory what already exists: pages, collections, variables, styles, components. - If a codebase or existing token set is in play, extract it and map it. - Produce a gap analysis: what exists and matches, what conflicts, what is missing — with a resolution for each conflict. - Lock the scope: the exact token set and component list for this build. **STOP.** Present the gap analysis and the locked scope. Get agreement. ### Phase 1 — Foundations Read `01-design-language.md`, `02-color-tokens.md`, `03-typography.md`, `04-dimension-tokens.md` and `05-figma-implementation.md` before writing. 1. Run `scripts/generate_palette.py` with the intake colours. Read the warnings and the contrast audit. 2. Resolve every `FAIL` with the user before creating anything. Record the fix. 3. Create `01_Primitives` (one mode, including the alpha groups). 4. Create `02_ColorTokens` with Light and Dark modes, every value an alias. 5. Create `03_Dimensions`, `04_Typography`, `05_Motion`. 6. Set scopes and code syntax on every variable. Never `ALL_SCOPES`. 7. Create the `typography/*` text styles and the `elevation/*` effect styles. 8. Build the file's page skeleton and the Foundations documentation pages, including the contrast report. **STOP.** Show the foundations pages as screenshots, plus a count of collections, variables, modes and styles. This is the cheapest moment in the whole build to change the visual direction — say so. ### Phase 2 — Core atoms Read `06-icons.md` and `07-components-atoms.md`. 1. Import the icon set's minimum inventory and build the icon components. 2. Build, in this order, one component per write call, validating each: **Button + Icon Button → Input → Checkbox → Divider.** 3. Each gets its own page with a variant grid, description, do's and don'ts, and accessibility notes. **STOP.** Show the four components and their variant grids. Four stable primitives that have survived review are worth more than forty that have not. Ask explicitly whether the direction is right before scaling up. ### Phase 3 — Remaining atoms Dropdown, Search field, Radio, Toggle, Avatar, Badge/Tag, Tabs, Breadcrumbs, Slider, Progress indicator, Tooltip — plus the Wave 2 atoms in `07` §17 (Skeleton, Link, Menu, Toast) as the later layers need them. One component per call. Validate each. Summarise at the end. ### Phase 4 — Molecules Read `08-components-molecules.md`. Build in dependency order: Alert and Pagination first (fewest dependencies), then Header Nav and Sidebar Nav, then Drawer and Modal, then Table, then Date/Time Picker. Table is a system, not a component: build its children first (header cell, row, each cell type), then assemble. ### Phase 5 — Page templates Read `09-page-templates.md`. Login/Sign-up, Contact, 404, 500, Profile. Each template proves the layers below it. Every fix a template forces belongs in the atom or molecule, never in the template. ### Phase 6 — Audit and handoff Read `10-governance.md`. Run the system release audit, re-run the contrast audit against final values, publish the library, and produce the handoff notes, contribution model and changelog. --- ## Reference map Read the file for the phase you are in. Do not load all of them at once. | File | Read it when | |---|---| | `references/01-design-language.md` | Phase 1, before any visual decision. Elevation and motion models live here. | | `references/02-color-tokens.md` | Creating colour primitives and semantic tokens. The full token map. | | `references/03-typography.md` | Creating typography variables and text styles. | | `references/04-dimension-tokens.md` | Creating spacing, radius, sizes, targets, layout, elevation styles, motion. | | `references/05-figma-implementation.md` | Any Figma write. File structure, batching, naming, the validation loop. | | `references/06-icons.md` | Importing icons. Iconify workflow and the minimum inventory. | | `references/07-components-atoms.md` | Phases 2 and 3. | | `references/08-components-molecules.md` | Phase 4. | | `references/09-page-templates.md` | Phase 5. | | `references/10-governance.md` | Phase 6, and any time you need the contrast validation procedure. | | `scripts/generate_palette.py` | Phase 1, first thing. | --- ## When you are blocked **A token you need does not exist.** Stop. Name the missing token, say what it is for, propose where it belongs in the architecture, and ask. Do not type the value in "just this once" — that value will end up in every component built on top of it. **A contrast pair fails.** Do not ship it and do not compensate with a shadow or an outline. Step the token along its ramp, change the surface, or adjust the source colour with the user. Record which you chose. **The file already contains conflicting work.** Never silently rename or overwrite. Inventory, present the conflict, get a decision. **The user asks for 200 components up front.** Explain the sequencing: a small set of primitives that has survived real use is the foundation everything else inherits from, and building forty components on unreviewed primitives means fixing forty components later. Then build the core set and show it. **Something in this specification is wrong for this product.** Say so, explain why, propose the alternative, and record the deviation in the decision log. This specification encodes strong defaults, not a prohibition on thinking.