Named styles a site can reuse — style once, apply to twenty elements, change it in one place.

Why this is not the style panel

The inspector writes utilities ONTO an element. That is right for the one card that needs to be a little wider, and wrong for the twenty cards that are meant to look the same: making them match means repeating yourself twenty times, and changing them means finding all twenty again. What Bricks calls a global class is the missing half — a name you can put on many elements, holding the styling they share.

What one compiles to

A class is a name and a list of Tailwind utilities. All of a site's classes are written into ONE stylesheet row the CMS owns, regenerated whole on every change:

@layer components {
  .card-shell { @apply rounded-xl bg-white p-6; }
}

Two decisions in that snippet, both load-bearing:

• @apply, so a class is written in the same vocabulary as everything else in this editor. The row is :custom, which MishkaCmsCore.Runtime.Compilers.TailwindCompiler appends INTO the source Tailwind processes — not after it — so @apply resolves.
• @layer components, so a per-element utility still wins. Without the layer, source order decides: the row is appended last, and .card-shell's padding would quietly beat the p-8 an author put on one card to make it the exception.

One row, rewritten whole

Not one row per class. A stylesheet row is a compile input and a versioned record; twenty of them for twenty classes would be twenty recompiles and twenty histories of something nobody thinks of as a document. The row is found by its reserved name, so it is recognisable in the Stylesheets admin — and editable there, at the cost of being rewritten the next time a class changes here.