These 13 Tailwind CSS prompts help ChatGPT, Claude, Claude Code and Codex write Tailwind v4 code: migrating from v3, turning brand colors into a @theme, building responsive and container query layouts, dark mode, custom utilities, fixing classes that don't generate, and cleaning up long class lists. Each prompt pushes the model toward your theme values instead of one-off arbitrary values.
For the framework around your styles, see the Next.js prompts and React prompts. For a full accessibility review, use the accessibility prompts.
How to use these prompts
Copy a prompt and fill the blanks in double braces. A blank with a colon has a default: {{framework:React}} means React unless you change it.
Say "Tailwind v4" in every prompt. The upgrade guide lists changes that models trip over: configuration moved into CSS, several utilities were renamed (shadow-sm is now shadow-xs, outline-none is now outline-hidden), the default border color is now currentColor, and stacked variants apply left to right. A model writing v3 habits will produce classes that look right and render wrong.
Paste your theme. Your CSS file with the @theme block tells the model which colors, fonts and spacing exist. Without it, the model invents bg-[#3b82f6] and your design drifts.
Describe states, not just the look. Hover, focus, disabled, loading, error, empty and dark mode each need classes. Listing them in the prompt is the difference between a mockup and a component.
How do you set up and migrate to Tailwind v4?
1. Migrate a project from v3 to v4
The official upgrade tool, npx @tailwindcss/upgrade, requires Node.js 20 or higher. This prompt helps you review its diff and fix what it can't.
I ran npx @tailwindcss/upgrade on a Tailwind v3 project. Here is the diff and
the files it didn't change:
{{diff}}
Check the result against the v4 upgrade guide: renamed utilities (shadow,
blur, rounded, outline-none, ring width), the border color default, @layer
utilities rewritten as @utility, variant stacking order, the important
modifier at the end, and bg-(--var) syntax for CSS variables. List anything
still on v3 behavior, with the file, the old class and the fix. Flag places
where a visual change is likely so I can check them in the browser.
2. Move a tailwind.config.js theme into @theme
The theme variables page explains that variables in namespaces like --color-* and --font-* create utility classes, while plain :root variables don't.
Convert the theme section of this tailwind.config.js into a Tailwind v4 @theme
block in CSS:
{{config}}
Use the right namespace for each value (--color-*, --font-*, --text-*,
--spacing-*, --radius-*, --shadow-*, --breakpoint-*). If the config replaced
a whole default palette, reset that namespace with initial. Keep values that
shouldn't become utilities in :root instead. Show the CSS, then a table of
old config key, new variable and the utility it creates.
3. Build a theme from brand colors
Create a Tailwind v4 @theme for this brand:
Brand colors: {{colors}}
Fonts: {{fonts:Inter for UI, a serif for headings}}
Feel: {{feel:calm, dense, for a data-heavy dashboard}}
Generate a full shade scale (50 to 950) for each brand color in OKLCH,
semantic tokens for surface, text, border, accent and danger, a radius and
shadow scale, and font variables. Check that body text on each surface
meets a 4.5:1 contrast ratio and list any pair that doesn't. Explain which
default namespaces you replaced and which you kept.
How do you build components with Tailwind?
4. Build a component with variants
The class detection docs say Tailwind scans files as plain text and can't understand string concatenation, so variants must map to complete class names.
Build a {{component:Button}} component in {{framework:React}} with Tailwind v4.
Variants: {{variants:primary, secondary, ghost, danger}}
Sizes: {{sizes:sm, md, lg}}
States: hover, focus-visible, active, disabled, loading
Map each variant and size to complete class strings in an object, never
build class names from pieces. Use only colors and spacing from my theme:
{{theme}}
Give it a visible focus-visible ring, keep the label readable while
loading, and forward native button attributes. Show the component and one
example of each variant.
5. Make a layout responsive, mobile first
The responsive design docs say unprefixed utilities apply to all screen sizes and prefixed ones apply at that breakpoint and above: "Don't think of sm: as meaning "on small screens", think of it as "at the small breakpoint"."
Make this layout responsive with Tailwind v4, mobile first:
{{markup}}
Behavior I want: {{behavior:one column on phones, sidebar from md, three-column grid from xl}}
Write the base classes for the smallest screen, then add md:, lg: and xl:
only where the layout changes. Use gap instead of margins between grid and
flex children. Check that nothing scrolls sideways at a 320px wide
viewport. Show the markup and explain each breakpoint change in one line.
6. Use container queries for a reusable card
A card that sits in a sidebar and a wide grid should respond to its container, not the viewport.
This card is used in a narrow sidebar and in a wide content grid:
{{card}}
Rewrite it with Tailwind v4 container queries: mark the wrapper with
@container and use @sm:, @md: and @max-md: variants so it stacks when
narrow and goes horizontal when wide. If cards nest inside another
container, use a named container like @container/card. Show the markup and
two usage examples at different widths.
7. Add a dark mode toggle
By default Tailwind's dark: variant follows prefers-color-scheme. The dark mode docs show how to switch it to a class or data attribute with @custom-variant.
Add dark mode to this app with Tailwind v4.
Toggle: {{toggle:light, dark and system, saved per user}}
Framework: {{framework:Next.js App Router}}
Current styles: {{files}}
Override the dark variant with @custom-variant so it follows a
{{selector:data-theme attribute}} on the html element. Set the theme before
first paint so there is no flash, and respect the system setting when the
user hasn't chosen. Prefer semantic theme tokens that change in dark mode
over adding dark: to every element. Show the CSS, the toggle component and
the script.
How do you keep Tailwind classes maintainable?
8. Clean up a long class list
These Tailwind elements have long, repeated class lists:
{{markup}}
For each repeated pattern, recommend one of: extract a component (preferred
when markup repeats), a variant map, or a custom @utility for a single
property pattern. Use @apply only where I can't change the markup, such as
third-party HTML. Sort the remaining classes in a consistent order and
remove conflicting or dead classes. Show before and after for each change.
9. Find why classes aren't generated
Some Tailwind v4 classes don't show up in my CSS.
Missing classes: {{classes}}
Where they're used: {{code}}
My CSS entry file: {{css}}
Check, in order: class names built from pieces or template strings; files
Tailwind doesn't scan by default (.gitignore, node_modules, CSS files);
a package or folder that needs @source; a base path set with source();
classes that only exist at runtime and need @source inline(). Give me the
cause and the smallest fix.
10. Write a custom utility or variant
I keep writing the same CSS in Tailwind v4 for {{need:hiding scrollbars while keeping scroll}}.
Write it as a custom utility with @utility so it works with variants like
hover: and lg:. If what I need is a new state rather than a style, write a
@custom-variant instead, for example one keyed on a data attribute. Show
the CSS, an example of use with a variant, and tell me if a built-in
utility already does this.
How do you review and convert Tailwind code?
11. Accessibility pass on Tailwind markup
Tailwind has variants for accessibility work: focus-visible, motion-safe and motion-reduce, forced-colors and aria-*, all documented on the states and variants page.
Review this Tailwind markup for accessibility:
{{markup}}
Check: a visible focus-visible style on every interactive element (not
removed with outline-hidden and nothing in its place); animations wrapped
in motion-safe or turned off with motion-reduce; states styled from aria-*
attributes so the visual state matches what screen readers hear; text
contrast against its background; forced-colors mode still showing borders
and focus. Show the fixed markup and list each change.
12. Replace arbitrary values with theme tokens
Audit these files for Tailwind arbitrary values like bg-[#1e293b],
p-[13px] or text-[15px]:
{{files}}
My theme: {{theme}}
For each one, map it to the nearest theme token, or say it should become a
new token because it repeats. Leave true one-offs alone and say why. Output
a table of file, old class, new class and visual difference, then the
@theme additions I need.
13. Convert existing CSS to Tailwind
Convert this {{source:plain CSS and HTML}} to Tailwind v4 utilities:
{{code}}
Map values to my theme scale where close: {{theme}}
Keep the same look at every breakpoint and state. List anything that
doesn't map cleanly to utilities, such as keyframes, complex selectors or
third-party overrides, and suggest where each should live (@theme,
@utility, or a small CSS file). Show the converted markup.
What should you check before you accept Tailwind output?
Open the result in a browser at a phone width and a desktop width before you read the classes. Layout bugs are faster to see than to spot in a long class list.
Then check four things. First, every class exists in v4: search the output for v3 habits, such as shadow-sm where you meant v3's smaller shadow (now shadow-xs), outline-none used to hide focus, or removed utilities like bg-opacity-*, which v4 replaces with modifiers like bg-black/50. Second, no class is built from pieces, because Tailwind will silently skip it. Third, colors and spacing come from your theme, not arbitrary values. Fourth, tab through the component with a keyboard and confirm a visible focus style on every control.
If the model keeps making the same mistake, add the fix to your project's instructions file once instead of correcting it in every chat.
How do you make these prompts part of your workflow?
Pick the two prompts you use most, usually the component prompt and the class cleanup prompt, and add your theme file to them once so you never paste it again. The shadcn skill and frontend design skill pages cover ready-made skills for component and visual work. To turn your own version into a skill, paste it into the SKILL.md generator.
Kipt stores prompts like these as Markdown in a private GitHub repo you own, with {{framework:React}} style blanks, tags and Cmd+K search. Skills you keep there install into Claude Code or Codex with one command.