tailwind-css
paulrberg/agent-skills
Apply and maintain Tailwind v4 styling with class management, configuration, and migration support.
What is tailwind-css?
Tailwind CSS skill handles styling tasks for Tailwind v4 projects: adding or fixing utility classes, configuring Tailwind, migrating versions, and integrating extensions like tailwind-variants and tw-animate-css. Use it when you need to style components, update class names, or manage Tailwind configuration while respecting the project's existing tokens and conventions.
- Add, fix, or refactor Tailwind utility classes in markup
- Configure Tailwind v4 settings, directives, and generated utilities
- Migrate Tailwind versions and update syntax accordingly
- Integrate tailwind-variants for component-scoped styling
- Support tw-animate-css and ESLint integrations when present
- Preserve responsive, dark-mode, interaction, and accessibility behaviors
How to install tailwind-css
npx skills add https://github.com/paulrberg/agent-skills --skill tailwind-css- Tailwind CSS v4 installed in the project (or earlier version if not migrating)
- A tailwind.config.js or tailwind.config.ts file present
- CSS entrypoint configured (typically main.css or globals.css)
How to use tailwind-css
- 1.Review the project's existing Tailwind configuration, tokens, and component conventions
- 2.Identify the visual or state change needed and define the intended result
- 3.Apply Tailwind utility classes following the project's class-merging utility and naming patterns
- 4.If modifying configuration, consult the v4 rules and official Tailwind docs
- 5.Run the Tailwind build to confirm generated utilities are correct
- 6.Inspect the rendered UI at representative viewports, themes, and interaction states to verify the change
- 7.Finish with a summary table showing viewport/theme/state results and evidence of inspection
Use cases
- Styling a new component with Tailwind utility classes
- Fixing broken or outdated Tailwind classes after a version upgrade
- Configuring custom tokens, colors, or spacing in tailwind.config.js
- Migrating a project from Tailwind v3 to v4 syntax
- Adding variant-based styling using tailwind-variants library
- Frontend developers building with Tailwind CSS
- Teams maintaining Tailwind v4 projects
- Developers integrating Tailwind extensions and plugins
tailwind-css FAQ
No. Follow the installed version and only migrate if explicitly requested and there is a local need. Do not add packages or change integration without a request.
Use the repository's existing class-merging utility (e.g., clsx, classnames) and follow local conventions. Keep classes statically discoverable in source.
Run the Tailwind build, then inspect the final DOM and rendered UI at multiple viewports, themes, and interaction states. Textual class review alone is insufficient.
No. Apply only the syntax and features supported by the installed version. Preserve all responsive, dark-mode, interaction, and accessibility behaviors.
Only when those integrations already exist in the project locally, or when the request explicitly adds them.
Full instructions (SKILL.md)
Source of truth, from paulrberg/agent-skills.
name: tailwind-css user-invocable: false description: "Use for Tailwind v4 styling: add/fix classes, configure or migrate Tailwind, use tailwind-variants, or tw-animate-css."
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.
Related skills
More from paulrberg/agent-skills and the wider catalog.
yeet
Create and update GitHub PRs, issues, and discussions with templated workflows and idempotency checks.
biome-js
Configure and extend BiomeJS linting and formatting with shared configs and monorepo patterns.
bump-deps
Batch npm/pnpm/yarn/bun dependency updates with structured planning and validation.
bump-release
Cut releases with version bumps, changelogs, commits, and tags for single packages or monorepos.
cms-migration
Design Payload CMS collections interactively from your source CMS data before migration.
payload
TypeScript-first Next.js CMS with admin panel, REST/GraphQL APIs, and extensible hooks for content management.