| name | prompt-enrichment |
| description | Expand vague or minimal UI requests into rich, specific design briefs before generating {{family}} components. Trigger whenever a user asks to build ANY kind of user interface using {{family}}, and the request lacks specific layout, data, or component details — dashboards, apps, forms, portals, landing pages, e-commerce views, social feeds, chat interfaces, settings screens, onboarding flows, or any other UI. Skip when the user already provides a detailed spec. This skill decides WHAT to build; the {{family}} design/styling skill decides HOW to style it. |
Prompt Enrichment
Short or generic UI prompts produce bland, generic layouts with placeholder data. This skill expands any vague {{family}} 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.
- Choose the matching Decision Table row.
- Read the reference file named by that row before producing a brief, scaffold, clarification question, or skip decision.
- If the selected row is Clarification triage, ask the clarification question and wait for the user's answer before returning to this workflow.
- Do not create a design brief from this file alone. The enrichment gate is incomplete until the selected reference workflow has been followed.
- 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.
| Pick this pattern when... | The deliverable is... | Pattern | Reference |
|---|
| The prompt is vague or generic (under ~30 words, no layout/data/component specifics, generic terms like "dashboard", "page", "app"). The user wants a UI but hasn't said what's in it. | A detailed design brief: user role, information architecture, spatial layout with dimensions, {{family}} component plan, realistic sample data, density/tone, and interaction spec. | Single-view enrichment | references/enrichment-dimensions.md |
| The prompt targets a multi-view application (signals: "app", "system", "platform", "portal", multiple features, workflows spanning screens). Multiple screens need shared architecture. | An app scaffold (identity, roles, view map, navigation, data model, visual identity) + a design brief for the first view. | App scaffolding | references/app-scaffolding.md |
| The prompt contains possessive references ("our team", "my data") or named entities without context ("for Acme Corp"). Real context exists but wasn't stated. | 1–2 targeted clarifying questions with tappable options + escape hatch, followed by enrichment or scaffolding. | Clarification triage | references/clarification-triage.md |
| The user already provides a detailed spec — specific components, data fields, layout instructions, and content. Nothing is vague. | No enrichment needed. Build directly. | Skip | — |
| You need to select a spatial layout pattern for any view (during enrichment or scaffolding). | A specific layout pattern with spatial structure, {{family}} components, and "when NOT to use" guidance. | Layout selection | references/layout-patterns.md |
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
- Specificity produces better UIs. A concrete user role + realistic data + explicit spatial layout always outperforms a generic prompt — even when the scenario is fictional.
- 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.
- 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.
- Data must be realistic. Never use "[placeholder]" or "Data 1". Invent plausible names, amounts, dates, and cross-component relationships.
- Don't duplicate implementation. Defer to {{family}} Agentic UI Generator assistants (
#{{assistantPrefix}}_component_assistant, #{{assistantPrefix}}_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] — [{{family}} 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.
