ub-tailwind

Use this skill for Tailwind setup, migration, integration, and utility-first styling. Apply it when the task mentions Tailwind directives or utilities, @import "tailwindcss", @theme, plugin wiring, legacy-to-modern migration, token bridging with CSS variables, or framework-specific Tailwind build issues.

robert-hoffmann/uncle-bob14 installsMITSynced Aug 26

Works with

Claude CodeCursorCodex CLIGitHub CopilotGemini CLI
---
name: ub-tailwind
description: Use this skill for Tailwind setup, migration, integration, and utility-first styling. Apply it when the task mentions Tailwind directives or utilities, @import "tailwindcss", @theme, plugin wiring, legacy-to-modern migration, token bridging with CSS variables, or framework-specific Tailwind build issues.
license: MIT
---

# UB Tailwind

## Overview

Use this skill to keep Tailwind usage current and correct across different environments and avoid outdated patterns. This skill targets the latest stable Tailwind CSS: enforce CSS-first setup, apply official framework recipes, and replace legacy defaults in generated guidance.

Implement against the detected project and tooling truth, but bias setup and
migration guidance toward modern CSS-first Tailwind rather than retaining
legacy configuration habits or compatibility layers by default.

## Load References On Demand

- Read `../ub-authoring/references/authoring-conventions.md` when adjusting routing
  guidance or cross-skill authoring conventions.
- Read `references/tailwind-guardrails.md` for strict do/don't rules, deprecated syntax traps, and review checklists.
- Read `references/framework-recipes.md` for environment-specific setup paths (standalone HTML/CDN, Vue + Vite, Nuxt).
- Read `references/tailwind-legacy-to-modern-migration.md` for migration matrix, upgrade replacements, and compatibility caveats.

## When Not To Use

- Do not use this skill when the task is plain CSS architecture, selector
  strategy, or token-driven styling without Tailwind as the primary surface;
  co-load or defer to `ub-css` when Tailwind and CSS architecture overlap.
- Do not use this skill when the main issue is framework runtime behavior
  rather than Tailwind integration or utility-class authoring.

## Core Workflow

1. Identify the target environment before writing any Tailwind setup.
2. Run required detection checks: `nuxt.config.*`, `vite.config.*`, `package.json` dependencies, CSS entrypoints, and Nuxt app stylesheet placement (for modern Nuxt, expect `app/assets/css/main.css`).
3. Choose the matching recipe from `references/framework-recipes.md`.
4. Compare official guidance, repo truth, and observed code reality for
   non-trivial or version-sensitive recommendations.
5. Surface `OFFICIAL_CONFLICT` when authoritative sources, repo truth, or live
   code reality materially disagree on a non-trivial recommendation.
6. Surface `UNVERIFIED` when a non-trivial claim could not be confirmed in
   official sources after targeted research.
7. Apply modern Tailwind CSS-first rules from `references/tailwind-guardrails.md`.
8. Apply upgrade-safe replacements from `references/tailwind-legacy-to-modern-migration.md`.
9. Run the environment-specific validation checklist.
10. Reject and replace deprecated or legacy syntax.

## Environment Selection

- Use the **Standalone HTML/CDN** recipe for plain HTML pages without a build tool.
- Use the **Vue + Vite** recipe for Vue projects with Vite bundling.
- Use the **Nuxt** recipe for Nuxt apps where integration details differ from plain Vite.
- For Nuxt, default to the official setup path (`@tailwindcss/vite` wired in `nuxt.config.*`), not legacy module defaults.

If the environment is unclear, inspect project markers first (`package.json`, framework config, build plugins) and do not guess.

## Non-Negotiable Guardrails

### Tailwind Version and Syntax

- Use modern Tailwind CSS-first patterns and current docs semantics.
- Prefer CSS entrypoint `@import "tailwindcss"`.
- Prefer CSS directives like `@theme`, `@utility`, `@variant`, `@custom-variant`, `@source`, and `@reference` as needed.
- Treat `@config` and `@plugin` as legacy paths unless explicitly required for compatibility.
- Prefer compatibility only as a bounded layer with a documented migration back to CSS-first defaults.

### Build Strategy

- Do not assume PostCSS is required for modern Tailwind.
- Use Vite plugin integration where applicable (`@tailwindcss/vite`) for Vue + Vite workflows.
- For Nuxt, use the official Nuxt framework-guide flow and configure the Vite plugin under Nuxt config instead of creating Vue-only `vite.config.*` instructions.
- Keep setup minimal and environment-native.

### Vue/Nuxt Style Context

- For Vue/Nuxt component-scoped styles using `@apply` or `@variant`, include `@reference` to the main stylesheet or app stylesheet context.
- Avoid duplicating imported CSS just to expose theme values in component-local styles.

### Design Tokens

- Keep Tailwind tokens centralized in `@theme`.
- Reuse existing token primitives and avoid ad-hoc hardcoded drift.

### Do Not Generate

- Do not generate `@tailwind base;`, `@tailwind components;`, `@tailwind utilities;` as the default modern entrypoint.
- Do not assume PostCSS setup is mandatory for modern Tailwind.
- Do not default to `@nuxtjs/tailwindcss` as the first-line setup for fresh Nuxt guidance.

## Output Requirements

When generating or modifying code, always provide:

1. A short environment detection note.
2. A source truth note: detected project version, environment markers, and any
   material gap versus latest stable guidance.
3. The selected setup path (CDN, Vue + Vite, or Nuxt).
4. Exact deprecated-to-modern replacements applied (syntax/tooling/utility changes).
5. A quick validation checklist confirming modern Tailwind setup.
6. Compatibility notes when legacy directives (`@config`/`@plugin`) are retained.
7. Conflict note when relevant: `OFFICIAL_CONFLICT` or `UNVERIFIED` with a
   concise explanation and the implementation consequence.

## Version & Research Policy

- Target the latest stable release of Tailwind CSS.
- Detect the project's actual Tailwind version from `package.json` and lockfiles.
- Use web search to verify current best practices, directive availability, and migration guidance against official Tailwind CSS documentation.
- Treat repo truth as the gold implementation standard when deciding what can
  actually ship safely in the current project.
- Treat official Tailwind docs as the preferred guidance baseline for
  forward-looking design and migration-ready patterns.
- If official guidance and repo truth diverge materially on a non-trivial
  recommendation, surface `OFFICIAL_CONFLICT`, implement the repo-safe path,
  and explain the migration path.
- If official sources disagree with each other on a non-trivial
  recommendation, also surface `OFFICIAL_CONFLICT` instead of silently
  collapsing the disagreement.
- If a non-trivial claim cannot be confirmed in official sources after
  targeted research, mark it `UNVERIFIED` or avoid presenting it as settled
  guidance.
- Keep conflict and uncertainty disclosure scoped to non-trivial,
  version-sensitive, or contested guidance rather than trivial edits.
- When the project's installed version is behind latest stable, note the version gap and recommend an upgrade path.
- Inspect the host repository's `AGENTS.md` or equivalent instructions when
  present for project-specific version policy and tooling; do not assume it
  contains this catalog's defaults.
- Do not hardcode version numbers in generated guidance — keep recommendations evergreen.

## Freshness Review

- Volatility: high
- Review recommendation: review on touch and during periodic maintenance, targeting a quarterly rhythm when practical.
- Trigger signals: official migration changes, deprecated directives, major Tailwind releases, or repo toolchain changes that affect setup recipes.
- Enforcement: advisory only; stale Tailwind guidance is a review signal, not a blocking gate by itself.
- Stable core: environment detection, official recipe selection, and deprecated-syntax avoidance should remain useful even when exact setup details evolve.

## Completion Checklist

- Environment explicitly identified before setup.
- Tailwind entrypoint and directives align with modern guidance.
- No deprecated/legacy syntax remains without explicit compatibility reason.
- Framework-specific differences are handled (CDN vs Vite vs Nuxt).
- Nuxt guidance uses the official framework path and does not drift into Vue-only `vite.config.*` steps.
- Token usage is centralized and consistent.
- Generated instructions are concise, deterministic, and current-version oriented.
- Any material official-source conflict or unverified non-trivial guidance is
  disclosed explicitly when relevant.

More Accessibility skills

← All Accessibility skills

Check your AI visibility

One URL in, a 0–100 score and the exact fixes out.

RUN THE CHECK

Browse all the tools

15 tools across six categories
13 of them never send your data anywhere

Free · No signup · No trial clock

SEE THE DIRECTORY