---name: tailwind-cssuser-invocable: falsedescription: "Use for Tailwind v4 styling: add/fix classes, configure or migrate Tailwind, use tailwind-variants, or---

Tailwind CSS

Follow the installed Tailwind version and the repository's tokens, components, class-merging utility, CSS entrypoint, and nearby UI. They take precedence over this skill; do not add packages, change integration, or migrate versions without a request and local need.

Routing

• Apply coding preferences only where the project is silent.
• For v4 configuration, migration, directives, or generated classes, use v4 rules and the matching official docs.
• Read tailwind-variants, tw-animate-css, or ESLint only when that integration exists locally or the request adds it.

Do not apply v4 syntax to an older installation. Preserve responsive, interaction, accessible, and dark-mode behavior; do not redesign beyond the request.

Completion

Define the intended visual and state change, reuse local conventions, and keep classes statically discoverable. If source registration or generated mappings change, run the real Tailwind build and confirm the expected utilities. Run relevant repository checks, then inspect the changed UI at representative viewports, themes, and interaction states. When markup is transformed by JavaScript or a component library, inspect the final DOM too. Textual class review alone is insufficient.

Finish with ### 🎨 Tailwind — ✅ styling updated (or ### 🎨 Tailwind — 🔎 inspected, no files written), a compact viewport/theme/state/result table, and separate code-check and rendered-inspection evidence. Add ### ⚠️ Remaining only when needed; keep source UI copy and diagnostics undecorated.