name: ui version: 1.0.0 description: Build and refine user interfaces with Tailwind CSS. Use when the user asks to build, design, style, or refine web UI — landing pages, dashboards, marketing sections, forms, buttons, cards, pricing tables, hero sections, testimonials, or Tailwind markup cleanup. Generates multiple design variations on exploratory requests. categories: [design, frontend] author: solo-team license: MIT tags: [tailwind, ui, design, css]
ui
This skill helps you build user interfaces with Tailwind CSS — from full landing pages to individual components, from scratch or by refining existing designs.
When invoked without a prompt
If the user runs /ui with no additional input, introduce the skill by explaining the kinds of things it's good for. Don't present a menu or ask what they want to do — just help them understand what's possible so they can come back with a specific request.
Good for:
- Building new UI — landing pages, dashboards, marketing sections, app interfaces, individual components
- Exploring design directions — generating multiple variations to compare and choose from
- Refining existing work — improving layouts, cleaning up Tailwind markup, adding responsive behavior, implementing dark mode
- Organizing code — extracting components, reducing duplication, and cleaning up code structure
Mention a few example prompts they might try:
- "Show me a few different directions for this hero section"
- "Add a grid/list view toggle to this dashboard"
- "Give me some ideas for making this feature section more visually interesting"
- "Build a pricing page with three tiers"
- "Add dark mode support to this page"
- "Clean up the Tailwind classes in this component"
- "Componentize this page"
Keep it conversational and brief — this is orientation, not documentation.
When invoked with a prompt
Route the request by loading the appropriate supporting files before doing any implementation work.
Supporting files
Based on the user's prompt, load any of these files that feel relevant:
design-guidelines.md— index of design and coding rules with a directory of specific guideline files for components (buttons, forms, headers, pricing cards, testimonials, etc.), font recommendations, general markup/Tailwind authoring rules, and more. Load this for any UI work, then load the specific guideline files it points to.ui-picker.md— workflow for generating multiple design variations the user can compare and choose from. Default to using this for any open-ended or exploratory request — if the user is designing something new, asking for ideas, or the request has room for interpretation, generate multiple concepts and let them pick. Only skip it when the user is asking for a specific, unambiguous change.finalize.md— workflow for cleaning up, componentizing, and organizing UI code. Only activate when the user explicitly asks to organize, componentize, or extract components — not during regular UI building.
Routing examples
| Prompt | Files to load |
|---|---|
| "Build a landing page for a SaaS product" | design-guidelines.md, general, landing-pages, headers, heading-groups, buttons, feature-lists, pricing-cards, testimonials, footers, typography |
| "Show me 3 different hero layouts" | design-guidelines.md, general, heading-groups, buttons, images, section-layout, typography, ui-picker.md |
| "Add dark mode to this page" | design-guidelines.md, general, colors, dark-mode |
| "Clean up the Tailwind in this file" | design-guidelines.md, general |
| "Componentize this page" | finalize.md, design-guidelines.md, general |
| "Build a dashboard with a sidebar" | design-guidelines.md, general, dashboards, headers, surfaces, typography |
Core behavior
- This skill only activates when explicitly invoked with
/ui - If
/uiis used for something clearly unrelated to UI work, explain what the skill is for and ask the user to clarify - Load supporting files before writing code — never skip the design guidelines
- When requests are ambiguous, ask one focused clarifying question rather than guessing