telerik/ai-plugins/prompt-enrichment

Prompt Enrichment

Short or generic UI prompts produce bland, generic layouts with placeholder data. This skill expands any vague Kendo UI request into a detailed design brief before code is written.

Workflow Contract

After reading this skill, stop and execute the Decision Table before doing any research, tool execution or implementation work.

1. Choose the matching Decision Table row.
2. Read the reference file named by that row before producing a brief, scaffold, clarification question, or skip decision.
3. If the selected row is Clarification triage, ask the clarification question and wait for the user's answer before returning to this workflow.
4. Do not create a design brief from this file alone. The enrichment gate is incomplete until the selected reference workflow has been followed.
5. Only after this workflow is complete may the orchestrator continue with accessibility, component, layout, theming, icon, validation, or project-file work.

Decision Table

This is the single source of truth for picking a pattern. Each row lists the trigger signals, the deliverable, the pattern name, and the reference to load for full instructions. Reference files do not repeat trigger criteria — they are loaded only after the pattern has been picked here.

If a prompt does not clearly match any row, default to single-view enrichment — it's the safest starting point. If both row 1 and row 2 match (vague prompt + app scope), run app scaffolding first, then enrich the primary view.

Core Principles

1. Specificity produces better UIs. A concrete user role + realistic data + explicit spatial layout always outperforms a generic prompt — even when the scenario is fictional.
2. Enrich any UI type. This skill covers dashboards, e-commerce pages, chat interfaces, settings screens, onboarding wizards, social feeds, media galleries, landing pages — not only business dashboards.
3. Layout must be spatially explicit. Never just name a pattern ("List-Detail"). Describe panel widths, what's above/below the fold, column/row structure, fixed vs. scrollable regions.
4. Data must be realistic. Never use "[placeholder]" or "Data 1". Invent plausible names, amounts, dates, and cross-component relationships.
5. Don't duplicate implementation. Defer to Kendo Agentic UI Generator assistants (#kendo_component_assistant, #kendo_layout_assistant, etc.) for API usage, code, and theming. This skill produces the design brief they consume.

Brief Format

Every enrichment — whether single-view or per-view within an app — produces a brief in this shape:

## Design Brief: [Descriptive Title]
 
**User**: [Role + context, 1–2 sentences]
**Primary Task**: [What they do on this screen]
**Layout**: [Pattern name + spatial description with dimensions/ratios]
**Density**: [High/Medium/Low] | **Tone**: [Descriptor]
 
### Component Plan
1. [Name] — [Kendo component] — [What it shows, with sample values]
2. ...
 
### Key Interactions
- [What happens on click/filter/selection]
 
### Sample Data
[Field names, types, 3–5 realistic rows per component]

The brief stays internal unless the user asks to see it. Present the plan conversationally, get confirmation, then build.