Figma Generate Library

What This Skill Does

• This skill builds professional-grade design systems in Figma that match code.
• It orchestrates multi-phase workflows, enforcing quality patterns from real-world design systems.
• This skill is for users who want to create a comprehensive design system in Figma.

When to Use

• Build a new design system from scratch.
• Create variable collections and modes.
• Create primitive variables.
• Create semantic variables.
• Build components from tokens.
• Enforce design system patterns.

Key Features

• Orchestrates multi-phase workflows.
• Enforces quality patterns.
• Requires the figma-use skill.
• Analyzes codebase for tokens and components.
• Inspects Figma file for existing conventions.
• Maps code to Figma.

Manual Installation

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) 3g. Validate: get_metadata (structure) + get_screenshot (visual) 3h. Optional: lightweight Code Connect mapping while context is fresh → Exit criteria: variant count correct, all bindings verified, screenshot looks right ✋ USER CHECKPOINT per component: show screenshot, await approval before next component

Phase 4: INTEGRATION + QA (final pass) 4a. Finalize all Code Connect mappings 4b. Accessibility audit (contrast, min touch targets, focus visibility) 4c. Naming audit (no duplicates, no unnamed nodes, consistent casing) 4d. Unresolved bindings audit (no hardcoded fills/strokes remaining) 4e. Final review screenshots of every page ✋ USER CHECKPOINT: complete sign-off

3. Critical Rules

Plugin API basics (from use_figma skill — enforced here too):

• Use return to send data back (auto-serialized).
• Do NOT wrap in IIFE or call closePlugin. Return ALL created/mutated node IDs in every return value Page context resets each call — always await figma.setCurrentPageAsync(page) at start figma.notify() throws — never use it Colors are 0–1 range, not 0–255 Font MUST be loaded before any text write: await figma.loadFontAsync({family, style})

Design system rules:

• Variables BEFORE components — components bind to variables.
• No token = no component.
• Inspect before creating — run read-only use_figma to discover existing conventions.
• Match them. One page per component (default) — exception: tightly related families (e.g., Input + helpers) may share a page with clear section separation.
• Bind visual properties to variables (default) — fills, strokes, padding, radius, gap.
• Exceptions: intentionally fixed geometry (icon pixel-grid sizes, static dividers).
• Scopes on every variable — NEVER leave as ALL_SCOPES.
• Background: FRAME_FILL, SHAPE_FILL.
• Text: TEXT_FILL.
• Border: STROKE_COLOR.
• Spacing: GAP.
• Radii: CORNER_RADIUS.
• Primitives: [] (hidden).
• Code syntax on every variable — WEB syntax MUST use the var() wrapper: var(--color-bg-primary), not --color-bg-primary.
• Use the actual CSS variable name from the codebase.
• ANDROID/iOS do NOT use a wrapper. Alias semantics to primitives — { type: 'VARIABLE_ALIAS', id: primitiveVar.id }. Never duplicate raw values in semantic layer.
• Position variants after combineAsVariants — they stack at (0,0).
• Manually grid-layout + resize.
• INSTANCE_SWAP for icons — never create a variant per icon.
• Cap variant matrices: if Size × Style × State > 30 combinations, split into sub-component.
• Deterministic naming — use consistent, unique node names for idempotent cleanup and resumability.
• Track created node IDs via return values and the state ledger. No destructive cleanup — cleanup scripts identify nodes by name convention or returned IDs, not by guessing. Validate before proceeding — never build on unvalidated work. get_metadata after every create, get_screenshot after each component.
• NEVER parallelize use_figma calls — Figma state mutations must be strictly sequential.
• Even if your tool supports parallel calls, never run two use_figma calls simultaneously.
• Never hallucinate Node IDs — always read IDs from the state ledger returned by previous calls.
• Never reconstruct or guess an ID from memory.
• Use the helper scripts — embed scripts from scripts/ into your use_figma calls.
• Don't write 200-line inline scripts from scratch. Explicit phase approval — at each checkpoint, name the next phase explicitly. "looks good" is not approval to proceed to Phase 3 if you asked about Phase 1.

4. State Management (Required for Long Workflows)

getPluginData() / setPluginData() are NOT supported in use_figma. Use getSharedPluginData() / setSharedPluginData() instead (these ARE supported), or use name-based lookups and the state ledger (returned IDs).