design.md: la especificación que da a los agentes de código una identidad visual persistente

Especificación de formato (DESIGN.md) abierta por Google para describir la identidad visual de una marca o producto a agentes de programación, acompañada de un CLI (lint, diff, export, spec) publicado como @google/design.md en npm. Aclaración de desambiguación: la línea de la cola google-labs-code design corresponde al repositorio real google-labs-code/design.md, cuyo nombre lleva la extensión .md.

Qué es

google-labs-code/design.md no es una aplicación ni un modelo: es una especificación de formato que define cómo describir la identidad visual de un sistema de diseño a agentes de código, más las herramientas para validarla y exportarla. El README la resume como «una especificación de formato para describir una identidad visual a agentes de código. DESIGN.md da a los agentes un entendimiento persistente y estructurado de un sistema de diseño».

El formato combina dos capas en un único archivo de texto plano:

Front matter YAML — tokens de diseño legibles por máquina (colors, typography, rounded, spacing, components), delimitado por cercas --- al inicio del archivo.
Cuerpo Markdown — racional de diseño legible por humanos, organizado en secciones ## (por ejemplo, Overview, Colors, Typography).

Las dos capas de un DESIGN.md: front matter YAML de tokens y cuerpo Markdown con el racional de diseño

Los tokens son los valores normativos; la prosa explica por qué existen esos valores y cómo aplicarlos. Un agente que lee un archivo DESIGN.md produce una interfaz coherente con esa identidad en lugar de una interfaz genérica de «IA».

Además de la especificación, el repositorio contiene el CLI (en la carpeta packages/cli), publicado como @google/design.md en npm, que valida, compara y exporta archivos DESIGN.md emitiendo JSON que los agentes pueden actuar sobre él.

Origen

El formato nació dentro de Stitch, el producto de «design con IA» de Google Labs (dominio stitch.withgoogle.com). En Stitch, el archivo DESIGN.md permite exportar e importar las reglas de diseño de un proyecto a otro, de modo que la herramienta «entiende el razonamiento detrás de tu sistema de diseño» y genera interfaces acordes a la marca.

La publicación como código abierto se produjo el 21 de abril de 2026 a través del blog oficial de Google, con el post de Cassia Xu (Software Engineer) titulado «Stitch app’s DESIGN.md format is now open-source for designers». El texto oficial explica la motivación: en lugar de que los agentes «adivinen la intención», «pueden saber exactamente para qué sirve un color y validar sus elecciones contra las reglas de accesibilidad WCAG». El post cita un video en el que David East de Google Labs explica el formato. El repositorio se creó en GitHub el 10 de abril de 2026 y la primera versión del CLI (0.1.0) se publicó en npm el 21 de abril de 2026.

El formato está explícitamente marcado como versión alpha / borrador («open-sourcing the draft specification»); el README advierte que «el formato, el esquema de tokens y el CLI están en desarrollo activo» y que hay que esperar cambios a medida que madure.

Filosofía y principios

El archivo PHILOSOPHY.md del repositorio declara los principios de forma inequívoca:

La prosa, no los tokens, es el foco. «La calidad de un diseño generado depende menos de la precisión de sus valores que de lo claramente que se describe la intención.» El documento declara que «generalmente no aceptamos ni recomendamos requisitos de tokens en la especificación»: los tokens son contexto que sirve de referencia a la prosa, no instrucciones de renderizado.
Una referencia concreta vale más que una lista de adjetivos. Referenciar «un apunte de clase de posgrado de los 70 en la tradición de una universidad antigua» evoca un mundo completo (tinta de un solo color, márgenes generosos, serif a tamaño de lectura, ausencia de decoración); «moderno, limpio, confiable, premium» no evoca nada concreto y produce salidas genéricas. «Los adjetivos describen una región; una referencia concreta describe un punto.»

Filosofía del formato: una referencia concreta frente a adjetivos genéricos que no evocan nada específico

Restricciones negativas. Un objeto nombrado lleva sus restricciones automáticamente: un modelo sabe lo que es un apunte de clase y lo que no (no brilla, no usa degradados). «Nombrar al objeto los nombra, de la misma forma que nombrar a un perro le dice al modelo que los perros no maúlan.» Una lista larga de «no hagas» suele ser señal de que la descripción era demasiado vaga como para cargarlas.
El formato crece por sus usuarios, no por su especificación. La spec define el mínimo estructural universal (un nombre y un pequeño conjunto de categorías: colores, tipografía, espaciado, redondeo, componentes). Todo lo demás —motion, iconografía, elevación, mayúsculas, medida de párrafo— lo define cada sistema. El linter acepta cualquier clave, sección o estructura; «no se necesitó ningún cambio de la spec porque los tokens en sí son contexto, no instrucción».

Cómo funciona

Estructura del archivo y esquema de tokens

Un DESIGN.md tiene dos capas. El front matter YAML declara tokens según este esquema (según docs/spec.md):

version: <string>          # opcional, actualmente "alpha"
name: <string>
description: <string>      # opcional
omitted: <string[] | OmittedSection[]>  # secciones omitidas intencionadamente
colors:
  <token-name>: <Color>
typography:
  <token-name>: <Typography>
rounded:
  <scale-level>: <Dimension>
spacing:
  <scale-level>: <Dimension | number>
components:
  <component-name>:
    <token-name>: <string | token reference>

Tipos de token verificados en la spec:

Tipo	Formato	Ejemplo
Color	cualquier color CSS (hex, `rgb()`, `oklch()`, nombrado, etc.)	`#1A1C1E`, `oklch(62% 0.18 250)`
Dimension	número + unidad (`px`, `em`, `rem`)	`48px`, `-0.02em`
Token Reference	`{path.to.token}`	`{colors.primary}`
Typography	objeto con `fontFamily`, `fontSize`, `fontWeight`, `lineHeight`, `letterSpacing`, `fontFeature`, `fontVariation`	ver ejemplo del README

El sistema de tokens está inspirado en el formato W3C de Design Tokens (designtokens.org), del cual adopta los grupos tipados de tokens y la sintaxis de referencia {path.to.token}.

Los tokens como sistema vivo: colores, tipografía, espaciado y redondeo conectados en una constelación

Orden canónico de las secciones

Las secciones usan encabezados ## y, cuando están presentes, deben aparecer en este orden (con sus alias):

Overview (alias Brand & Style)
Colors
Typography
Layout (alias Layout & Spacing)
Elevation & Depth (alias Elevation)
Shapes
Components
Do’s and Don’ts

Comportamiento ante contenido desconocido

Escenario	Comportamiento
Encabezado de sección desconocido	Se preserva; no produce error
Nombre de token de color desconocido	Se acepta si el valor es válido
Nombre de token tipográfico desconocido	Se acepta como tipografía válida
Propiedad de componente desconocida	Se acepta con advertencia
Encabezado de sección duplicado	Error; se rechaza el archivo

El CLI

El CLI (packages/cli, publicado como @google/design.md) expone cuatro comandos. Todos aceptan una ruta de archivo o - para stdin, y por defecto emiten JSON.

Comando	Función
`lint`	Valida la corrección estructural de un `DESIGN.md`. Código de salida `1` si hay errores, `0` en otro caso.
`diff`	Compara dos archivos `DESIGN.md` e informa de cambios a nivel de token. Código de salida `1` si detecta regresiones.
`export`	Exporta tokens a otros formatos (`json-tailwind`, `css-tailwind`, `tailwind`, `dtcg`).
`spec`	Emite la especificación del formato (útil para inyectar contexto de la spec en prompts de agentes). Opciones `--rules`, `--rules-only`, `--format markdown\|json`.

El CLI en acción: los cuatro comandos lint, diff, export y spec sobre un archivo DESIGN.md

El linter ejecuta once reglas (con severidades fijas) contra el DESIGN.md analizado: broken-ref (error), missing-primary, contrast-ratio (WCAG AA, 4.5:1), orphaned-tokens, missing-typography, section-order, unknown-key (detecta erratas como colours: → colors:), token-like-ignored (advertencias); y token-summary, missing-sections, omitted-rules (información).

Validación del linter: once reglas fijas, incluida la comprobación de contraste WCAG AA y el orden canónico de secciones

También hay una API programática para usar el linter como librería:

import { lint } from '@google/design.md/linter';
const report = lint(markdownString);
console.log(report.findings);      // Finding[]
console.log(report.summary);       // { errors, warnings, info }
console.log(report.designSystem);  // DesignSystemState analizado

Interoperabilidad de tokens

El comando export convierte tokens a:

Configuración de Tailwind v3 (JSON) — --format json-tailwind (alias tailwind): objeto theme.extend para tailwind.config.js.
Tema de Tailwind v4 (CSS) — --format css-tailwind: bloque @theme { ... } con los espacios de nombres de variables CSS de Tailwind v4 (--color-*, --font-*, --text-*, --leading-*, --tracking-*, --font-weight-*, --radius-*, --spacing-*).
DTCG tokens.json (Formato de Módulos W3C de Design Tokens) — --format dtcg.

El ecosistema

El repositorio es la especificación oficial, pero alrededor ha crecido un ecosistema de colecciones, generadores y herramientas comunitarias. Estas son las que se pudieron verificar en esta ejecución (estrellas según la API de GitHub del 26 de agosto de 2026):

Colecciones y catálogos de DESIGN.md:

VoltAgent/awesome-design-md — colección de archivos DESIGN.md analizados a partir de sistemas de diseño de marcas populares; «coloca uno en tu proyecto y deja que los agentes de código generen una interfaz coincidente». 110.550 estrellas, 12.586 bifurcaciones. Creado el 31 de marzo de 2026; su página web es getdesign.md.
scroobius-pip/fudge-design-md — guías DESIGN.md generadas a partir de referencias de sitios web reales capturadas por Fudge. 75 estrellas.

Mapa del ecosistema de DESIGN.md: colecciones comunitarias, sitios generadores, extensiones de Chrome y repos hermanos de Google

Sitio y encuesta asociados:

getdesign.md — catálogo de DESIGN.md para agentes de código (300+ sitios en el catálogo) y generador de DESIGN.md. Publica la encuesta «State of DESIGN.md 2026» (basada en 64.000+ respuestas de onboarding en 11 semanas; el sitio afirma 102.000+ estrellas en GitHub y 1.000.000+ descargas de DESIGN.md — son afirmaciones del propio sitio, no mediciones independientes).

Repositorios compañeros de la misma organización google-labs-code (el mismo equipo detrás de Stitch/Jules):

google-labs-code/stitch-skills — biblioteca de Agent Skills diseñadas para el servidor MCP de Stitch. 8.187 estrellas.
google-labs-code/stitch-sdk — genera pantallas UI desde prompts de texto y extrae su HTML. 1.787 estrellas.
google-labs-code/jules-awesome-list — prompts para el agente Jules. 3.158 estrellas.
google-labs-code/jules-action (227), jules-sdk (124), jules-skills (90), action-setup (21).

Extensiones de Chrome para generar DESIGN.md (mencionadas en hilos de HN):

«AI Design Taste – Design.md Generator» (ID de Chrome Web Store peclkdlolmcclhhgpoehpikgknbmkknc).
«Design.md Style Extractor» (ID ogpdnchdjiibhobphelbbkemnnemkfma), que extrae estilos y genera archivos DESIGN.md.

Estándares de referencia: el formato se apoya en el Formato de Design Tokens del W3C (designtokens.org), al que convierte tanto hacia (export --format dtcg) como desde.

Estado oficial / semioficial

El repositorio tiene un estatus oficial de proveedor: lo aloja la organización google-labs-code de Google en GitHub, y el formato fue publicado como código abierto por Google Labs el 21 de abril de 2026 como la especificación de borrador de Stitch. La página de documentación oficial vive en stitch.withgoogle.com/docs/design-md/specification.

En la práctica esto significa:

Es la especificación de referencia para el formato DESIGN.md, usada directamente por la herramienta comercial Stitch de Google.
Está marcado como alpha / borrador, no como estándar definitivo: el README declara «expect changes to the format as it matures» y la spec indica version: alpha.
No es un estándar de consorcio: se inspira en el Formato de Design Tokens del W3C y exporta a tokens.json (DTCG), pero no es una norma W3C. Su oficialidad es la de un proveedor (Google), no de un organismo externo.

Guía rápida de uso

Instalación y primer arranque

El paquete es @google/design.md en npm.

npm install @google/design.md

En Windows, si el shell trata @ de forma especial (PowerShell), conviene entrecomillar:

npm install "@google/design.md"

O bien ejecutar directamente siempre desde el registro público (forma más sencilla):

npx @google/design.md lint DESIGN.md

En el primer arranque basta con tener un archivo DESIGN.md (front matter YAML + cuerpo Markdown). Por ejemplo, npx @google/design.md lint DESIGN.md devuelve un JSON con findings (cada uno con severity, path, message) y un summary (errors, warnings, infos).

Flujos de trabajo habituales

Para validar un DESIGN.md (detectar referencias de token rotas, contraste WCAG, secciones mal ordenadas): ejecuta npx @google/design.md lint DESIGN.md; el resultado es JSON con findings y summary. Código de salida 1 si hay errores.
Para detectar regresiones entre dos versiones de un sistema de diseño: npx @google/design.md diff DESIGN.md DESIGN-v2.md; devuelve tokens (added/removed/modified por sección) y findings con delta, más una bandera regression. Código de salida 1 si hay regresiones.
Para exportar tokens a Tailwind v3 (config JSON para tailwind.config.js): npx @google/design.md export --format json-tailwind DESIGN.md > tailwind.theme.json.
Para exportar a Tailwind v4 (CSS) o a DTCG: npx @google/design.md export --format css-tailwind DESIGN.md > theme.css o ... --format dtcg DESIGN.md > tokens.json.
Para inyectar la spec en un prompt de agente: npx @google/design.md spec (con --rules para añadir la tabla de reglas de linting).

Configuración esencial

El front matter YAML del DESIGN.md — los tokens normativos (colors, typography, rounded, spacing, components). Es lo que el linter valida y el export serializa.
La clave name (obligatoria) y version (opcional, alpha) — identifican el sistema de diseño.
omitted — lista de secciones omitidas intencionadamente (p. ej. omitted: [spacing] o {section: rounded, reason: "..."}); suprime las advertencias del linter por secciones ausentes.
Los archivos de ejemplo del repositorio (examples/atmospheric-glass, examples/paws-and-paths, examples/totality-festival) — cada uno trae DESIGN.md + tailwind.config.js + design_tokens.json como plantilla de partida.
El arnés de agente que lo consume (Claude Code, Gemini CLI, Stitch, etc.) — el DESIGN.md se coloca en el proyecto y el agente lo lee como referencia de identidad visual.

Trampas frecuentes y soluciones

Windows: el bin design.md abre el editor de Markdown. El sufijo .md en el nombre del bin colisiona con la asociación de archivos Markdown de Windows. Solución documentada en el README: usar el alias sin punto designmd → npx -p @google/design.md designmd lint DESIGN.md. En scripts de package.json (no vía npx) se recomienda siempre designmd.
npm error ENOVERSIONS («No versions available for @google/design.md»). Casi siempre significa que npm no está consultando el registro público (.npmrc con registry= a medida, espejo corporativo no sincronizado, o @google:registry mal configurado). Verifica con npm config get registry (debe ser https://registry.npmjs.org/) y, si un 404 quedó en caché, npm cache clean --force.
Errores de salida de export desdoblados (corregido en 0.4.0). Desde 0.4.0, un export exitoso siempre devuelve código de salida 0 (desacoplado de las advertencias del linter del documento de origen); antes esto impedía que builds válidas superaran puertas de pipeline.
Crashes del linter por YAML anidado o no-string (corregido en 0.3.0). Declaraciones anidadas como colors: { background: { light: '#fff' } }, valores numéricos en spacing (unit: 8) y escalares booleanos en props de componente ya no rompen el linter.
Fichero que no existe (corregido en 0.4.0). Leer un DESIGN.md inexistible o ilegible ahora emite un mensaje limpio + JSON estructurado con código de salida 2, en lugar de una trazada de pila.

Integraciones y migración

Tailwind. export --format json-tailwind (v3) y --format css-tailwind (v4) emiten directamente configuraciones de tema de Tailwind, lo que permite usar DESIGN.md como fuente de tokens y derivar el tema de la app.
DTCG / Figma / Style Dictionary. export --format dtcg produce tokens.json compatible con el Formato de Design Tokens del W3C y con pipelines de tokens (Figma, Style Dictionary, etc.).
Agentes de código. El DESIGN.md se coloca como archivo de referencia en el repositorio del proyecto; cualquier agente (Claude Code, Gemini CLI, Stitch, Cursor) lo lee para mantener coherencia visual entre generaciones y entre herramientas. npx @google/design.md spec permite inyectar la spec como contexto.
API programática. La función lint() de @google/design.md/linter permite integrar la validación en CI o en herramientas propias.
Migración. Al ser un formato de descripción (no de estado), «migrar» a DESIGN.md consiste en describir el sistema de diseño en el archivo; desde un tema de Tailwind o un tokens.json existentes se puede reconstruir el front matter, y hacia ellos se puede exportar. El repositorio no declara un asistente de conversión automática de otras herramientas.

Números del repo

Medición: 26 de agosto de 2026, API de GitHub.

Métrica	Valor
Estrellas	27.514
Bifurcaciones	2.285
Suscriptores (watchers)	171
Incidencias abiertas indicadas por la API	41
Commits (rama main)	62
Lenguaje principal	TypeScript
Licencia	Apache-2.0
Creación	10 de abril de 2026
Último push	27 de julio de 2026
Último release	0.4.0 (27 de julio de 2026)

Principales contribuidores por número de contribuciones (API de GitHub): davideast (16), rmyndharis (9), xkxx (6), mvanhorn (4), Emp1500 (3), SyedaQurratAI (2), tejas100 (2).

Descargas de npm del paquete @google/design.md (API de npm, 26 de agosto de 2026): 138.138 descargas en la última semana (2026-08-19 a 2026-08-25) y 629.805 en el último mes (2026-07-27 a 2026-08-25). Versión latest: 0.4.0 (publicada 2026-07-27).

Caveats: la API de GitHub usa open_issues_count (41), que puede incluir solicitudes de cambios (PR) abiertas, por lo que no debe leerse como conteo exclusivo de incidencias. El campo watchers_count replica las estrellas; el número de suscriptores por separado es subscribers_count (171). El conteo de 62 commits se obtuvo del encabezado Link de paginación de la API de commits (rel="last" en la página 62).

Cómo contribuir

El proceso está documentado en CONTRIBUTING.md y es abierto (a diferencia de google/skills):

Firma el CLA de Google en cla.developers.google.com antes de contribuir (tú o tu empleador retenéis el copyright; el CLA da permiso de usar y redistribuir). Si ya firmaste el CLA de Google para otro proyecto, probablemente no necesites repetirlo.
Revisa las pautas de comunidad: el proyecto sigue las Google Open Source Community Guidelines (opensource.google/conduct).
Flujo de contribución: «Todas las contribuciones, incluidas las de miembros del proyecto, requieren revisión. Usamos solicitudes de cambios (pull requests) de GitHub para ello.»
La spec se regenera: docs/spec.md indica que está generado desde spec.mdx + spec-config.ts con bun run spec:gen («Do not edit directly»). El CLI está en packages/cli (monorepo con turbo.json, tsconfig.base.json, y CI en .github/workflows/test.yml).

En la práctica, las contribuciones recientes (visible en los releases) llegan vía PR para el CLI (bugs del linter, exports) atribuidas a contribuidores externos (@rmyndharis, @Emp1500, @vikks, @SyedaQurratAI, @sbrsubuvga, @dalmaer, @arpitjain099).

Recepción de la comunidad

La evidencia recuperada muestra interés técnico y entusiasmo, junto con una crítica concreta sobre el alcance y la necesidad del formato. (El endpoint JSON de Reddit devolvió una página anti-bot en esta ejecución, por lo que no se infieren reacciones de Reddit que las fuentes no muestran.)

Hacker News — hilo principal 47887123 («Design.md: A format spec for describing a visual identity to coding agents», 24 de abril de 2026), 37 puntos, 4 comentarios:

aurareturn: «Very useful. Stealing it.» (muy útil, me lo llevo).
gavmor — la pregunta más sustancial: cómo es DESIGN.md «para jugar bien» con Figma Design Tokens o tailwind.config.js; si va a ser la fuente de verdad o solo apunta a esos, y en qué se diferencia, además de la validación determinista, de AGENTS.md; plantea el alcance en un futuro de sub-agentes discretos.
brendanmc6 — posición contraria: «he ido en dirección opuesta y decidí que el diseño no pertenece a artefactos o documentos de larga vida. Entré en un conejo experimental llamado specsmaxxing… todo lo que veo definido aquí en DESIGN.md ya está codificado en mis config de temas o archivos de componentes.»
necatiozmen: «DESIGN.md es muy útil para algo rápidamente operativo. Construimos un sitio donde puedes explorar archivos DESIGN.md de sitios populares: https://getdesign.md/».

Hacker News — hilo 47718706 («Figma is dead. Long live DESIGN.md», artículo de typeui.sh/design-md, 10 de abril de 2026), 7 puntos, 12 comentarios — la crítica más amplia encontrada:

vrganj: «¿Por qué estamos automatizando todas las actividades creativas humanas y ninguna de las tareas tediosas? ¿Hacia dónde vamos a construir un futuro donde los humanos limpian inodoros y las máquinas crean arte?».
krapp (respuesta): «El fin es el maximalismo capitalista. Contratar artistas es caro, así que se automatizan. Contratar conserjes menos».
levity: «el mercado objetivo de este tipo de automatización son las personas que ven el diseño como una tarea tediosa».

Otros hilos de HN (menor alcance, registrados para contexto):

47882713 — «Google: Stitch’s DESIGN.md format is now open-source» (el post oficial de blog.google), 3 puntos, 0 comentarios.
47852568 — «Google Launches Design.md» (docs de Stitch), 2 puntos, 0 comentarios.
47719485 — «Show HN: Figma for Coding Agents» (getdesign.md), 11 puntos, 6 comentarios.
48924796 — «State of DESIGN.md 2026 – Survey results», 3 puntos.

En conjunto, la recepción refleja un recurso con tracción real (27.514 estrellas en cuatro meses y una colección comunitaria derivada de 110.550 estrellas), con discusión técnica de calidad sobre su posición frente a AGENTS.md y a los temas existentes, y una objeción ideológica/ocupacional sobre automatizar el diseño.

design.md frente a otras propuestas

Proyecto	Coincidencia verificable	Diferencia verificable
`VoltAgent/awesome-design-md`	Colección de archivos `DESIGN.md` para que agentes de código generen una UI coincidente.	Es un catálogo de archivos de ejemplo (110.550 estrellas), no la especificación ni el linter; consume el formato de `google-labs-code/design.md`.
`getdesign.md`	Sitio de catálogo/generador de `DESIGN.md` (300+ sitios) que «sigue la spec oficial de Google DESIGN.md».	Es una herramienta comercial de generación, no el repo de la spec oficial.
Figma Design Tokens / Formato de Design Tokens del W3C (`designtokens.org`)	Formato tipado de tokens (`{path.to.token}`) interoperable.	Son formatos de solo tokens orientados a design→dev; `DESIGN.md` añade la prosa de racional de diseño y se dirige a agentes de código. `DESIGN.md` exporta a `tokens.json` (DTCG).
`tailwind.config.js` / temas de Tailwind	Definición de tokens de color/tipografía/espaciado para una app.	Es la config de un framework CSS concreto, no una especificación portable; `DESIGN.md` exporta hacia Tailwind v3/v4.
`AGENTS.md` / `CLAUDE.md`	Instrucciones legidas por agentes de código en un repo.	Son instrucciones de proceso/estilo de código en general; `DESIGN.md` se especializa en identidad visual con tokens + prosa y validación (linter, WCAG). La diferencia de alcance fue planteada explícitamente por el usuario `gavmor` en el hilo 47887123.

Casos de uso

Equipos que hacen «vibe coding» y quieren una marca coherente. Fundadores y desarrolladores que construyen landing pages y apps con IA y cuyo problema recurrente es «que se vea más premium, consistente y menos genérico» (la motivación declarada en el sitio getdesign.md) pueden describir una vez su identidad visual en un DESIGN.md y que cualquier agente la respete en cada nueva página, en lugar de reinventar la marca por generación.
Diseñadores que quieren que su racional viaje con los tokens. Quien define una identidad visual en Stitch (o en papel) puede exportarla/importarla entre proyectos; el formato conserva por qué se elige cada valor, no solo el valor, de modo que los agentes reproduzcan la intención y no una copia numérica.
Equipo front-end que mantiene un tema (Tailwind) y quiere una fuente de verdad portable. Mediante export --format json-tailwind / css-tailwind / dtcg puede derivar la config de Tailwind o un tokens.json interoperable (Figma, Style Dictionary) a partir del DESIGN.md, y usar lint/diff como puerta de CI para detectar referencias rotas, contraste no WCAG AA o regresiones entre versiones.
Agentes de código multi-herramienta. En flujos donde el mismo proyecto lo tocan Claude Code, Gemini CLI, Stitch u otras herramientas, el DESIGN.md actúa como referencia visual compartida y persistente entre agentes y sesiones; npx @google/design.md spec permite inyectar la spec como contexto de prompt.
Quien quiere validar accesibilidad y estructura automáticamente. El linter con sus once reglas (contraste WCAG AA, referencias de token rotas, orden de secciones, erratas de claves) da un gate determinista sobre archivos que de otro modo solo un humano revisaría.

Recursos

Repositorio: https://github.com/google-labs-code/design.md
Documentación / especificación oficial: https://stitch.withgoogle.com/docs/design-md/specification · spec en el repo: docs/spec.md
Philosophía del formato: PHILOSOPHY.md en el repo
CLI (npm): https://www.npmjs.com/package/@google/design.md (bin design.md / designmd)
Ejemplos oficiales: examples/atmospheric-glass, examples/paws-and-paths, examples/totality-festival (cada uno con DESIGN.md, tailwind.config.js, design_tokens.json)
Blog de lanzamiento: https://blog.google/innovation-and-ai/models-and-research/google-labs/stitch-design-md/ («Stitch’s DESIGN.md format is now open-source for designers», Cassia Xu, 21 de abril de 2026)
Colección comunitaria: https://github.com/VoltAgent/awesome-design-md (110.550 estrellas) · https://getdesign.md
Encuesta: https://getdesign.md/state-of-design-md («State of DESIGN.md 2026»)
Hilos de HN relevantes: 47887123 (37 pts), 47718706 (7 pts, 12 cmt), 47719485 (11 pts), 47882713, 48924796
Video: «Del diseño al código en minutos con Google Stitch ✨ | Carlos Alarcón – AI» (YouTube, ID i9OiB3FNYcw, canal @alarcon7a)
Formato de referencia: https://www.designtokens.org/ (W3C Design Token Format)
Repos compañeros de la organización: google-labs-code/stitch-skills (8.187), google-labs-code/stitch-sdk (1.787), google-labs-code/jules-awesome-list (3.158)

Este artículo combina el README.md, PHILOSOPHY.md, CONTRIBUTING.md, docs/spec.md y los ejemplos del repositorio, los releases (0.1.0–0.4.0), el post oficial de Google (21 de abril de 2026), la API de GitHub y la API de npm, consultados el 26 de agosto de 2026. Las cifras de estrellas y descargas cambian con el tiempo. Las afirmaciones de getdesign.md sobre su encuesta (64.000+ respuestas, 102.000+ estrellas, 1.000.000+ descargas) son del propio sitio y no están verificadas de forma independiente.