SearchBook a call

DESIGN ENGINEERING / Essay

DESIGN.md is README.md for visual identity

A useful file format arrived quickly. The work now is to stop its surrounding ecosystem from becoming a pile of incompatible approximations.

In April 2026, Google Labs open-sourced DESIGN.md: a format specification for describing a visual identity to coding agents. The basic move is familiar. Put a text file at the root of a repository. Give an agent enough stable context to make a better decision on the next task. README.md describes a project. AGENTS.md describes how to work in it. DESIGN.md describes the visual system an agent should respect.

That is a sensible addition to a repository. Design systems already exist as Figma files, Cascading Style Sheets (CSS) variables, component libraries, style guides, and unspoken local conventions. An agent asked to add a page sees only part of that system unless the system is made legible in the codebase. A plain file is a practical bridge: it can carry colors and type values in frontmatter, then explain how those values are used in prose.

The format arrived with a recognizable body: Overview, Colors, Typography, Layout & Spacing, Elevation & Depth, Shapes, Components, and Do’s and Don’ts. Design Extractor documents the same order. The public prompt in designmd.supply does too. The shape is not mysterious. It is a compact design-system brief with a place for values and a place for judgment.

What happened next is more interesting than the file itself. Within roughly five months, an ecosystem appeared around populating, extracting, cataloging, and selling those files. The question is no longer whether a DESIGN.md can be useful. The question is whether the surrounding market will make it trustworthy and interoperable.

A file, then a small economy

Google’s repository was at 28,047 stars as of September 2026. That signals attention, but the larger signal is what others built around it. VoltAgent’s awesome-design-md was at 117,378 stars as of September 2026, a collection of reverse-engineered design files for recognizable brands. Its companion site, getdesign.md, presents itself as a browsable frontend and carefully says the entries are reference material, not official analyses or exact reproductions.

Other products chose different points in the pipeline. Design.md Store packages ready-made files that a developer can rename to DESIGN.md and place beside package.json. designmd.me takes a Uniform Resource Locator (URL) and generates a file, with a command-line interface (CLI) and a Figma import path. design-extractor.com takes a URL too, but exposes the workflow through a Model Context Protocol (MCP) server as well as a web interface and Chrome extension. Refero Styles publishes long per-brand reference pages with tokens, component notes, CSS properties, prompts, and a clear caveat that the output is interpreted.

None of these products authors the underlying format. They are instances, pipes, catalogs, and commercial surfaces around a format that Google Labs named and published. That distinction matters. A group can have a popular convention without a shared process for resolving ambiguity, declaring compatibility, or evaluating output quality.

The distribution model is also uneven. A file at repository root is nearly frictionless. The research found that Claude Code can auto-discover it there, while Cursor requires an explicit @DESIGN.md mention. That simplicity is a strength. A tool does not need a proprietary editor or a new runtime to start using the artifact. But the same simplicity lets every generator make up its own frontmatter names, conventions, and claims about what a file represents.

README worked because the contract was modest

The comparison to README is helpful, as long as it is not stretched too far. READMEs do not all look alike, and Markdown does not force a project to document its purpose, installation, license, or contribution process in one particular arrangement. The convention survives because it has a modest contract: there is a discoverable text file, and humans know where to look first.

DESIGN.md has a stronger contract. A value in the file can influence generated product user interface (UI). A phrase such as “use the primary color sparingly” is not just project documentation. It is guidance to a system that may write code at scale. If the primary color was inferred from one screenshot, if the typeface was misidentified, or if a component note was copied from an approximation, the agent can turn that error into repeated implementation.

This is why a loose convention is not enough. An exact brand reconstruction, an independently authored style study, a generic “editorial” preset, and a manually maintained first-party design system are all valid artifacts. They are not interchangeable artifacts. The file needs to tell its reader which one it is.

Refero is unusually clear on this point. Its Brex style page says source measurements are normalized, roles and recommendations are interpreted, and HyperText Markup Language (HTML) examples are reconstructions rather than source components. getdesign.md says its files are reference material rather than exact reproductions. Design.md Store calls its specs independent, unofficial works inspired by public websites. These are not defects in the writing. They are necessary disclosures about what extraction can and cannot produce.

The mistake would be to treat those caveats as small-print legal language rather than data about the artifact. An agent needs the caveat in the file, attached to the relevant section, before it decides how heavily to rely on it.

Fragmentation is already visible

The research landscape has one clear signal of consolidation and several signals of its absence. The Design Tokens Community Group (DTCG) format gives tokens a shared shape. Design skills do not. Extractors do not. DESIGN.md has a known name and an upstream repository, but the products producing files already differ in token shape, extraction method, delivery path, and provenance.

There is also a concentration problem. Our public open source software (OSS) survey found that VoltAgent and Bergside account for a disproportionate share of visible, highly starred artifacts. This does not make their projects less useful. It does mean that star counts are evidence of format virality more than independent validation from many unrelated teams. A collection with 117,378 stars as of September 2026 is important, but it does not prove that its individual reconstructions are ground truth.

The format can fragment in quieter ways than a public fork. A generator can emit colors.primary; another can emit color.brand.primary; a third can describe the same choice only in prose. One service can identify its output as a Document Object Model (DOM) scrape, another as a large language model (LLM) summary, and a third can omit the method entirely. Every version may look like a reasonable Markdown document to a human. A parser and an agent will see incompatible assumptions.

This is also where agent distribution becomes relevant. Some services have a direct programmatic route. Design Extractor documents tools including extract_design, get_extraction, and list_my_extractions in its MCP server. Sona UI offers an llms.txt, a manifest, a catalog, and OpenAPI alongside its component registry. getdesign.md, Design.md Store, and CollectUI do not offer the equivalent programmatic interface. There is no common expectation that a design file can be fetched, checked, refreshed, or attributed in the same way.

The smallest useful extension

Velofy’s draft profile proposes a conservative answer. Keep the existing eight body sections. Do not rename the format. Do not ask teams to migrate from a file their tools already recognize. Add only the pieces that let another person or agent reason about the file.

First, shape the frontmatter around DTCG’s $type, $value, and $description convention. A color should not become unusable simply because it moved from a design file to a build pipeline. Second, require a provenance block: source_url, extraction_method, confidence, generated_by, and generated_at. Third, make a linter proposal explicit as a proposal. There is no Velofy DESIGN.md package on npm and no MCP server for it today, and the draft should not imply one.

The point is not that every design decision can be reduced to a number. The point is that a file should make the boundary clear. Tokens are data. The eight sections are context. Provenance says how much trust to place in each.

That is a better fit for the actual state of the field than a claim of a new standard. Google Labs already supplied a useful starting point. DTCG already supplies a mature token vocabulary. The missing work is connective tissue: a profile that says which parts are source, which parts are inference, and which exports are possible.

A neutral map is more useful than another extractor

There is room for products that extract a site quickly. There is room for catalogs and skill packs. But the current open problem is not a shortage of places to paste a URL. It is a shortage of shared measurements and shared labels.

No source in this research publishes an extraction-fidelity score against ground truth. No common schema says whether a “primary” token came from CSS, a screenshot, or a model’s interpretation. No general discovery layer tells an agent when a file was last generated or whether it is first-party. Even licensing is uneven: the OSS survey notes visible repositories without an open source license. anthropics/skills has no LICENSE file, and the GreenSock Animation Platform (GSAP) uses custom license terms.

A neutral map can make those conditions visible without pretending to solve them by decree. It can separate first-party files from reconstructions, show the extraction method, link to a source, state uncertainty, and name the license. It can preserve the useful facts that current catalogs hide behind a thumbnail or a download button.

That work is dull in the good sense. It helps a builder decide what can be used, what must be checked, and what should remain only inspiration. DESIGN.md should become boring infrastructure only after its claims can be inspected.

What Velofy is doing next

Velofy intends to keep a public draft profile and a first-party DESIGN.md for this site. We intend to document proposed linting and DTCG export behavior before presenting either as a shipped tool. We also intend to use provenance and confidence labels in any future catalog work, so an agent can distinguish a source record from an interpretation.

← All design-engineering entries