$npx -y skills add PaulRBerg/agent-skills --skill tailwind-cssUse for Tailwind v4 styling: add/fix classes, configure or migrate Tailwind, use tailwind-variants, or tw-animate-css.
| 1 | # Tailwind CSS |
| 2 | |
| 3 | Style within the installed Tailwind version, existing design tokens, component patterns, and product context. |
| 4 | |
| 5 | ## Authority and Defaults |
| 6 | |
| 7 | - Inspect package versions, CSS entrypoints, theme declarations, shared components, class-merging utilities, and nearby |
| 8 | UI before editing. Those are authoritative. |
| 9 | - Apply this catalog's preferences only where the project is silent. Read |
| 10 | [references/coding-preferences.md](references/coding-preferences.md) for that fallback style. |
| 11 | - Prefer existing semantic tokens and components over arbitrary values, new colors, or one-off utilities. |
| 12 | - Preserve responsive states, interaction states, accessibility, and dark-mode conventions. Do not add decorative UI or |
| 13 | redesign beyond the request. |
| 14 | - Use CSS Modules only when the behavior is materially clearer than utilities; preserve any project-specific Tailwind |
| 15 | reference mechanism. |
| 16 | |
| 17 | ## Routing |
| 18 | |
| 19 | - For v4 configuration, migration, removed utilities, variables, gradients, or CSS-first directives, read |
| 20 | `references/tailwind-v4-rules.md` after confirming v4 is installed. |
| 21 | - For component variants or slots with `tailwind-variants`, read `references/tailwind-variants.md`. |
| 22 | - For `tw-animate-css`, read `references/tw-animate-css.md`. |
| 23 | - For Tailwind ESLint integration, read `references/eslint.md`. |
| 24 | |
| 25 | Do not apply v4 syntax to an older project merely because this skill targets v4. If the installed version differs, use |
| 26 | its official documentation or ask whether migration is intended. |
| 27 | |
| 28 | ## Workflow |
| 29 | |
| 30 | 1. Define the visual outcome and affected states from the request and product context. |
| 31 | 2. Reuse local tokens, spacing, typography, breakpoints, components, and variant conventions. Make the smallest |
| 32 | class/config change that achieves the outcome. |
| 33 | 3. Run the repository's relevant lint/type/build checks. |
| 34 | 4. Render the affected screen or component at representative viewport sizes and inspect it visually, including changed |
| 35 | interaction and theme states. Fix visible regressions before completion. |
| 36 | |
| 37 | Completion requires code checks plus rendered inspection; textual class review alone is insufficient. |
| 38 | |
| 39 | Finish with `### 🎨 Tailwind — ✅ styling updated` after edits or `### 🎨 Tailwind — 🔎 inspected, no files written` for |
| 40 | read-only work, a compact viewport/theme/changed-states/result table, and separate `### 🧪 Code checks` and |
| 41 | `### 🔎 Rendered inspection` evidence. Add `### ⚠️ Remaining` only when non-empty. Do not inject decorative emoji into |
| 42 | source classes, product copy, or snapshots unless the request calls for it; keep commands and diagnostics exact. |