/igniteui-wc-generate-from-image-design

name: igniteui-wc-generate-from-image-design
description: Implement application views from design images using Ignite UI Web Components. Uses MCP servers (igniteui-cli, igniteui-theming) to discover components, generate themes, and follow best practices. Triggers when the user provides a design image (screenshot, mockup, wireframe) and wants it built as a working view with Ignite UI Web Components. Also triggers when the user asks to "implement this design", "build this UI", "convert this mockup", or "create a page from this image" in an Ignite UI Web Components project.
user-invocable: true

Implementing Ignite UI Web Components Views from Design Images

MANDATORY AGENT PROTOCOL

Before writing any implementation code, you must complete these steps in order:

1. Analyze the image and identify all visible regions and UI patterns. 2. Read [references/component-mapping.md](references/component-mapping.md) and [references/gotchas.md](references/gotchas.md). 3. This skill is Web Components-first. Check package layout or licensing only when package choice, component registration, or theming depend on it. 4. To apply a theme, use the theming workflow from this skill and the dedicated `igniteui-wc-customize-component-theme` skill; use the `igniteui-theming` MCP tools instead of styling from memory. 5. Call `get_doc` for every chosen component family before using it. 6. Only then start coding.

Workflow

1. **Analyze the design image** - Read the image, identify every UI section, component, layout structure. 2. **Confirm package layout if needed** - Web Components packages are split by component family; check package layout or licensing only when package choice, component registration, or theming depend on it. 3. **Discover components** - Call `list_components` with targeted filters to find matching components for each UI pattern. 4. **Look up component docs** - Call `get_doc` for every chosen component family before coding. 5. **Generate theme** - (a) To generate a theme, first extract colors and create a color palette using `create_palette` or `create_custom_palette` depending on the scenario. Then extract elevations and call `create_elevations`. Then extract typography and call `create_typography`. Then call `create_theme` when Sass is configured, or import the closest pre-built theme CSS. (b) After a theme exists, prefer using design tokens or scoped semantic CSS variables over raw literals. (c) For every Ignite UI component family that exposes design tokens, call `get_component_design_tokens`, map extracted image tokens to token roles, then call `create_component_theme` with the tokens differing from the global theme for the specific component. 6. **Implement** - Build the screenshot-first layout, data, and view components. 7. **Refine** - Use the `set_size`, `set_spacing`, `set_roundness` tools to refine the view's visual fidelity against the image, then iterate on implementation and theming until the view matches the design closely. 8. **Validate** - Build, test, run, compare against the image, and fix differences.

Step 1: Analyze the Design Image

Read the input image carefully. For each visual section, identify:

• **Layout structure**: grid rows/columns, sidebar, navbar, content area proportions, and estimated fixed widths or percentages for major regions.

> Note: Do not guess the exact CSS properties at this stage; just identify the high-level structure and relative proportions. Do not try to fit the view into exact breakpoints or pixel values. Try to generate a flexible layout that preserves the observed proportions and can adapt to different screen sizes. You will refine the exact CSS rules in Step 8 after building a first version of the view.

• **Component type**: chart, list, card, grid, form, navigation, etc.
• **Color palette**: primary, secondary, surface/background, accent, text colors.
• **Typography**: font sizes, weights, letter-spacing patterns.
• **Surface styling**: borders, border-radius, shadows, elevation, divider treatments.
• **Data patterns**: what mock data is needed (time series, lists, KPIs, tabular, scheduling).
• **Spacing system**: translate observed padding and gaps into a small reusable scale derived from the design.

Before writing code, create a decomposition table with one row per visible region containing:

| Region | Visual role | Candidate component | Custom CSS required | Data type | |---|---|---|---|---| | Example: sidebar item list | repeated rows with icon + label | `IgcListComponent` + `IgcListItemComponent` | yes - item height, icon size | domain-appropriate mock data | | Example: top bar | brand + tabs + search | `IgcNavbarComponent` | yes - multi-zone slot layout | n/a | | Example: side panel | always-visible navigation | `IgcNavDrawerComponent` | yes - width, item styling | n/a |

Start every region with the most appropriate Ignite UI component from [references/component-mapping.md](references/component-mapping.md). Only fall back to plain semantic HTML when the component DOM structure is fundamentally incompatible with the design after CSS overrides, tokens, slots, and documented `::part(...)` selectors are considered. Document the reason for any plain-HTML fallback in a code comment.

Before writing code, produce a compact implementation brief that captures:

• chosen components per region
• fallback HTML regions
• theme strategy
• package needs
• component registration needs
• major assumptions

After the table, translate the image into CSS Grid rows and columns first. Preserve desktop proportions before adding responsive behavior, then define explicit breakpoint stacking rules for smaller screens.

Step 2-3: Use MCP Tools for Discovery

This skill is Web Components-first. Check package layout or licensing only when package choice, component registration, or theming depend on it.

• If the project is unlicensed or uses trial package layout, do not mark documented trial packages as blocked or licensed-only during impl