Dec 10, 2025
7 min read

Migrating to DaisyUI with Claude Code: Using llms.txt for AI-Assisted Styling

How dropping a single context file into a project transformed AI-assisted UI development and made CSS migrations painless

Today’s session included migrating the room-tracker project from custom CSS to DaisyUI 5. What made this interesting wasn’t the migration itself - it was how Claude Code handled it once I gave it the right context.

The llms.txt Pattern

DaisyUI publishes a special file at https://daisyui.com/llms.txt - a condensed reference designed specifically for LLMs. It contains:

  • Installation instructions for DaisyUI 5 + Tailwind 4
  • Component class names and their purposes
  • Color system documentation
  • Theme configuration syntax
  • Usage rules and best practices

I downloaded this file and dropped it into the project root as daisy.llms.txt:

curl -o daisy.llms.txt https://daisyui.com/llms.txt
$ ls -la daisy.llms.txt
-rw-rw-r-- 1 kyran kyran 62493 Dec 10 14:05 daisy.llms.txt

$ head -20 daisy.llms.txt
---
description: daisyUI 5
alwaysApply: true
applyTo: "**"
downloadedFrom: https://daisyui.com/llms.txt
version: 5.5.x
---

# daisyUI 5
daisyUI 5 is a CSS library for Tailwind CSS 4
daisyUI 5 provides class names for common UI components

The file is ~62KB of structured documentation - component classes, modifiers, theme colors, everything an LLM needs to write correct DaisyUI code without hallucinating class names.

Why llms.txt Matters

[Content placeholder: Discuss the problem of LLMs hallucinating CSS class names. Old tutorials, outdated docs, mixing Bootstrap/Tailwind/DaisyUI patterns.]

Without the context file, Claude would:

  • Mix DaisyUI 4 and 5 syntax (breaking changes between versions)
  • Use deprecated Tailwind CSS 3 patterns with Tailwind 4
  • Suggest tailwind.config.js (deprecated in v4)
  • Hallucinate non-existent utility classes

With daisy.llms.txt in the project, Claude:

  • Used correct DaisyUI 5 class names
  • Followed the @plugin "daisyui" syntax for CSS
  • Applied the right color semantic (btn-primary, bg-base-200)
  • Understood the component/part/modifier class hierarchy

The Migration Process

Step 1: Install DaisyUI

Claude correctly identified the installation steps from the llms.txt:

pnpm add -D daisyui@latest

Then updated the CSS entry point:

--- a/src/app.css
+++ b/src/app.css
@@ -1,45 +1,3 @@
 @import "tailwindcss";
-
-/* Custom color variables */
-:root {
-    --color-primary: #3b82f6;
-    --color-primary-hover: #2563eb;
-    --color-success: #22c55e;
-    --color-warning: #eab308;
-    --color-error: #ef4444;
-    --color-bg-subtle: #f8fafc;
-}
-
-/* Custom button base */
-.btn-custom {
-    @apply px-4 py-2 rounded-lg font-medium transition-colors;
-}
-.btn-custom-primary {
-    @apply bg-blue-600 text-white hover:bg-blue-700;
-}
-
-/* Custom card styles */
-.card-custom {
-    @apply bg-white rounded-xl shadow-md p-4;
-}
-
-/* ...50+ more lines of custom utilities... */
+@plugin "daisyui";

Step 2: Identify Components to Migrate

Claude explored the existing components and identified what needed conversion:

[Content placeholder: List the main components that were migrated - Button, Card, Badge, Table, Modal, etc.]

Components converted:

  • Custom button styles → btn btn-primary, btn-ghost, btn-sm
  • Card containers → card, card-body, card-title
  • Status indicators → badge badge-success, badge-warning, badge-error
  • Loading spinners → loading loading-spinner
  • Form inputs → input, select, checkbox
  • Tables → table table-zebra

Step 3: Remove Custom CSS

[Content placeholder: Describe the old CSS patterns that were removed - custom color variables, button styles, card shadows, etc.]

The old approach used custom CSS classes with Tailwind utilities:

/* Old custom button styles - app.css before migration */
.btn-custom {
    @apply px-4 py-2 rounded-lg font-medium transition-colors;
    @apply focus:outline-none focus:ring-2 focus:ring-offset-2;
}
.btn-custom-primary {
    @apply bg-blue-600 text-white hover:bg-blue-700;
    @apply focus:ring-blue-500;
}
.btn-custom-secondary {
    @apply bg-gray-200 text-gray-800 hover:bg-gray-300;
}
.btn-custom-ghost {
    @apply bg-transparent hover:bg-gray-100;
}
.btn-custom-danger {
    @apply bg-red-600 text-white hover:bg-red-700;
}

/* Custom badge styles */
.badge-custom {
    @apply px-2 py-1 text-xs font-medium rounded-full;
}
.badge-success { @apply bg-green-100 text-green-800; }
.badge-warning { @apply bg-yellow-100 text-yellow-800; }
.badge-error { @apply bg-red-100 text-red-800; }

/* Custom loading spinner */
.spinner {
    @apply animate-spin h-4 w-4 border-2 border-current;
    border-top-color: transparent;
    border-radius: 50%;
}

This was replaced with DaisyUI’s semantic classes:

<!-- Old -->
<button class="btn-custom btn-custom-primary">Save</button>

<!-- New -->
<button class="btn btn-primary">Save</button>

Step 4: Update Component Library

The project had a custom Button.svelte component. Claude updated it to use DaisyUI classes internally:

<script>
    let { variant = 'primary', size = 'md', loading = false, ...props } = $props();

    const variantClasses = {
        primary: 'btn-primary',
        secondary: 'btn-secondary',
        ghost: 'btn-ghost',
        danger: 'btn-error',
        success: 'btn-success'
    };

    const sizeClasses = {
        sm: 'btn-sm',
        md: '',
        lg: 'btn-lg'
    };
</script>

<button
    class="btn {variantClasses[variant]} {sizeClasses[size]}"
    disabled={loading}
    {...props}
>
    {#if loading}
        <span class="loading loading-spinner loading-sm"></span>
    {/if}
    <slot />
</button>

[SCREENSHOT: Side-by-side comparison of Button component before and after migration]

Step 5: Theme Configuration

DaisyUI’s theme system replaced custom color variables:

@plugin "daisyui" {
    themes: light --default, dark --prefersdark;
}

[Content placeholder: Discuss the theme switcher implementation and dark mode handling]

What the llms.txt File Contains

Here’s a sample of what makes daisy.llms.txt useful:

## daisyUI 5 usage rules
1. We can give styles to a HTML element by adding daisyUI class names to it.
2. Components can be customized using Tailwind CSS utility classes if the
   customization is not possible using the existing daisyUI classes.
3. If customization didn't work because of CSS specificity issues, you can
   use the `!` at the end of the Tailwind CSS utility class to override.
4. Only allowed class names are existing daisyUI class names or Tailwind CSS
   utility classes.

And the class reference:

## Button
component: `btn`
style: `btn-outline` `btn-link` `btn-glass` `btn-block` `btn-wide` `btn-square` `btn-circle`
color: `btn-neutral` `btn-primary` `btn-secondary` `btn-accent` `btn-info` `btn-success` `btn-warning` `btn-error`
size: `btn-lg` `btn-md` `btn-sm` `btn-xs`
modifier: `btn-active` `btn-disabled`

[Content placeholder: Discuss how this structured format helps Claude understand the API better than scattered documentation]

Results

[SCREENSHOT: The Camera Controls panel showing DaisyUI-styled buttons, badges, and loading states]

[SCREENSHOT: The movements list page with DaisyUI table styling]

Before migration:

  • ~500 lines of custom CSS
  • Inconsistent button styles across components
  • Manual dark mode color switching
  • Specificity conflicts between components

After migration:

  • ~20 lines of CSS (just the imports and theme config)
  • Consistent component styling via DaisyUI classes
  • Automatic dark mode via theme system
  • No specificity issues - DaisyUI handles the cascade

Lessons Learned

1. Context files are force multipliers

[Content placeholder: Discuss how the llms.txt pattern could be adopted by other libraries]

The llms.txt pattern should become standard for UI libraries. A single, well-structured file gives AI assistants everything they need to use the library correctly.

2. Migration is easier than maintenance

[Content placeholder: Discuss how maintaining custom CSS is more work than migrating to a component library]

We resisted DaisyUI for months because “migration seems like a lot of work.” The actual migration took a few hours. Maintaining custom CSS was taking hours every week.

3. Semantic classes beat utility-only

[Content placeholder: Compare pure Tailwind vs DaisyUI’s semantic layer]

Pure Tailwind works, but btn btn-primary is more readable than px-4 py-2 bg-blue-600 hover:bg-blue-700 text-white rounded-lg font-medium transition-colors.

DaisyUI gives you the semantic clarity of component classes with the escape hatch of Tailwind utilities when you need customization.

The llms.txt Specification

DaisyUI’s file follows an emerging pattern for AI-friendly documentation. Key elements:

  1. Frontmatter metadata - version, download URL, scope
  2. Installation instructions - exact commands, no ambiguity
  3. Usage rules - numbered list of patterns to follow
  4. Class reference - component → parts → modifiers hierarchy
  5. Code examples - show don’t tell

Other libraries are starting to adopt this. Check if your favorite UI library has an /llms.txt endpoint.

References