Tailwind CSS
Style within the installed Tailwind version, existing design tokens, component patterns, and product context.
Authority and Defaults
- Inspect package versions, CSS entrypoints, theme declarations, shared components, class-merging utilities, and nearby
UI before editing. Those are authoritative.
- Apply this catalog's preferences only where the project is silent. Read
references/coding-preferences.md for that fallback style.
- Prefer existing semantic tokens and components over arbitrary values, new colors, or one-off utilities.
- Preserve responsive states, interaction states, accessibility, and dark-mode conventions. Do not add decorative UI or
redesign beyond the request.
- Use CSS Modules only when the behavior is materially clearer than utilities; preserve any project-specific Tailwind
reference mechanism.
Routing
- For v4 configuration, migration, removed utilities, variables, gradients, or CSS-first directives, read
references/tailwind-v4-rules.md after confirming v4 is installed.
- For version-specific behavior that may have changed, consult the current official documentation matching the installed
version. Treat the local v4 reference as a decision checklist, not an exhaustive substitute for the docs.
- For component variants or slots with
tailwind-variants, read references/tailwind-variants.md.
- For
tw-animate-css, read references/tw-animate-css.md.
- For Tailwind ESLint integration, read
references/eslint.md.
Do not apply v4 syntax to an older project merely because this skill targets v4. Use documentation matching the
installed version, and migrate only when the request includes migration.
Workflow
- Define the visual outcome and affected states from the request and product context.
- Reuse local tokens, spacing, typography, breakpoints, components, and variant conventions. Make the smallest
class/config change that achieves the outcome.
- Keep class names statically detectable. When values select styles, map them to complete class strings and verify that
Tailwind scans every relevant source location.
- Run the repository's relevant lint/type/build checks.
- Render the affected screen or component at representative viewport sizes and inspect it visually, including changed
interaction and theme states. When JavaScript or a component library transforms markup, inspect the final DOM and
verify that selectors and state behavior still match. Fix visible regressions before completion.
Completion requires code checks plus rendered inspection; textual class review alone is insufficient. When source
detection or generated class names changed, run the real Tailwind build and verify that the expected utilities are
present.
Finish with ### 🎨 Tailwind — ✅ styling updated after edits or ### 🎨 Tailwind — 🔎 inspected, no files written for
read-only work, a compact viewport/theme/changed-states/result table, and separate ### 🧪 Code checks and
### 🔎 Rendered inspection evidence. Add ### ⚠️ Remaining only when non-empty. Do not inject decorative emoji into
source classes, product copy, or snapshots unless the request calls for it; keep commands and diagnostics exact.
1---
2name: tailwind-css
3user-invocable: false
4description:
5 "Use for Tailwind v4 styling: add/fix classes, configure or migrate Tailwind, use tailwind-variants, or
6 tw-animate-css."
7---
8
9# Tailwind CSS
10
11Style within the installed Tailwind version, existing design tokens, component patterns, and product context.
12
13## Authority and Defaults
14
15- Inspect package versions, CSS entrypoints, theme declarations, shared components, class-merging utilities, and nearby
16 UI before editing. Those are authoritative.
17- Apply this catalog's preferences only where the project is silent. Read
18 [references/coding-preferences.md](references/coding-preferences.md) for that fallback style.
19- Prefer existing semantic tokens and components over arbitrary values, new colors, or one-off utilities.
20- Preserve responsive states, interaction states, accessibility, and dark-mode conventions. Do not add decorative UI or
21 redesign beyond the request.
22- Use CSS Modules only when the behavior is materially clearer than utilities; preserve any project-specific Tailwind
23 reference mechanism.
24
25## Routing
26
27- For v4 configuration, migration, removed utilities, variables, gradients, or CSS-first directives, read
28 `references/tailwind-v4-rules.md` after confirming v4 is installed.
29- For version-specific behavior that may have changed, consult the current official documentation matching the installed
30 version. Treat the local v4 reference as a decision checklist, not an exhaustive substitute for the docs.
31- For component variants or slots with `tailwind-variants`, read `references/tailwind-variants.md`.
32- For `tw-animate-css`, read `references/tw-animate-css.md`.
33- For Tailwind ESLint integration, read `references/eslint.md`.
34
35Do not apply v4 syntax to an older project merely because this skill targets v4. Use documentation matching the
36installed version, and migrate only when the request includes migration.
37
38## Workflow
39
401. Define the visual outcome and affected states from the request and product context.
412. Reuse local tokens, spacing, typography, breakpoints, components, and variant conventions. Make the smallest
42 class/config change that achieves the outcome.
433. Keep class names statically detectable. When values select styles, map them to complete class strings and verify that
44 Tailwind scans every relevant source location.
454. Run the repository's relevant lint/type/build checks.
465. Render the affected screen or component at representative viewport sizes and inspect it visually, including changed
47 interaction and theme states. When JavaScript or a component library transforms markup, inspect the final DOM and
48 verify that selectors and state behavior still match. Fix visible regressions before completion.
49
50Completion requires code checks plus rendered inspection; textual class review alone is insufficient. When source
51detection or generated class names changed, run the real Tailwind build and verify that the expected utilities are
52present.
53
54Finish with `### 🎨 Tailwind — ✅ styling updated` after edits or `### 🎨 Tailwind — 🔎 inspected, no files written` for
55read-only work, a compact viewport/theme/changed-states/result table, and separate `### 🧪 Code checks` and
56`### 🔎 Rendered inspection` evidence. Add `### ⚠️ Remaining` only when non-empty. Do not inject decorative emoji into
57source classes, product copy, or snapshots unless the request calls for it; keep commands and diagnostics exact.
paulrberg