As a project grows, certain class combinations start repeating - a card layout, a primary button, a badge. Instead of copying that combination in ten places across the project, it's worth defining your own design tokens and component classes.

Design tokens as @theme variables

Design tokens are named, reusable values - colors, spacing, font sizes. In Tailwind v4 they're defined as CSS custom properties inside @theme (see chapter 11). For a growing project, it's worth aligning these values with a design language rather than a single page:

@import 'tailwindcss';

@theme {
  /* Brand colors */
  --color-brand-dark: #1a2332;
  --color-brand-slate: #475569;
  --color-brand-accent: #0ea5e9;
  --color-brand-accent-dim: #0369a1;
  --color-brand-red: #dc2626;

  /* Recurring spacing */
  --spacing-section: 4rem;
  --spacing-card: 1.5rem;
}

Custom component classes with @apply

For truly recurring combinations (not for every single element!), the @apply directive lets you build your own, semantic CSS class out of several utility classes:

@layer components {
  .card {
    @apply rounded-xl border border-slate-200 bg-white p-6 shadow-sm;
  }

  .btn-primary {
    @apply inline-block rounded-lg bg-brand-accent px-5 py-2.5
           font-semibold text-white transition hover:bg-brand-accent-dim;
  }
}

In the template, this becomes a single, descriptive class:

<div class="card">
    <a href="#" class="btn-primary">Get in touch</a>
</div>

Keeping token names consistent

A good naming scheme for color tokens makes future additions easy to predict: brand-* for brand colors, brand-accent-dim for a darkened variant of the accent (also used, for instance, by this project's tip() callout component), instead of arbitrary names like blue-special.