Turn UX flows into a UI plan grounded in components, tokens, states, accessibility, responsive behavior, and a Stitch-ready prompt. Use when the user asks for UI design, component structure, design systems, shadcn, Tailwind, screen specs, visual inspiration, or a UI handoff before coding or polishing starts.
Convert UX logic into a concrete UI system the developer can build without guessing. Default to reusable components, token-driven styling, and explicit states instead of ad-hoc page mockups.
This skill should feel conversational. Lead the user through the missing decisions instead of expecting one perfect standalone prompt.
Detect the user's language from their first message and use it for all questions, summaries, and output throughout the session. If the language is unclear, ask once: "Which language do you want to work?" (or the equivalent in whatever language you detect). Do not switch languages mid-session.
Use an interactive loop:
Do not start by dumping a giant questionnaire. Do not behave like a static prompt template. The goal is to interview the user, tighten the direction, and turn that into a buildable UI plan.
Confirm:
If there is no existing system, propose a minimal one before styling details.
Before producing the final UI spec, ask the most relevant missing questions. Do not jump straight to visual recommendations if the screen intent, trust cues, or inspiration references are still vague.
If the user does not already have a strong visual reference, explicitly ask them to go to Dribbble dashboard search, choose one dashboard or product design they like, and upload it so the agent can extract the right hierarchy, spacing, and trust cues.
Unless the project already chose a different stack:
| Layer | Default | Why |
|---|---|---|
| Component library | shadcn/ui | Copy-in ownership, Radix primitives, full customization |
| Styling | Tailwind CSS v4 | Utility-first, @theme tokens, @custom-variant for dark mode |
| Variant management | class-variance-authority (cva) | Type-safe variant props, composable with cn() |
| Utility merge | clsx + tailwind-merge via cn() | Prevents class conflicts |
| Icons | lucide-react | Tree-shakeable, consistent, pairs with shadcn |
| Forms | react-hook-form + Zod | Validation at the boundary, minimal re-renders |
shadcn/ui is copy-in, not a package — components live in components/ui/ and are fully owned. Custom wrappers go in components/ (never modify components/ui/ directly).
Before structuring the UI, ask only the questions that will materially change the design. Prioritize:
If the screen is a pricing, checkout, onboarding, or conversion flow, explicitly ask whether a side panel, modal, inline expansion, or full page is preferred and why.
Do not finalize the visual direction until you either:
When you ask questions, prefer rounds like:
After each round, briefly reflect back what you learned before asking the next question set.
Define:
Prefer composition over custom one-off widgets. If a shadcn component exists, use it.
Use Tailwind v4 @theme for semantic tokens:
@theme {
--color-primary: oklch(0.65 0.24 265);
--color-surface: oklch(0.98 0.01 265);
--radius-default: 0.5rem;
--spacing-page: 1.5rem;
}
Token hierarchy: brand → semantic → component
Define:
@theme font sizes)Do not hardcode random values. Every visual choice traces to a token.
For each important component or screen:
| State | What the user sees | Data condition |
|---|---|---|
| Default | Normal view | Data loaded |
| Loading | Skeleton / spinner | Fetching |
| Empty | Illustration + CTA | No data exists |
| Error | Message + retry | Request failed |
| Success | Confirmation | Action completed |
| Disabled | Greyed + tooltip | Action unavailable |
UI quality is mostly state quality. Do not skip this.
Always cover:
aria-label for icon-only buttonsInclude:
@starting-style for enter, keyframes in @theme for motion)@custom-variant dark in Tailwind v4)If the output will be used in Stitch or another design generator, include:
The prompt should be strong enough that a student can paste it into Stitch without adding more design context.
Produce the UI spec in this shape:
# UI Spec: [Screen or Feature]
## Goal
## Clarifying answers captured
## Component tree (hierarchy)
## Token system (colors, typography, spacing, radius)
## shadcn/ui components used
## Custom components (with cva variants)
## States by component (table)
## Responsive behavior (breakpoints)
## Accessibility notes
## Visual inspiration notes
## Stitch-ready prompt
## Build notes for dev
components/ui/ files instead of wrappingWhen the user gives only a rough request, begin with something like:
I’ll lead this as a short UI interview instead of jumping straight to a design. First, tell me which flow we’re designing, what the main CTA is, and what absolutely must stay visible on the screen. After that, if the visual direction is still vague, I’ll ask you to pick and upload one favorite reference from Dribbble dashboard search so I can turn it into a stronger Stitch handoff.