Igniteui Angular Figma To App

Ignite UI for Angular — Figma to App

Translate Figma app screens into production Angular applications built with Ignite UI for Angular. The skill accepts designs from three kinds of source. A single file often mixes them, so every component is classified individually (Phase 1f):

Tier A gives the highest fidelity for the least effort. Tiers B and C reach high fidelity through token overrides, and record the remaining anatomy deltas (structural differences between the design's components and Ignite UI's) for the user to approve instead of hiding them.

This skill orchestrates four MCP servers: Figma (design data), Ignite UI CLI (component docs), Ignite UI Theming (styles), and Playwright (visual validation).

Required Workflow

Complete all phases in order — do not skip phases or generate component code from memory. Every component selector, input name, and import path must come from get_doc results or, where no doc exists in the catalog, from the igniteui-angular-components / igniteui-angular-grids skill reference files — never guessed.

Read references/project-setup.md before Phase 0b. Read references/figma-exploration.md before Phase 1. Read references/design-provenance.md before Phase 1f. Read references/asset-extraction.md before Phase 1h. Read references/figma-component-map.md before Phase 2. Read references/theme-generation.md before Phase 3. Read references/design-token-bridge.md before Phase 3. Read references/validation-patterns.md before Phase 5.

Phase 0 — Prerequisites

Tool naming: this skill writes MCP tool names as <server>_<tool> (e.g. figma_get_metadata, theming_create_theme). The exact name depends on the client — Claude Code exposes them as mcp__<server>__<tool> (e.g. mcp__figma__get_metadata). Match by the tool's base name on whatever server is connected.

0a: Verify All Four MCP Servers

Run these checks silently in parallel. Each verification call is a no-op if the server is not connected; do not surface raw errors to the user at this point.

If any server fails, fix setup for that server only before continuing. For igniteui-cli and igniteui-theming, configure them yourself — run npx -y igniteui-cli ai-config (or ig ai-config) from the project root, which configures both. Add a missing Playwright entry yourself as well. The Figma servers need the user's action — the desktop server is enabled in the Figma desktop app, and the remote server signs in through Figma OAuth — so guide the user through the Figma setup. Full setup instructions for all servers are in references/mcp-setup.md. Newly configured MCP servers require an editor/session reload before their tools appear — ask the user to reload, then stop.

0b: Detect or Scaffold Angular Project

Check whether the working directory contains a package.json that lists igniteui-angular or @infragistics/igniteui-angular, and a src/app/ directory.

• Project found: note the package (open-source or licensed) and the Angular version, and confirm the MCP configuration has all four server entries.
• No project found: offer to scaffold one with npx -y igniteui-cli new, or to use an existing project directory, and wait for the user's choice.

Read references/project-setup.md for the detection checklist, the exact messages to show the user, template selection, and the scaffolding steps.

Phase 1 — Figma Design Exploration

Goal: understand the full design structure and capture all data needed for implementation and validation before writing any code.

Read references/figma-exploration.md in full before the first Figma MCP call. It has the call budget, exact tool arguments, extraction checklists, and table templates for each step:

Key constraints:

• Rate limits: limits depend on the Figma seat. A View/Collab seat allows about 6 calls a month, which may not cover one artboard. Compare the call estimate with the user's quota before starting, and discover structure with figma_get_metadata first.
• Two Figma MCP servers: the remote server (mcp.figma.com) takes fileKey and nodeId, so you can move between artboards yourself. The desktop server (127.0.0.1:3845) works only on the file open in the Figma desktop app. Pass the node ID from a frame link and check the response, or ask the user to select each artboard and do not batch those calls. Detect the server before the first call (see figma-exploration.md).
• Any UI kit: do not assume the Indigo.Design kits. Classify each component in 1f. A third-party kit's names, variables, and Code Connect mappings are evidence of the component's role. Never copy them into the code.
• React + Tailwind output: figma_get_design_context returns React + Tailwind code. Read it for information only — never copy it into Angular files, and never use its localhost image URLs as final assets.

Phase 2 — Component Discovery (Ignite UI CLI MCP)

Goal: look up exact Angular selectors, inputs, outputs, and usage patterns for every component identified in Phase 1. Never generate component code from memory.

2a: Read the Component Map

Read references/figma-component-map.md in full. For each row of the Phase 1g Table A:

• Tier A: find the Indigo.Design kit name in the kit tables.
• Tier B/C: find the canonical role in the Canonical Role Index, then the row it points to in the named section.

That row gives you:

• The Ignite UI Angular selector
• The get_doc key to call
• Key inputs and variants to configure

2b: Fetch Component Docs

Call list_components({ framework: "angular" }) once to discover which component families have full docs — the catalog covers only a subset of components. Then:

• For families with a doc: call get_doc({ framework: "angular", name: "<doc-name>" }), all in a single parallel batch — never sequentially.
• For families without a doc: read the matching reference files from the igniteui-angular-components and igniteui-angular-grids skills, and use search_api for member-level API lookups.

Do not write any component code until you have read its doc or reference file.

2c: Search for Feature Docs

Use search_docs for feature-level questions raised by the artboard, for example:

search_docs({ framework: "angular", query: "row editing" })
search_docs({ framework: "angular", query: "virtual scrolling" })
search_docs({ framework: "angular", query: "column pinning" })

Feature docs are mandatory when the artboard shows grid editing, filtering, sorting, pinning, or other advanced feature states.

2d: Document the Final Component Plan

After reading all docs, confirm or revise the decomposition table from Phase 1g with:

• Exact selectors (e.g. <igx-grid>, <igx-navbar>)
• Exact import paths (never imported from the root barrel)
• Required peer modules or provider functions

Anatomy delta ledger (Tier B and C). For every mapped component whose anatomy differs from the design in a way that tokens or content projection cannot close, add a ledger entry:

Do not ledger differences that tokens can close: color, radius, border, casing, height, and spacing are implementation work, not deltas. For every interactive control, prefer the Ignite UI component with a recorded delta over hand-built markup. The component's keyboard, focus, ARIA, and form behavior are worth more than a pixel-exact but inert copy. Approved entries are classified Accepted in Phase 5.

If new packages are required (including an icon package for a third-party kit), identify exact packages and versions and ask for approval before installing. Present this updated plan, with the ledger, to the user and wait for confirmation before Phase 3.

Phase 3 — Theme Generation (Ignite UI Theming MCP)

Goal: produce Sass theming code that matches the Figma design's visual language using the kit variables from Phase 1e (Path A) or the color census and measurements from Phase 1d (Path B).

Read references/theme-generation.md and references/design-token-bridge.md in full before running any theming tool. The steps are:

Key constraints:

• theming_create_palette takes primary/secondary/surface/gray/success/warn/error/info and variant, while theming_create_theme takes primaryColor/secondaryColor/surfaceColor (no gray).
• theming_create_elevations takes designSystem (material or indigo); there is no preset parameter.
• Never use the font name as the primary design-system signal.
• Never convert Figma pixel values into theming_set_spacing or theming_set_roundness multipliers. --ig-size is different: it is a size step (small / medium / large), not a multiplier. Path A keeps the default; Path B picks the nearest step to the measured control heights (3d).
• Path B: seed the palette with the color painted on the component, not the variable named …/500. On a material baseline, buttons, checkboxes, and switches use secondary, so seed it with the button color.

Phase 4 — Implementation

Goal: build the Angular view(s) that match the artboard decomposition from Phase 2.