Por qué hicimos open source nuestro design system — y por qué el tuyo debería ser una skill de IA

El design system de Agentikas tiene un fichero. Markdown. 800 líneas. Tokens de color, decisiones tipográficas, regla de tres reglas para botones primarios, qué se usa cuándo y por qué.

Está en GitHub con licencia MIT. Y lo más importante: está escrito para que un modelo lo lea y lo aplique. No para impresionar a un comité de diseño.

Esta es la decisión que hay detrás, y por qué creemos que es el formato correcto para los design systems de 2026.

El problema con un design system "tradicional"

Un design system tradicional vive en Figma. Tiene una librería de componentes, un manual de tokens, una sección de reglas. El equipo de diseño lo mantiene. El equipo de desarrollo lo "implementa" en código (React, Vue, lo que sea). Hay un día anual donde se actualiza la documentación.

Cuando aparece una nueva pantalla, el flujo es:

1. El diseñador la dibuja en Figma respetando los componentes
2. El desarrollador la traduce a código respetando los componentes
3. Alguien — humano — revisa que ambos respeten el system

Funciona en equipos grandes con disciplina. En el resto, deriva. Cinco meses después tienes tres versiones del botón primario en producción. Cuando un agente o un copilot empieza a generar UI, el problema escala — un modelo no abre Figma. Lee código. Y si el código no es la fuente de verdad, lo que escribe el modelo se desvía.

El design system como skill

En Agentikas tomamos otra ruta. El design system es un fichero markdown que vive en skills/design-system.md. Tiene tres secciones:

1. Tokens en formato máquina

## Tokens

### Colores
- `--color-primary`: #C8352A   /* Rojo Agentikas */
- `--color-text`: #0D0D0D      /* Casi negro */
- `--color-bg`: #F7F5F0        /* Papel cálido */
- `--color-muted`: #6B6B6B

### Tipografía
- `--font-heading`: 'Playfair Display', serif
- `--font-body`: 'DM Sans', sans-serif

### Espaciado
- escala 4-8-16-24-32-48-64
- nunca usar valores fuera de la escala

Los tokens se exportan también como CSS variables para que el código los consuma directamente. Pero la fuente de verdad — la que el modelo lee — es el markdown.

2. Componentes con uso

## Botón primario

```html
<button class="btn btn-primary">Llamada a la acción</button>
```

**Cuándo se usa:** una sola acción primaria por sección. Nunca dos botones primarios juntos.
**Cuándo NO se usa:** acciones secundarias (usa `btn-secondary`), enlaces dentro de texto (usa <a>).

Cada componente tiene HTML de ejemplo, decisiones de cuándo se usa y cuándo no, y eventualmente las variantes legítimas. El modelo no tiene que adivinar — está descrito.

3. Reglas de marca con ejemplos contrastados

## Voz visual

✅ **Usar:** mucho espacio en blanco, una sola foto de cabecera por post, tipografía en escala clara.
❌ **No usar:** stock corporativo (handshakes, gente sonriendo en oficinas), gradientes saturados, gráficos sin propósito.

✅ **Botones:** texto en mayúscula primera (Crear blog), no todo en mayúsculas.
❌ **No:** "CREAR BLOG" en mayúsculas. "Crear Blog" tampoco.

Las reglas con ejemplos contrastados son lo que mejor lee un modelo. Una lista de "no hagas X" sin ejemplo a veces se ignora. Una lista que dice "✅ Hace X · ❌ No hagas Y" lo respeta más, porque entiende el patrón.

Por qué markdown y no JSON

Hay un argumento natural para hacer el design system en JSON estructurado. Es lo que hacen Style Dictionary, Tokens Studio, etc. Funciona bien para tokens — colores, espaciado, tipografía. Funciona mal para reglas, contexto, decisiones.

JSON es para datos. Markdown es para conocimiento. Una regla como "los botones primarios nunca van en pares" no es un dato — es una decisión con razones. En markdown puedes contar la razón. En JSON, queda como un valor booleano sin contexto y el modelo no sabe por qué.

Lo que terminamos con: los tokens en JSON exportable, las decisiones en markdown. El modelo lee ambos. El diseñador edita el markdown. El compilador genera el JSON desde el markdown como artefacto.

El efecto en la generación

Cuando un autor pide al editor "genera una landing para esta sección", el modelo recibe en su system prompt:

1. El BRAND.md del blog (tono, vocabulario)
2. El design-system.md (tokens, componentes, reglas)
3. El skill correspondiente (blog-writer.md, landing-builder.md)

La generación respeta los tres. No es por magia — es porque están descritos en un formato que el modelo procesa nativamente. Los componentes que aparecen en la salida son los del system. Los colores son los tokens. Las reglas se respetan porque están escritas como reglas.

El resultado: la consistencia visual entre lo que un humano construye y lo que el modelo genera converge. La deriva del "design system traditional" desaparece, porque el modelo no entiende Figma — entiende markdown.

Open source: por qué libre, por qué útil

El design system de Agentikas está en github.com/agentikas/agentikas-skills con licencia MIT. Forka, copia los tokens, adapta las reglas a tu marca. La razón es doble:

1. El conocimiento se acumula más rápido cuando es público. Si un equipo en Berlín mejora la pluralización del brand reviewer en alemán, lo añade. Lo aprovechan todos los blogs en alemán al instante.
2. Estandarizar el formato beneficia a todo el ecosistema. Si los design systems del mundo son markdown skills, los modelos saben dónde buscarlos. Hoy lo sabes tú; mañana lo sabe Claude por defecto.

El futuro cercano es modelos que generan UI en tu marca sin que tú escribas nada. Para que eso funcione, tu marca tiene que estar en un formato que el modelo lea. Markdown es ese formato. Diséñalo así desde hoy.

---

Forka el design system de Agentikas en github.com/agentikas/agentikas-skills. Licencia MIT, sin atribución requerida. Si añades reglas para tu vertical, abre un PR — todo el ecosistema te lo agradece.