southleft/skills-for-figma

analyze-component-set-figma

Analyze a Figma COMPONENTSET as a state machine for code generation — extract variant axes (state/size/etc.), map state variants to CSS pseudo-classes (hover→:hover, focus→:focus-visible, disabled→:disabled, error→[aria-invalid]), and compute per-variant vi…

Vedi sorgente
Documento Skill originale

Contenuto dal repository con titoli, esempi, codice, tabelle, link e immagini preservati.

analyze-component-set-figma — variant state machine → CSS

Take a Figma COMPONENT_SET (the purple dashed container holding all the variants of one component) and turn it into a code-generation blueprint: which property axes are state vs size, how each state maps to a CSS pseudo-class or ARIA attribute, and the minimal visual delta each state applies on top of the default variant. This is the bridge between "Figma has 12 button variants" and "emit one .btn rule + :hover/:disabled overrides."

Skill boundaries

  • `use_figma` rules — load the official `figma-use` skill first; it is the full Figma Plugin API reference. Essentials these scripts rely on: plain JS with top-level await + return (no IIFE, no figma.closePlugin(); console.log is not returned), inputs inlined as const at the top of each script, colors in 0–1 range, load fonts before any text op, await figma.getNodeByIdAsync(...), and atomic errors (a failed script applies nothing — read the error, fix, retry).
  • Full recursive tree (unlimited depth, reactions, instance refs) → use deep-component-figma.
  • Reorganizing variants into a labeled grid → use arrange-component-set-figma.
  • Adding/removing the properties themselves → use component-properties-figma.
  • This is a design-system code-gen capability that the native MCP's get_design_context /

get_metadata do not provide — they return raw structure, not a variant→CSS state machine.

Workflow

  1. Get the COMPONENT_SET id. From the user's selection (figma_get_selection), a search, or a

node id they paste. It must be the set, not an individual variant — the script validates type.

  1. Run `scripts/analyze-component-set.js` via use_figma

(skillNames: "analyze-component-set-figma"). Set const COMPONENT_SET_ID at the top first.

  1. Read the result. It returns variantAxes (each axis + its options), componentProps

(non-variant TEXT/BOOLEAN/INSTANCE_SWAP props → code props), a stateMachine with cssMapping (state name → CSS selector) and defaultSignature, and per-variant diffFromDefault.

  1. Generate code. Implement the default variant from defaultSignature, then add one rule per

cssMapping entry applying only that variant's diffFromDefault. Map componentProps to framework props: BOOLEAN→boolean, TEXT→string, INSTANCE_SWAP→ReactNode/slot, VARIANT→union.

  1. Validate. Cross-check that every state in stateMachine.states got a CSS rule, and that

token names in the diff (e.g. Color/Brand/Primary) resolve to your exported tokens.

How states map to CSS

The script normalizes the state axis value (case-insensitive) to a selector:

Variant valueCSS / ARIA selector
default(base rule, no selector)
hover:hover
focus / focused / focus-visible:focus-visible
active / pressed:active
disabled:disabled, [aria-disabled="true"]
error / invalid[aria-invalid="true"]
selected[aria-selected="true"]
checked:checked
loading[aria-busy="true"]
open / closed`[aria-expanded="true""false"]`
filled.has-value

Notes

  • Diffs are computed against the default variant, so a state's diffFromDefault lists only the

properties that change (fill token, stroke, text color, opacity, effects, child visibility). Emit exactly those as overrides — don't re-specify unchanged properties.

  • The script resolves boundVariables (fills/strokes) to token names when available, falling

back to raw hex. Prefer the token name in generated code.

  • Axis detection is heuristic: an axis named state/status/interaction is the state axis;

size/scale is the size axis. If your set names axes differently, the cssMapping may be empty — read variantAxes and map states yourself.

dallo stesso repository

Altri Skills

Tutti gli Skills
southleft
Community

annotations-figma

Read and write designer annotations on Figma nodes — node-level design specs that pin properties (fills, width, fontSize, etc.) and carry plain or markdown notes. Use when the user wants to document or inspect interaction specs, animation timings, easing, accessibility requirements, or implementation notes attached directly to a node. Triggers: 'add an annotation', 'annotate this node/component', 'read the annotations on…', 'what specs are pinned to this element', 'list annotation categories', 'document the focus behavior on this button in Figma'. Annotations are distinct from comments (they pin to design properties) and from the description field. Requires the Figma Desktop app (Plugin API).

installazioni
1
GitHub Stars
14
Aggiornato
1 giu
southleft
Community

audit-accessibility-figma

Deep accessibility scorecard for a single Figma component or component set — state coverage (default/hover/focus/disabled/error/active/loading), focus-indicator quality and contrast, non-color state differentiation, target size, annotation completeness, and color-blind simulation (protanopia/deuteranopia/tritanopia), all rolled into per-category 0–100 scores and prioritized recommendations. Use when the user wants to vet ONE component before shipping it: triggers 'audit this component', 'accessibility score for this button', 'is this component set accessible', 'check the states on this component', 'does my button have a focus state', 'color blind check', 'rate this component for a11y', 'component accessibility scorecard'. Works on ANY Figma plan. For a broad sweep over a whole page/frame use lint-design-figma; for CODE-side (HTML) checks use scan-code-accessibility-figma.

installazioni
1
GitHub Stars
14
Aggiornato
1 giu
southleft
Community

check-design-parity-figma

Compare a Figma node's actual specs against a code spec (the values your component renders) and get a 0–100 parity score, a list of discrepancies, and fix suggestions. Use to detect design-to-code DRIFT: triggers 'check design parity', 'does my code match the Figma', 'compare this component to the design', 'is my implementation faithful', 'find differences between design and code', 'verify the build matches Figma', 'design QA against code', 'parity score'. Reads the node's visual / typography / spacing / token / accessibility specs via usefigma (any plan) and diffs them against a codeSpec you provide. Complements the native getdesigncontext: instead of GENERATING code, it VALIDATES that existing code stayed in sync with the design.

installazioni
1
GitHub Stars
14
Aggiornato
1 giu
southleft
Community

component-properties-figma

Add, edit, and delete Figma component properties (TEXT, BOOLEAN, INSTANCESWAP, VARIANT) on a COMPONENT or COMPONENTSET, and instantiate a component then set its instance properties. Use when authoring or wiring up a component's API in Figma — triggers: 'add a component property', 'add a boolean prop to this component', 'make this text a component property', 'add an instance-swap slot', 'create a variant property', 'rename/delete a component property', 'place an instance of this component', 'instantiate this component and set its label/state', 'set properties on this instance'. Properties must be added to the parent COMPONENTSET, not individual variants. NOT covered by the native MCP's read-only getdesigncontext/getmetadata.

installazioni
1
GitHub Stars
14
Aggiornato
1 giu