Every React codebase that has shipped for a while already has a design system: a set of colours, sizes and components that repeat. To discover it, read three things from the code. The declarations (Tailwind config, @theme blocks, CSS custom properties). The usage (classes, CSS, inline styles, every raw value). And the components (definitions, use sites, variants). Where declarations and usage disagree is where the real system and the intended one have come apart.
Start with what is declared
Tokens live in more places than people remember: a Tailwind v3 theme.extend, a Tailwind v4 @theme block, :root custom properties, dark-mode overrides under .dark or [data-theme], and package-level stylesheets in a monorepo. Follow every var() chain to a real value in every theme, or you will compare against the wrong colour.
Then read what is used
Usage tells you which parts of the declared system are real. Count token classes and raw values separately. A token nobody uses is dead; a raw value used dozens of times is a token nobody declared.
In Lunary, Saer read 28,798 colour observations across 4,262 files and reduced them to 115 findings and 14 questions for a person. Most of the work is resolution, not judgement.
Finally, the components
List every component, resolve every JSX use to its definition through imports, aliases and barrels, and note duplicates, unused components and variants that are declared but never passed. This is the part of the system agents and new joiners most need, and it is rarely documented.
What Saer does about this
- Colour in the beta: Tailwind v3 and v4, CSS custom properties, themes and modes, monorepos.
- Typography, foundations and components, in the beta.
- Generated documentation pages from what Saer found: planned.
Every capability and its state: what Saer checks.
See it on your own codebase.
Request early access