LSCSS

Audit checklist

How to review an existing CSS codebase

A good audit does not start by counting selectors. It starts by understanding ownership, override safety, and whether the team is maintaining a system or surviving one.

Ask this first

Ask first: Are you auditing code, or auditing the decisions that created it?

Selectors are symptoms. Ownership is usually the diagnosis.

A messy selector is often a symptom. The real issue is usually unclear ownership, weak defaults, or accidental architecture.

Structure and layers

Quick checks

  • Are layers defined?
  • Is legacy isolated?
  • Are utilities controlled?
  • Are tokens enforced?
  • Is theme separate from components?
  • Are hacks temporary?
  • Are overrides predictable?
  • Are cascade layers defined clearly?
  • Does old CSS live in a legacy layer?
  • Are overrides predictable without important declarations?
  • Can developers explain where new CSS should live?
  • Do files reflect ownership, not historical accidents?

Tokens and consistency

  • Are colours, spacing, typography, and radius tokenised?
  • Are random values appearing across components?
  • Do people invent new spacing values under deadline pressure?
  • Are media queries named and consistent?
  • Can design changes happen without hunting 47 hard-coded colours?

Random values create design inconsistency instead of design systems.

Components and ownership

  • Are selectors shallow and scoped?
  • Are components named semantically?
  • Are repeated utility groups asking to become components?
  • Are files small enough to understand quickly?
  • Do components own behaviour, or are they hiding layout problems?

If a component file feels like a small novel, it is probably multiple components.

State, modifiers, and behaviour

  • Are modifiers used for permanent reusable variants?
  • Are temporary states using clear .is_* classes?
  • Is JavaScript creating styling confusion instead of state clarity?
  • Can developers explain why something is a modifier and not state?

Legacy CSS and hacks

  • Is there a real hacks layer?
  • Are temporary fixes reviewed and removed?
  • Is legacy CSS shrinking over time?
  • Are important declarations normalised?
  • Does anyone know why the z-index is 999999?

If hacks become permanent residents, governance already failed.

Fast warning signs

  • Everyone solves overrides with more specificity.
  • No one agrees where CSS should live.
  • Utilities appear faster than components.
  • New developers fear touching shared stylesheets.
  • The phrase “do not touch that file” exists.

These are not style issues. They are delivery risks.

Next useful pages