designkit
designkit
A design system that lives in someone's head, or in Figma, is invisible to the agent writing the UI. DESIGN.md is what the ecosystem converged on instead: an open format from Google Labs (Apache-2.0, google-labs-code/design.md) that pairs machine-readable design tokens in YAML front matter with human-readable rationale in prose. It is deliberately the design counterpart to the agent instruction files coding agents already read (CLAUDE.md and its equivalents), a persistent contract in the repo root that survives sessions, and that any DESIGN.md-aware agent reads.
designkit does the half the ecosystem left empty. Every other tool hands you a design system from somewhere else, whether a file reverse-engineered from Stripe or a palette retrieved from a product-type lookup table. designkit derives yours from the UI you already shipped, and tells you later when it has gone stale.
That makes the grounding rule the whole skill: every token must be a value that appears in your codebase. The one exception is a repo with no UI at all, where there is nothing to derive from; there, every token is a value you supplied (see init's interview), and designkit still invents none. Clustering forty near-identical greys into a scale is derivation. Picking a nicer neighbouring hex because it rounds better is invention, and it is the one thing designkit never does.
What designkit is not
- Not a UI generator. It records the system; it writes no components, no pages, no application CSS. A skill that both defines the taste and applies it can't be held to the grounding rule.
- Not a taste library. It ships no palettes, no font pairings, no style catalog. If your project has no design system, designkit proposes one from the values your code already uses, or, with no UI at all, from the values you supply; when neither exists it says so. It never imports someone else's.
- Not a spec implementation. Linting, contrast checking, token export, and the schema itself belong to the official CLI. designkit shells out and reports; it is not a second, worse implementation.
- Not a design critique. Whether the system is any good is a human's call. designkit reports what is there, including when what's there is a mess.
- Not the glossary or the decision log. Domain vocabulary and architecture decisions belong elsewhere; a design token is neither.