igniteui-angular-generate-from-image-design

Files (3)

• SKILL.md
• component-mapping.md · references/
• gotchas.md · references/

SKILL.md (first lines)

# Implementing Ignite UI Angular Views from Design Images

## OpenClaw Safety Adapter

This skill has been adapted for Lucy/OpenClaw.

- Do **not** automatically install npm packages, configure MCP servers, edit IDE settings, or write external configuration without Camilo's explicit approval.
- First inspect the project (`package.json`, Angular version, installed Ignite UI package variant, existing theme/config).
- If an Ignite UI MCP server/tool is already available, use it to verify current APIs. If it is unavailable, use the bundled references and say when an answer should be checked against vendor docs.
- Project `docs/STANDARDS.md`, SDD phase gates, and higher-priority workspace rules remain authoritative.
- Never put secrets, license tokens, private registry credentials, or PATs in code, docs, logs, or chat.

## 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 Angular-only. Check package layout or licensing only when imports, packages, or theming depend on it.
4. To apply a theme, use the theming workflow from this skill and the dedicated `igniteui-angular-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. 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** - this skill is Angular-only; check package layout or licensing only when imports, packages, or theming depend on it
3. **Discover components** - If Ignite UI MCP tools are available, call `list_components` with targeted filters; otherwise use the bundled component-mapping references
4. **Look up component docs** - Call `get_doc` for every chosen component family before coding
5. **Generate/propose theme** - If Ignite UI theming MCP tools are available, use them for palette/elevation/typography/theme generation. If not, derive the theme manually from the bundled references. Prefer design tokens or scoped semantic CSS variables over raw literals; do not install/configure tooling without approval.
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 | `IgxListComponent` | yes - item height, icon size | domain-appropriate mock data |
| Example: top bar | brand + tabs + search | `IgxNavbarComponent` | yes - multi-zone flex layout | n/a |
| Example: side panel | always-visible navigation | `IgxNavigationDrawerComponent` | 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 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 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 Angular-only. Check package layout or licensing only when imports, packages, or theming depend on it.

If you need to confirm package layout or licensing state, act on the result immediately:

- If the project uses Open Source package layout, use `igniteui-angular` for all core imports.
- If the project is unlicensed or uses Open Source package layout, do not mark any core UI components as blocked or premium-only during implementation.
- If the result indicates a licensed package layout, follow the licensed import paths shown in the component reference when needed.

If MCP tools are available, call `list_components` with `framework: "angular"` and relevant filters to find components matching each UI pattern. Otherwise, use `references/component-mapping.md`. Common filters:

- `chart`, `sparkline` - for data visualization
- `list view`, `card`, `avatar`, `badge` - for data display
- `nav`, `navbar`, `drawer` - for navigation
- `progress`, `gauge` - for metrics
- `map` - for geographic displays
- `grid` - for tabular data

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](references/component-mapping.md).

## Step 4: Look Up Component API

For every chosen component category, call `get_doc` with the doc name from `list_components` results (e.g., `name: "card"`, `framework: "angular"`). Use the doc `name` field from the MCP results, not the result title shown in the list. This is preferred before coding when MCP tools are available; otherwise rely on the bundled references and note uncertainty.

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-angular-theming`](../igniteui-angular-theming/SKILL.md) 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 global stylesheet (typically `styles.scss`). Look for an active `@include theme(...)` or `@include palette(...)` call that already references a palette variable.

- **Existing theme found** -> the global palette is already set. Do **not** call `create_theme` or `create_palette` unless the user explicitly wants a global theme change. Instead:
  1. Inspect the existing theme definition and any exposed palette tokens or 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/default palette** -> proceed with **5b** to generate a fresh global theme.

### 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_theme` or `create_palette`** with the extracted seed values:

From CamiloAndresGTRUniandes/lucy-ai, MIT.

More from CamiloAndresGTRUniandes/lucy-ai