AddThisFeature

Utility Class Conventions

Agree how utility classes are written so the markup stays readable as the app grows.

moderate CSS & Styling

What it adds

A written convention for the order, grouping, merging, and extraction of utility classes across the app.

What your agent is told to do

5
  1. 1

    Fix a canonical order for utility classes — layout, then box model, then typography, then colour, then state and responsive variants — and apply it mechanically so that reviewers never argue about it.

  2. 2

    Write down the extraction threshold in plain terms: how many repetitions, in how many places, before a run of utilities becomes a named component. State the number rather than leaving it to taste.

  3. 3

    Define which variants and states are permitted inline and which must be expressed as a component variant, so a screen does not accumulate a dozen conditional branches in its markup.

  4. 4

    Record where handwritten CSS is the correct answer — complex selectors, keyframes, print rules, anything that reads worse as a chain of utilities — so people do not contort the utility vocabulary to avoid a stylesheet.

  5. 5

    Leave the mechanics of combining conditional classes to Class Merge Helper and the mapping of component variants to classes to Variant Class Generator. This feature sets the rules; those two implement them.

Edge cases it handles

6
  • Extracting a component the first time a pattern repeats is premature and produces a primitive with one caller and five props. Hold the repetition threshold, and prefer a second literal copy over an abstraction invented too early.
  • Two utilities setting the same property in one class list produce a result decided by stylesheet order rather than by the order they were written, which is why contradictory pairs must be prevented at authoring time rather than reasoned about later.
  • Conditional classes must be combined through one agreed mechanism everywhere. Hand-rolled string concatenation in some components and a helper in others guarantees that caller overrides work in one place and not the next.
  • The convention needs to say when custom CSS is clearer than utilities, or every rule ends up expressed as utilities regardless of whether that reads well.
  • Long utility chains on a single element are a signal, not a style crime. Say what length triggers a look at extraction, and what to do when the element is genuinely one of a kind.
  • Arbitrary one-off values written inline defeat the token system entirely. Require a token, or a deliberate documented exception, rather than a raw measurement in the markup.

Definition of done

9
  • The convention is written down in the repository, not held as folklore.
  • Utility class order is canonical and applied consistently across the app.
  • The extraction threshold is stated as a number and observed in the codebase.
  • Contradictory utilities on the same element are prevented rather than tolerated.
  • All conditional class composition goes through a single agreed mechanism.
  • Cases where handwritten CSS is preferred are documented with examples.
  • Arbitrary inline values are absent, or carry a documented exception.
  • The feature matches the existing design system.
  • No existing functionality is broken.

Related features

How it works

  1. 1

    Copy the link

    Grab the Markdown instruction URL for this feature.

  2. 2

    Give it to your AI

    Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.

  3. 3

    It inspects, then implements

    Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.