explainx / blog
Google Labs' David East explains DESIGN.md: a human-and-machine-readable design spec that combines rationale with exact values so AI agents can apply design systems semantically and validate accessibility before shipping.
May 8, 2026
DESIGN.md isn't just a spec; it's a workflow. Learn how to use the explainx.ai design registry and generator skill to teach your AI agents exactly how your brand should look and feel.
Jun 28, 2026
Prompt engineering fixes your wording. Context engineering fixes what the model sees. This guide draws the precise line, shows concrete examples of each in action, and maps out when to reach for which tool.
Jun 28, 2026
RAG is not just a retrieval problem — it's a context engineering problem. What you retrieve, how you inject it, and where it lives in the context window determines whether the model can actually use it. This guide covers the full pipeline from chunking to injection.
Design system files are often machine-readable but not agent-readable in the way modern coding workflows require. The values are there, but the reasoning is missing. In this Google Labs walkthrough, David East frames DESIGN.md as the missing bridge: one structured format that stores both the intent and the exact implementation details.
Watch: YouTube - DESIGN.md overview with David East
Most teams have at least three parallel representations of design:
--color-primary, spacing scales, typography values)When AI agents edit UI code, they can see #2 clearly, but #1 and #3 are often implicit. That gap leads to familiar issues: visually plausible changes that violate brand intent, inaccessible contrast pairings, or inconsistent component behavior.
DESIGN.md proposes collapsing those layers into one portable artifact.
The high-leverage idea in the video is this: tokens should be interpreted as semantic roles, not static variables.
color.surface.critical is not just a hex valueThat is the shift from value substitution to design reasoning.
As described in the talk, the format combines:
This makes the file useful to both:
DESIGN.md and SKILL.md are complementary, not competing formats:
| File | Primary purpose | Typical content | Best use |
|---|---|---|---|
| DESIGN.md | Encode design-system semantics for humans + agents | Roles, rationale, tokens, constraints, accessibility intent | Keep UI decisions consistent across design + code |
| SKILL.md | Encode reusable agent behavior/workflows | Triggers, procedures, examples, guardrails | Teach agents how to execute repeatable tasks |
In practical terms:
DESIGN.md to define what good UI means in your systemSKILL.md to define how an agent should work when building or updating UIOne of the strongest workflow ideas in the video is the CLI linter that can validate design updates against WCAG constraints before an agent writes code changes.
That is operationally important because it moves accessibility from:
to:
For teams using AI-assisted coding, this is the practical path to scaling output without scaling regressions.
DESIGN.md is bigger than a single tool integration. It points to a broader pattern:
If your team is already using agents for UI work, this pattern can reduce "looks right, feels wrong" diffs and make design reviews more about product decisions than cleanup.
If you are evaluating DESIGN.md-style workflows, start small:
The goal is not to replace design judgment. It is to make that judgment explicit enough that both humans and agents can execute it consistently.
SKILL.md, triggering, and production workflowsDESIGN.md’s promise is straightforward: keep the design why and the design values together, so AI stops treating your system like a bag of variables and starts treating it like a set of product decisions.
For teams building AI-native front-end workflows, that is a meaningful upgrade from token sync to design intelligence.
Source video: YouTube - DESIGN.md with Google Labs' David East