/igniteui-blazor-generate-from-image-design

name: igniteui-blazor-generate-from-image-design
description: Implement Blazor application views from design images using Ignite UI Blazor 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 Blazor view with Ignite UI Blazor 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 Blazor project.
user-invocable: true

Implementing Ignite UI Blazor 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). 3. This skill is Blazor-only. Check NuGet package (`IgniteUI.Blazor.Lite`, `IgniteUI.Blazor.GridLite` for general purpose components and light-weight grid, or `IgniteUI.Blazor` / `IgniteUI.Blazor.Trial` for specialized feature-rich grids and charts) only when theming or component availability depends on it. 4. To apply a theme, use the theming workflow from this skill and the dedicated `igniteui-blazor-theming` 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. **Read [references/gotchas.md](references/gotchas.md) now — after docs, before writing any code.** Read the file in full. Some entries are component-specific; others apply broadly to any chart, any themed component, or any scoped CSS. Apply every entry that is relevant to what you are building. This is a blocking step: do not start implementation until you have read the whole file and checked it against your component list. 7. Only then start coding.

---

Workflow

1. **Analyze the design image** - Read the image, identify every UI section, component, layout structure. 2. **Confirm NuGet package if needed** - this skill is Blazor-only; use `IgniteUI.Blazor.Lite`, `IgniteUI.Blazor.GridLite` for general purpose components and the light-weight grid, and `IgniteUI.Blazor` (trial version available publicly as `IgniteUI.Blazor.Trial`) for specialized feature-rich grids and charts. 3. **Discover components** - Call `list_components` with targeted filters and `framework: "blazor"` 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) Extract colors and call `create_palette` or `create_custom_palette` with `platform: "blazor"` and `output: "css"` — do **not** use `create_theme` for Blazor, it produces Sass requiring compilation. Optionally call `create_elevations` and `create_typography` for elevation and font overrides. (b) After a palette exists, prefer using design tokens or scoped semantic CSS variables over raw literals. (c) For every Ignite UI component, 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, map, gauge, table, form, 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, geographic)
• **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 | `IgbList` | yes - item height, icon size | domain-appropriate mock data | | Example: top bar | brand + tabs + search | `IgbNavbar` | yes - multi-zone flex layout | n/a | | Example: side panel | always-visible navigation | `IgbNavDrawer` | yes - width, item styling | n/a |

Start every region with the most appropriate Ignite UI Blazor 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 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
• major assumptions

After the table, translate the image into CSS Grid rows and columns first. Preserve desk