Figma Component Generation Skill
This skill reads component definitions from a Figma file via MCP and generates production-ready QML control files that consume the design-system singletons produced by the token-extraction skill.
Prerequisites
Before generating any components, confirm all of the following exist in the project:
design-tokens.json— the merged token file from the token-extraction skill- QML design system singletons —
Primitives.qml,Theme.qml,Spacing.qml,FontInterface.qmlin adesign-system/folder
If either is missing, stop and run the token-extraction skill first (qt-figma-token-extraction).
Verify Figma MCP is connected — confirm that get_metadata and get_design_context are available in the tool list. If not, tell the user:
"The Figma MCP connector isn't connected yet. Connect it via your MCP configuration, then come back and we can start."
Do not proceed until the connection is confirmed.
Step 1 — Component Discovery
Use get_metadata to fetch the file structure and identify which pages and frames contain components:
From the response, note all pages and frames or component sets named as component groups (e.g. "Button", "Text Field", "Checkbox").
Ask the user:
"I can see the following component groups in the Figma file: [list]. Which ones should I generate QML files for? Or should I do all of them?"
Build a single component inventory table and keep it updated throughout the entire workflow — do not create a second table later:
Status values: pending → extracting → mapping → done / blocked
Step 2 — Pattern Selection
Ask the user to choose an implementation pattern before reading any assets or writing any code. If the AskUserQuestion tool is available, use it:
If the tool is not available (e.g. in Claude Code, Codex, or Copilot), ask the question in plain text and wait for a reply before proceeding.
If the user selects "I'm not sure", recommend Pattern A for most projects — it is simpler, self-contained, and easier to debug. Only recommend Pattern B if the project already has a Qt.Themes / TokenInterface layer or needs to support multiple swappable themes.
Pattern B uses integer enum variants, not strings. Pattern A uses
property string variant: "primary". Pattern B usesproperty int typeVariant: ButtonStyle.TypeVariant.Primary. Do not mix the two approaches — pick one and use it consistently throughout all components.
Step 3 — Prepare the Chosen Pattern
Before extracting or writing anything, make sure the structure for the chosen pattern is in front of you. Pattern B is read from the bundled assets; Pattern A is built from the inline snippets in Step 5.
Pattern A assets — references/
This folder contains Figma-verified Pattern A controls. Each is a self-contained file where all state logic lives inside the component using conditional expressions on readonly property values.
Read the file that most closely matches the component being generated before writing any code. If a QML coding skill (qt-development-skills:qt-qml) is available, use it while writing so the output follows idiomatic Qt 6 patterns.
Pattern B assets — assets/qt-controls/
This folder contains QML pairs from a production Qt controls library. Each component is split across two files:
Button.qml— component logic, layout, base type, public APIButtonStyle.qml—pragma Singletondefining typedcomponentobjects for each state and size variant
Read the asset pair for the component you are about to generate — before writing any code. The generated file must follow the reference asset's structure, property ordering, and pattern choices. If the output deviates from the reference in a way that cannot be justified by the specific Figma component, ask yourself why and correct it. Do not invent a different structure when a reference exists.
Core pairs to read first (read the pair that matches the component being generated):
Button.qml+ButtonStyle.qmlCheckBox.qml+CheckBoxStyle.qmlComboBox.qml+ComboBoxStyle.qmlSwitch.qml+SwitchStyle.qmlTextField.qml+TextFieldStyle.qml
Step 4 — Per-Component Extraction
For each component in the inventory, extract its specification via MCP.
Always call
get_design_contexton an individual main component node — NOT the parent component set node. Component sets return oversized JSON mixing all variants. Inspect the default/base variant first, then representative variants (Hover, Pressed, Disabled) individually.
If individual node IDs are not known yet, call get_design_context on the parent frame and scan for child component nodes, then re-call on each.
What to extract per component
- Variants / props — Figma variant properties and allowed values → QML
propertydeclarations - States — Default, Hover, Pressed, Disabled, Focus, Error → conditional expressions on
readonly propertyvalues - Sizing — height, padding (H + V), gap, font size, font weight, corner radius
- Color tokens — which semantic token appears in each state; record exact Figma name and resolved value from
design-tokens.json - Typography — font family, size, weight, line height per text element
- Border — stroke width, color token, which states it appears in
- Icon / slot — whether the component has an icon slot, its size, left/right/both position
Record all extracted data in a scratch note before writing any code.
Step 5 — Figma → QML Mapping
Before writing any token reference, open
Theme.qml,Primitives.qml,Spacing.qml, andFontInterface.qmland read the actual property names. Do not copy token names from the reference assets — the project's token naming convention may differ from the examples. Every token name you write in a component must exist in the project's singletons.
Base type selection
Variant → property pattern (Pattern A)
Variant → enum pattern (Pattern B)
State → conditional expression pattern
Icon slot pattern
Sizing — tokens first, literals as fallback
Check Spacing.qml and FontInterface.qml first. Only use a literal value when no token covers the dimension, and add a // TODO: add to Spacing.qml comment.
Focus ring pattern
Focus rings apply only to Control-based components (AbstractButton, CheckBox, Switch, Slider, etc.). Text Field (ColumnLayout root) and Select (Item root) are not Control subclasses — use activeFocus and a fixed radius for those.
Color animation pattern
Add Behavior blocks only on color properties that animate during interaction (hover, press). Skip them for the disabled state — a snap, not a fade, is usually correct there.
Cursor pattern
Step 6 — Write the QML File
Place each component in the project's components/ folder. Use PascalCase matching the Figma component name (Button.qml, TextField.qml, etc.).
File header
Public API section
Missing values
After generating all components, summarise the full TODO list for the user.
Step 7 — Post-Generation Review
After all components are written, run a consistency pass:
- Every
readonly property colorreferencing a theme token must use a name that actually exists inTheme.qmlorPrimitives.qml. Flag any that don't. - Every numeric size must come from
Spacing.qmlorFontInterface.qml. Collect any literals that should be promoted to tokens. - Every interactive component has a focus ring.
- Every interactive component has a
HoverHandlerwith a cursor shape. - File headers document the node IDs that were inspected.
- Update the inventory table from Step 1 — mark all components
doneorblocked.
Present a brief summary to the user:
- Components generated (count and names)
- Components skipped or blocked (with reason)
- Full TODO list: tokens that need to be added to the design-system singletons
- Recommended next step: add components to
qt_add_qml_module QML_FILESin CMakeLists.txt and smoke-test in a gallery
Common Pitfalls
Inspecting the component set instead of a main component. Component sets return all variants stacked. Always drill down to an individual component node.
Using token names from reference assets instead of the project. The reference assets use example token names that may not match the project's singletons. Always read the actual singleton files first.
Hardcoding a value that exists in a token. Check Spacing.qml and FontInterface.qml before writing any literal number.
Missing the indeterminate / partial state. Checkbox and radio buttons often have a third state. Always check for Qt.PartiallyChecked.
Not zeroing out AbstractButton default padding. AbstractButton and other Control subclasses have default padding that inflates rendered height. Zero them explicitly when managing geometry yourself.
Forgetting Behavior blocks. Add Behavior on color { ColorAnimation { duration: Theme.duration_fast } } on color properties that animate during interaction (hover, press). Use a token for duration — not a hardcoded 100. Skip Behaviors on the disabled state; a snap transition is usually correct there.
Popup z-ordering. Popup items need parent: Overlay.overlay if clipped by a parent container.
Mixing Pattern A strings and Pattern B enums. Choose one variant approach and use it consistently across all components.

