Igniteui Wc Generate From Image Design

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 and 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:

Start every region with the most appropriate Ignite UI component from 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 implementation.
• If the result indicates a licensed package layout, follow the licensed import paths shown in the component reference when needed.

Then call list_components with framework: "webcomponents" and relevant filters to find components matching each UI pattern. Common filters:

• chart, sparkline - for data visualization
• list view, card, avatar, badge - for data display
• nav, navbar, drawer, dock manager - for navigation and shell layouts
• progress - for metrics
• grid lite, data grid, tree grid - for tabular data
• calendar, date picker, combo, select, input - for forms and scheduling

Use narrow search terms to reduce noisy MCP results. Search for the specific UI pattern you need, such as list view instead of list.

For component-to-Ignite-UI mapping, see references/component-mapping.md.

Step 4: Look Up Component API

For every chosen component category, use both tools before coding:

• Usage patterns, HTML examples, slots, registration → get_doc({ framework: "webcomponents", name: "<doc-name>" }) — use the name field from list_components, not the display title
• Full property/method/event API → get_api_reference({ platform: "webcomponents", component: "<ClassName>" }) — use search_api first to find the exact class name if needed

Call search_docs for feature-based questions (e.g., "how to configure [component] for [specific behavior or styling need]").

Step 5: Generate Theme with MCP

Use this skill for the image-to-view theming workflow only. The dedicated igniteui-wc-customize-component-theme skill remains the source of truth for palette-token behavior, global theme rules, and broader theming-system guidance.

5a - Existing app guard (always run first)

Before generating any theme code, inspect the project's entry point and main stylesheet(s) (commonly main.ts, main.js, index.ts, app.ts, styles.css, or the app's main theme stylesheet). Look for:

• an imported pre-built theme CSS file such as igniteui-webcomponents/themes/light/material.css

• existing palette tokens or semantic CSS variables already exposed by the app

• existing app-level typography or elevation variables already exposed by the app

• Existing theme found -> the global theme is already set. Do not call create_palette unless the user explicitly wants a global theme change. Instead:

  1. Inspect the existing theme import, palette definition, and any exposed semantic CSS variables.
  2. Reuse the current design system, variant, and palette tokens wherever they already match the design image.
  3. Skip to 5c and apply only minimal scoped overrides for the new view's components.

• No theme found / blank theme setup -> proceed with 5b to generate a fresh CSS-based theme baseline.

5b - Global theme generation (new projects only)

Follow this order - MCP guidance first, image extraction second:

1. Read MCP guidance first - call theming://guidance/colors/rules (or get_theming_guidance) before looking at the image. This tells you the available theme inputs and any luminance or variant constraints.
2. Resolve the design system - infer it from the existing workspace, explicit user request, or the closest visual match in the design. Do not assume one if a stronger signal exists.
3. Extract from the image - now that you know the available slots, extract values only for the inputs you actually need.
4. Call create_palette or create_custom_palette with the extracted seed values:

create_palette({
  primary: "<color extracted from image for primary slot>",
  secondary: "<color extracted from image for secondary slot>",
  surface: "<color extracted from image for surface/background slot>",
  variant: "<resolved theme variant>",
  platform: "webcomponents"
})

Import the closest built-in theme CSS for the resolved design system and variant, then use get_color to translate the generated palette into CSS custom properties, semantic app tokens, and component token values. Apply typography decisions with standard CSS font-family, font-size, and font-weight rules, and apply elevations with CSS box-shadow values or semantic shadow variables.

Read and act on any luminance warnings returned. If the design needs multiple surface depths that a single generated surface color does not cover, use create_custom_palette or define semantic CSS variables for the additional depths in the main stylesheet.

Use create_palette for straightforward designs with a small, coherent color system. Use create_custom_palette when the design has multiple distinct surface depths, several accent families, or when the generated palette cannot reliably match the screenshot.