figma-generate-library

安装量: 278
排名: #7330

安装

npx skills add https://github.com/figma/mcp-server-guide --skill 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)
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})
. Use
await figma.listAvailableFontsAsync()
to discover available fonts and verify exact style strings — if a load fails, query available fonts to find the correct name or a fallback.
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).
Entity type
Idempotency key
How to check existence
Scene nodes (pages, frames, components)
setSharedPluginData('dsb', 'key', value)
or unique name
node.getSharedPluginData('dsb', 'key')
or
page.findOne(n => n.name === 'Button')
Variables
Name within collection
(await figma.variables.getLocalVariablesAsync()).find(v => v.name === name && v.variableCollectionId === collId)
Styles
Name
getLocalTextStyles().find(s => s.name === name)
Tag every created
scene node
immediately after creation:
node
.
setSharedPluginData
(
'dsb'
,
'run_id'
,
RUN_ID
)
;
// identifies this build run
node
.
setSharedPluginData
(
'dsb'
,
'phase'
,
'phase3'
)
;
// which phase created it
node
.
setSharedPluginData
(
'dsb'
,
'key'
,
'component/button'
)
;
// unique logical key
State persistence
Do NOT rely solely on conversation context for the state ledger. Write it to disk:
/tmp/dsb-state-{RUN_ID}.json
Re-read this file at the start of every turn. In long workflows, conversation context will be truncated — the file is the source of truth.
Maintain a state ledger tracking:
{
"runId"
:
"ds-build-2024-001"
,
"phase"
:
"phase3"
,
"step"
:
"component-button"
,
"entities"
:
{
"collections"
:
{
"primitives"
:
"id:..."
,
"color"
:
"id:..."
}
,
"variables"
:
{
"color/bg/primary"
:
"id:..."
,
"spacing/sm"
:
"id:..."
}
,
"pages"
:
{
"Cover"
:
"id:..."
,
"Button"
:
"id:..."
}
,
"components"
:
{
"Button"
:
"id:..."
}
}
,
"pendingValidations"
:
[
"Button:screenshot"
]
,
"completedSteps"
:
[
"phase0"
,
"phase1"
,
"phase2"
,
"component-avatar"
]
}
Idempotency check
before every create: query by name + state ledger ID. If exists, skip or update — never duplicate.
Resume protocol
at session start or after context truncation, run a read-only
use_figma
to scan all pages, components, variables, and styles by name to reconstruct the
{key → id}
map. Then re-read the state file from disk if available.
Continuation prompt
(give this to the user when resuming in a new chat):
"I'm continuing a design system build. Run ID: {RUN_ID}. Load the figma-generate-library skill and resume from the last completed step."
5. search_design_system — Reuse Decision Matrix
Search FIRST in Phase 0, then again immediately before each component creation.
search_design_system({ query, fileKey, includeComponents: true, includeVariables: true, includeStyles: true })
Reuse if
all of these are true:
Component property API matches your needs (same variant axes, compatible types)
Token binding model is compatible (uses same or aliasable variables)
Naming conventions match the target file
Component is editable (not locked in a remote library you don't own)
Rebuild if
any of these:
API incompatibility (different property names, wrong variant model)
Token model incompatible (hardcoded values, different variable schema)
Ownership issue (can't modify the library)
Wrap if
visual match but API incompatible:
Import the library component as a nested instance inside a new wrapper component
Expose a clean API on the wrapper
Three-way priority
local existing → subscribed library import → create new.
6. User Checkpoints
Mandatory. Design decisions require human judgment.
After
Required artifacts
Ask
Discovery + scope lock
Token list, component list, gap analysis
"Here's my plan. Approve before I create anything?"
Foundations
Variable summary (N collections, M vars, K modes), style list
"All tokens created. Review before file structure?"
File structure
Page list + screenshot
"Pages set up. Review before components?"
Each component
get_screenshot of component page
"Here's [Component] with N variants. Correct?"
Each conflict (code ≠ Figma)
Show both versions
"Code says X, Figma has Y. Which wins?"
Final QA
Per-page screenshots + audit report
"Complete. Sign off?"
If user rejects
fix before moving on. Never build on rejected work. 7. Naming Conventions Match existing file conventions. If starting fresh: Variables (slash-separated): color/bg/primary color/text/secondary color/border/default spacing/xs spacing/sm spacing/md spacing/lg spacing/xl spacing/2xl radius/none radius/sm radius/md radius/lg radius/full typography/body/font-size typography/heading/line-height Primitives : blue/50 → blue/900 , gray/50 → gray/900 Component names : Button , Input , Card , Avatar , Badge , Checkbox , Toggle Variant names : Property=Value, Property=Value — e.g., Size=Medium, Style=Primary, State=Default Page separators :

(most common) or
——— COMPONENTS ———
Full naming reference:
naming-conventions.md
8. Token Architecture
Complexity
Pattern
< 50 tokens
Single collection, 2 modes (Light/Dark)
50–200 tokens
Standard
Primitives (1 mode) + Color semantic (Light/Dark) + Spacing (1 mode) + Typography (1 mode)
200+ tokens
Advanced
Multiple semantic collections, 4–8 modes (Light/Dark × Contrast × Brand). See M3 pattern in token-creation.md Standard pattern (recommended starting point): Collection: "Primitives" modes: ["Value"] blue/500 = #3B82F6, gray/900 = #111827, ... Collection: "Color" modes: ["Light", "Dark"] color/bg/primary → Light: alias Primitives/white, Dark: alias Primitives/gray-900 color/text/primary → Light: alias Primitives/gray-900, Dark: alias Primitives/white Collection: "Spacing" modes: ["Value"] spacing/xs = 4, spacing/sm = 8, spacing/md = 16, ... 9. Per-Phase Anti-Patterns Phase 0 anti-patterns: ❌ Starting to create anything before scope is locked with user ❌ Ignoring existing file conventions and imposing new ones ❌ Skipping search_design_system before planning component creation Phase 1 anti-patterns: ❌ Using ALL_SCOPES on any variable ❌ Duplicating raw values in semantic layer instead of aliasing ❌ Not setting code syntax (breaks Dev Mode and round-tripping) ❌ Creating component tokens before agreeing on token taxonomy Phase 2 anti-patterns: ❌ Skipping the cover page or foundations docs ❌ Putting multiple unrelated components on one page Phase 3 anti-patterns: ❌ Creating components before foundations exist ❌ Hardcoding any fill/stroke/spacing/radius value in a component ❌ Creating a variant per icon (use INSTANCE_SWAP instead) ❌ Not positioning variants after combineAsVariants (they all stack at 0,0) ❌ Building variant matrix > 30 without splitting (variant explosion) ❌ Importing remote components then immediately detaching them General anti-patterns: ❌ Retrying a failed script without understanding the error first ❌ Using name-prefix matching for cleanup (deletes user-owned nodes) ❌ Building on unvalidated work from the previous step ❌ Skipping user checkpoints to "save time" ❌ Parallelizing use_figma calls (always sequential) ❌ Guessing/hallucinating node IDs from memory (always read from state ledger) ❌ Writing massive inline scripts instead of using the provided helper scripts ❌ Starting Phase 3 because the user said "build the button" without completing Phases 0-2 10. Reference Docs Load on demand — each reference is authoritative for its phase: Use your file reading tool to read these docs when needed. Do not assume their contents from the filename. Doc Phase Required / Optional Load when discovery-phase.md 0 Required Starting any build — codebase analysis + Figma inspection token-creation.md 1 Required Creating variables, collections, modes, styles documentation-creation.md 2 Required Creating cover page, foundations docs, swatches component-creation.md 3 Required Creating any component or variant code-connect-setup.md 3–4 Required Setting up Code Connect or variable code syntax naming-conventions.md Any Optional Naming anything — variables, pages, variants, styles error-recovery.md Any Required on error Script fails, multi-step workflow recovery, cleanup of abandoned workflow state 11. Scripts Reusable Plugin API helper functions. Embed in use_figma calls: Script Purpose inspectFileStructure.js Discover all pages, components, variables, styles; returns full inventory createVariableCollection.js Create a named collection with modes; returns {collectionId, modeIds} createSemanticTokens.js Create aliased semantic variables from a token map createComponentWithVariants.js Build a component set from a variant matrix; handles grid layout bindVariablesToComponent.js Bind design tokens to all component visual properties createDocumentationPage.js Create a page with title + description + section structure validateCreation.js Verify created nodes match expected counts, names, structure cleanupOrphans.js Remove orphaned nodes by name convention or state ledger IDs rehydrateState.js Scan file for all pages, components, variables by name; returns full {key → nodeId} map for state reconstruction
返回排行榜