Aestheria vs Supernova
Supernova moves a design system you own to where it has to land, from Figma variables to a pull request. Aestheria, the design context layer, is the system itself. Pipeline, and payload.
Pipeline and payload.
Supernova is infrastructure for a design system that exists: pulling tokens out of Figma variables, transforming them per platform, opening the pull request, and exposing the result to coding agents. For a team with a system and people maintaining it, that is real work being removed.
Aestheria is not infrastructure for your system. It is a system, shipped complete and written for machines from the start. The distinction is what each one assumes you already have, and it decides which of the two is useful to you first.
The half that was never in a format to move.
Syncing tokens is a solved-shaped problem. What stays unsolved is the reasoning: which token belongs on this surface, when a pattern applies, which states a screen owes its user, whether an action needs a confirm step. That knowledge lives in review comments and in two senior people's heads, so no pipeline can carry it, because it was never in a format anything could pick up.
Aestheria puts that half in files: usage rules attached to the tokens, constraints attached to the components, six skills carrying judgment as editable text an agent loads per task, and a validation call so the standard is enforceable rather than aspirational.
Which one your team needs.
If you have a mature system and people maintaining it, your problem is distribution, and a pipeline is the right tool. If your agents are generating a dozen surfaces a week against no shared reference, your problem is that the reference does not exist, and a pipeline has nothing to carry.
The two are compatible where both apply. Aestheria is plain files and tokens, so a team already running a pipeline can treat the kit as the system it distributes.
| Supernova | Aestheria | |
|---|---|---|
| Role | Pipeline and platform for your system | The system, written to be read by agents |
| Assumes | You have a design system and maintain it | You may have nothing yet |
| Contents | Your tokens, assets, and documentation | 405 tokens, 37 components, 63 templates, six skills |
| Design reasoning | Whatever your team documents | Attached to tokens and components, loaded per task |
| Agent access | MCP over your system | MCP, repo files, or CDN import |
| Source of truth | The hosted platform | Files in your repository |
| Verification | Your review process | validate_snippet returns specific violations |
- 405 tokens
- 6 themes
- 37 components
- 27 charts
- 63 templates
Questions
Do Aestheria and Supernova compete?
Only if you read both as "design system platform". One pipelines a system you already own; the other is a system written for agents to consume. A team with a mature system might use both; a team with none needs the second first.
We have a token pipeline already. What is missing?
The reasoning. A synced token list tells an agent which values exist, not which one belongs on a card border or when a pattern applies. That half usually lives in review comments, which is why nothing has been able to move it.
Can we bring our own tokens?
Yes. The kit is yours to edit down to the token, so teams commonly replace the palette and keep the structure, the rules, and the judgment that come with it.