Figma Generate Library
Orchestrate a codebase-aligned Figma design system—tokens, variants, light/dark theming, and component libraries—in the right build order alongside the figma-use API skill.
Overview
figma-generate-library is an agent skill most often used in Build (also Validate for code–Figma reconciliation) that orchestrates professional design-system creation in Figma from a codebase.
Install
npx skills add https://github.com/figma/mcp-server-guide --skill figma-generate-libraryWhat is this skill?
- Multi-phase workflow across 20–100+ orchestrated use_figma calls with quality patterns from Material 3, Polaris, and sim
- Creates variables/tokens, variant sets, light/dark theming, foundations docs, and full libraries—not one-off frames
- Reconciles gaps between codebase tokens/components and what exists in Figma
- Must load figma-use in parallel for Plugin API syntax; pass skillNames: figma-generate-library on each use_figma call
- Applies even when generating a single component so variable foundations and bindings stay production-grade
- Orchestrates workflows across 20–100+ use_figma calls
- References quality patterns from systems such as Material 3, Polaris, Figma UI3, and Simple DS
Adoption & trust: 1.8k installs on skills.sh; 1.6k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your React or web codebase has real tokens and components but Figma is missing, out of date, or full of unbound variants that will not scale with theming.
Who is it for?
Indie builders shipping a SaaS or mobile UI who already use Figma MCP and need a disciplined build sequence from tokens through themed components.
Skip if: Quick wireframes with no token strategy, or teams that only need raw Plugin API snippets without design-system methodology (use figma-use alone).
When should I use this skill?
User wants to create or update a design system in Figma from a codebase, including variables, libraries, theming, documentation, code–Figma reconciliation, or any Figma component that needs production-grade tokens and va
What do I get? / Deliverables
You get an ordered, production-quality Figma library with variables, variants, and documentation aligned to code—ready for designers and devs to share the same source of truth after figma-use executes each step.
- Variable and token foundations with light/dark (or multi-mode) theming
- Component library with variant sets and variable bindings aligned to code
- Foundations documentation and gap-reconciliation notes where code and Figma diverged
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Design systems and production components are created during product build when UI must match code and ship-quality Figma assets. Frontend is the canonical shelf because the skill binds variables, variant sets, and components to how the product is actually built and themed.
Where it fits
Audit which code tokens and components are missing in Figma before committing to a full library rebuild.
Stand up variables, variant sets, and themed components so new screens in Figma match shipped UI patterns.
Document foundations and usage in Figma so future solo updates do not break bindings or modes.
Hand partners or contractors a consistent library for marketing surfaces that still respects brand tokens.
How it compares
A design-system orchestration playbook paired with figma-use—not a substitute for learning individual Figma Plugin API calls.
Common Questions / FAQ
Who is figma-generate-library for?
Solo and indie builders (and small squads) who maintain Figma alongside code and want libraries that match production tokens, variants, and themes—not one-off mockups.
When should I use figma-generate-library?
During Build when creating or updating UI foundations and components; during Validate when reconciling what code ships versus what Figma shows; and whenever any new Figma component must bind to existing variables and variant rules.
Is figma-generate-library safe to install?
It drives many automated Figma edits via your MCP setup—review the Security Audits panel on this Prism page and confirm you trust the figma-use integration and repo before granting agent access.
Workflow Chain
Requires first: figma use
SKILL.md
READMESKILL.md - Figma Generate Library
# Design System Builder — Figma MCP Skill Build professional-grade design systems in Figma that match code. This skill orchestrates multi-phase workflows across 20–100+ `use_figma` calls, enforcing quality patterns from real-world design systems (Material 3, Polaris, Figma UI3, Simple DS). **Prerequisites**: The `figma-use` skill MUST also be loaded for every `use_figma` call. It provides Plugin API syntax rules (return pattern, page reset, ID return, font loading, color range). This skill provides design system domain knowledge and workflow orchestration. **Always pass `skillNames: "figma-generate-library"` when calling `use_figma` as part of this skill.** This is a logging parameter — it does not affect execution. --- ## 1. The One Rule That Matters Most **This is NEVER a one-shot task.** Building a design system requires 20–100+ `use_figma` calls across multiple phases, with mandatory user checkpoints between them. Any attempt to create everything in one call WILL produce broken, incomplete, or unrecoverable results. Break every operation to the smallest useful unit, validate, get feedback, proceed. --- ## 2. Mandatory Workflow Every design system build follows this phase order. Skipping or reordering phases causes structural failures that are expensive to undo. ``` Phase 0: DISCOVERY (always first — no use_figma writes yet) 0a. Analyze codebase → extract tokens, components, naming conventions 0b. Inspect Figma file → pages, variables, components, styles, existing conventions 0c. Search subscribed libraries → use search_design_system for reusable assets 0d. Lock v1 scope → agree on exact token set + component list before any creation 0e. Map code → Figma → resolve conflicts (code and Figma disagree = ask user) ✋ USER CHECKPOINT: present full plan, await explicit approval Phase 1: FOUNDATIONS (tokens first — always before components) 1a. Create variable collections and modes 1b. Create primitive variables (raw values, 1 mode) 1c. Create semantic variables (aliased to primitives, mode-aware) 1d. Set scopes on ALL variables 1e. Set code syntax on ALL variables 1f. Create effect styles (shadows) and text styles (typography) → Exit criteria: every token from the agreed plan exists, all scopes set, all code syntax set ✋ USER CHECKPOINT: show variable summary, await approval Phase 2: FILE STRUCTURE (before components) 2a. Create page skeleton: Cover → Getting Started → Foundations → --- → Components → --- → Utilities 2b. Create foundations documentation pages (color swatches, type specimens, spacing bars) → Exit criteria: all planned pages exist, foundations docs are navigable ✋ USER CHECKPOINT: show page list + screenshot, await approval Phase 3: COMPONENTS (one at a time — never batch) For EACH component (in dependency order: atoms before molecules): 3a. Create dedicated page 3b. Build base component with auto-layout + full variable bindings 3c. Create all variant combinations (combineAsVariants + grid layout) 3d. Add component properties (TEXT, BOOLEAN, INSTANCE_SWAP) 3e. Link properties to child nodes 3f. Add page documentation (title, description, usage notes)