What Milda is

Milda is a compiler for design systems. You describe a system once, as one document; Milda produces the React library, the Figma file, the documentation site and the files an AI agent reads, all from that one description. Nothing generated is ever the source of anything.

#The problem it solves

A design system usually exists several times over: tokens in one tool, components in a repository, usage guidance in a wiki, and a fourth interpretation in design files. Each copy drifts from the others, and keeping them in step is constant manual work that nobody is paid for. Milda starts from a different premise: the system is the source, and code is one of its outputs.

#One document, many outputs

Studio ─┐                                        ┌─ React library (npm package)
        ├─▶  the Milda document  ─▶  generators ─┼─ Figma variables and components
.milda ─┘     one neutral value                  ├─ documentation site
                                                 ├─ DESIGN.md · AGENTS.md · llms.txt
                                                 └─ the CLI, the MCP server

The document is platform-neutral: it contains no CSS, no HTML tag, no framework API. A button is described by what it is and what it does, not by <button> or a class name. Every platform-specific decision is made later, by a generator, when it realizes the document for one target. That is what lets one description feed React today, Figma beside it, and other targets as they ship.

#What a system is made of

A .milda file shows the shape of a system better than a diagram, because the file is the system. This one is complete: it opens in the Playground and describes one token set and one button.

milda 0.10
prelude 0.0.2

meta { name "Acme" }

context-group ColorScheme { Light Dark }

foundations {
  layer Base {
    token violet/600 : color = hex(7c3aed)
    token violet/500 : color = hex(8b5cf6)
    token white : color = hex(ffffff)
    token gray/900 : color = hex(0f172a)
  }
  layer Semantic {
    token accent : color = alias by ColorScheme { default -> violet.600; Dark -> violet.500 }
    token on-accent : color = alias by ColorScheme { default -> white }
    token surface : color = alias by ColorScheme { default -> white; Dark -> gray.900 }
    token space/sm : spacing = 8px
    token space/lg : spacing = 16px
    token radius/sm : radius = 6px
  }
}

component Button "The primary action." {
  archetype Button

  props {
    label : string = "Get started"
    disabled : boolean = false
  }

  events { click }

  part Button: container {
    emits { click on activate }
    bind state disabled disabled
    layout { stack row; gap space.sm; align center }
    fill accent
    ink on-accent
    corner radius.sm
    inset space.sm space.lg
    state hovered { fill violet.500 }
    state disabled { opacity 50 }
  }

  part label: text {
    slot of content default
    content bind label
  }
}

Read top to bottom, a system has four parts, and the file is written in that order:

• Foundations - the tokens: typed values in layers, able to answer differently per context (light and dark, density, platform, brand). Everything else points at them by name.
• Components - each one a contract (props and events, the surface consumers code against) and an anatomy of parts that say what they are, how they are painted and laid out, and how they behave. A component starts from an archetype, a built-in blueprint that brings the behaviour and the accessibility with it.
• The library - what surrounds the components: their groups, the demo scenes, the asset and icon libraries, and the documentation pages.
• Rules - how the system is meant to be used, in a form a checker can evaluate and an agent can follow.

One thing is deliberately not in the document: which targets a project produces. That is a choice about what you do with the system, kept beside it, so the same system can feed any generator.

#Two front-ends, one document

The document has two ways in, and they are equals. The Studio is the visual editor: people author there, with structured editors for every token type, a live canvas, and a preview that can force any state. The .milda text is the same document written down: it is what an AI agent reads and writes, what an import produces, what a pull request diffs, and what you type in the Playground to learn the language. Neither is a view over the other; both edit the one document.

#What Milda is, and is not

• It is an authoring system and a compiler, not a component kit with a fixed look. You define your own system; the archetypes give it correctness, not style.
• It is the source of truth, not a synchronization layer between several equal sources. Import exists for adoption; ongoing changes happen in Milda and flow out.
• It produces real source and ordinary packages. The generated React depends on React alone; there is no Milda runtime in your app, and the code is yours to keep whatever happens.
• It models portable intent and does not pretend every platform is the same. Where a target genuinely differs, the difference is declared, and a generator says what it could not express rather than approximating in silence.

#Where to go next

Or go straight to the part of the model you need: