31 skills, 72 systems: cómo funciona la biblioteca de Open Design

Open Design es, mecánicamente, cuatro primitivas apiladas una sobre otra:

1. Skills — qué debe hacer el agente
2. Systems — cómo debe verse el resultado
3. Adapters — qué agente realiza el trabajo
4. El daemon — el bucle que los conecta entre sí

Cada primitiva es una carpeta de archivos. Ninguna de ellas requiere una base de datos, un runtime de plugins ni un servicio alojado. Eso es toda la biblioteca — no hay un quinto concepto escondido detrás de un muro de inicio de sesión. Esta publicación recorre cada una por turnos y muestra qué ocurre cuando diriges tu agente hacia un brief real. Si quieres el argumento de por qué lo diseñamos de esta manera antes del cómo, empieza por por qué construimos Open Design como una capa de skills, no como un producto.

Skills: la unidad de capacidad

Un skill es una carpeta que contiene un SKILL.md y cero o más archivos de apoyo. El archivo Markdown es el contrato del agente — todo lo demás en la carpeta está ahí para ayudar al agente a cumplirlo.

Anatomía de una carpeta de skill

Un skill típico se ve así:

skills/
  guizang-ppt/
    SKILL.md
    templates/
      magazine.html
    examples/
      product-launch.html
      pitch-deck.html

SKILL.md declara el nombre del skill, las condiciones de activación, la forma de la entrada, la forma de la salida y cualquier orientación en línea para el agente. Las carpetas templates/ y examples/ son opcionales pero aportan mucho: los ejemplos son artefactos conocidos y correctos con los que el agente puede hacer coincidencia de patrones, que es la diferencia entre que «hazme un deck» produzca algo coherente en lugar de algo improvisado.

El front matter es la parte que el daemon lee para registrar el skill; el cuerpo es la parte que el agente lee para ejecutarlo:

---
name: guizang-ppt
trigger: a deck, slide presentation, or pitch
output: HTML (exportable to PDF, PPTX)
---

Build a horizontal slide deck. One idea per slide.
Lead with a cover, close with a call to action.
Respect the locked-in design system for color, type, and spacing.
Pattern-match against examples/ for layout density and rhythm.

Por qué el archivo es el registro

Cuando el daemon arranca, escanea skills/ y registra cada carpeta que contenga un SKILL.md. No hay manifiesto de plugin. No hay campo de versión. No hay paso de subida, ni cola de revisión, ni build. Está el archivo, y el archivo es la fuente de verdad. Suelta una nueva carpeta dentro, reinicia el daemon, y el skill aparece en el selector. Bórrala, y desaparece — sin una entrada de registro huérfana apuntando a código que ya no existe.

Actualmente distribuimos 31 skills. Algunos son generadores de decks, algunos producen mockups móviles, algunos construyen páginas editoriales, algunos escriben documentos de oficina (Word, Excel, PowerPoint). Cada uno es una carpeta que puedes bifurcar, editar o reemplazar. Como el contrato es texto plano, «escribir un skill» y «leer un skill para entender qué hace» son la misma actividad — lo auditas abriéndolo.

Systems: la unidad de gusto

Si un skill describe qué hacer, un system describe cómo debe verse. Un system es un archivo DESIGN.md más assets de referencia opcionales. Describe una identidad visual en forma legible por máquina:

• Color — valores OKLch para primer plano, fondo, acento, error, etc.
• Tipografía — el stack de fuentes, los pesos, la escala tipográfica, las convenciones de interlineado
• Espacio — unidad base, escala de espaciado, anchos de contenedor, reglas de canalón
• Postura de layout — elecciones de grid, reglas de asimetría, preferencias de densidad
• Voz — la tipografía de las palabras: tono, vocabulario, ritmo de las frases

Un DESIGN.md es un contrato, no una biblioteca de componentes

En la práctica, un DESIGN.md se lee como un brief de marca breve y con opinión que un agente no puede malinterpretar:

## Color
--bg: oklch(98% 0.01 95);
--ink: oklch(20% 0.02 260);
--accent: oklch(72% 0.19 35);

## Type
Display — Albert Sans, 600, -0.02em
Body — Albert Sans, 400, 1.7 line-height

## Posture
Generous whitespace. One accent, used sparingly. No drop shadows.

Los colores son OKLch para que se mantengan perceptualmente uniformes entre superficies claras y oscuras; la escala tipográfica es una escalera de la que el agente no se desviará; las reglas de postura son la diferencia entre diez pantallas generadas que se sienten como un solo producto y diez que se sienten como diez becarios distintos. El agente lee esto una vez y lo respeta durante todo el trabajo.

Un system no es una biblioteca de Figma. No hay componentes, ni variantes, ni instancias anidadas, ni formato binario interponiéndose entre tú y las reglas. Es un contrato que cualquier agente puede leer y cualquier humano puede auditar. Distribuimos 72 systems de fábrica, incluidas versiones portables de Linear, Vercel, Stripe, Apple, Cursor, Figma, y una larga cola de sistemas editoriales y de marca.

Mezcla, bifurca, hazlo tuyo

Como un system es solo texto, puedes bifurcar uno y editarlo en el sitio, distribuir una variante, o escribir el tuyo desde cero en aproximadamente 30 minutos de trabajo concentrado. Incluso puedes mezclar systems a mitad de un proyecto — tipografía de Linear, lógica de color de Vercel, layout de una especificación interna — porque nada está encerrado en un binario propietario. La división entre las carpetas skills/ y design-systems/ es deliberada: capacidad y gusto son ortogonales, de modo que cualquier skill puede ejecutarse bajo cualquier system, y cualquier system puede impulsar cualquier skill.

Adapters: la unidad de agente

Los skills y los systems son texto inerte. Los adapters son la pequeña cantidad de código que los conecta con el agente que realmente hace el trabajo. Un adapter es un breve archivo TypeScript en adapters/ que sabe cómo:

• detectar si el agente está instalado en el $PATH del usuario
• iniciar una sesión con ese agente
• canalizar una invocación de skill hacia él
• recopilar la salida de vuelta

Hoy distribuimos adapters para 12 agentes: Claude, Codex, Gemini, Cursor, Copilot, OpenCode, Devin, Hermes, Pi, Kimi, Kiro, Qwen. El daemon detecta automáticamente cuáles están presentes y los ofrece como un desplegable en el primer arranque — no configuras nada, simplemente ves los agentes que ya tienes.

Primitiva	Vive en	Archivo	Fuente de verdad
Skill	skills/	SKILL.md	el archivo en disco
System	design-systems/	DESIGN.md	el archivo en disco
Adapter	adapters/	un archivo .ts	una llamada a register()

Si quieres añadir un nuevo adapter, el archivo son aproximadamente 80 líneas de TypeScript y una única llamada a register(). Ningún SDK que aprender, ningún permiso que solicitar, ningún registro central donde publicar. El mismo agente en el que ya confías en tu portátil se convierte en el motor — Open Design nunca lo reemplaza. (La pieza complementaria flujo de trabajo de diseño BYOK recorre cómo dirigir un adapter hacia tu propia clave.)

El daemon: el bucle que lo une todo

El daemon es el único proceso en ejecución del sistema. Es un pequeño proceso de Node que inicias con pnpm tools-dev, y hace cuatro cosas en secuencia:

1. Detectar — escanea el $PATH en busca de agentes instalados y skills/ en busca de skills instalados, al arrancar
2. Descubrir — abre un formulario interactivo de preguntas para precisar superficie, audiencia, tono, escala y contexto de marca del brief actual
3. Dirigir — presenta 5 direcciones visuales deterministas (paleta en OKLch, stack de fuentes, pistas de postura de layout) y pide al usuario que elija una
4. Entregar — invoca el skill seleccionado con el system fijado, deja que el agente escriba en disco, y previsualiza la salida en un iframe en sandbox

Todo el bucle cabe en aproximadamente 1500 líneas de código. Es intencionadamente pequeño. La inteligencia está en los skills, no en el runtime — el trabajo del daemon es escanear carpetas, enrutar un brief a través de los cuatro pasos y quitarse de en medio. Esa pequeñez es el punto clave: hay muy poco aquí que pueda pudrirse, y casi nada que pueda tener tu trabajo como rehén.

Cómo se siente en la práctica

Supón que quieres un deck de lanzamiento para una nueva funcionalidad de producto. Este es el flujo:

1. Ejecutas pnpm tools-dev en una terminal. El daemon arranca en localhost:7780.
2. Abres la URL. El daemon te muestra qué agentes encontró (p. ej. Claude, Cursor, Codex).
3. Eliges guizang-ppt de la lista de skills.
4. Aparece un formulario de preguntas de 30 segundos: quién es la audiencia, cuál es el tono, cuál es el contexto de marca.
5. Se te muestran 5 direcciones visuales — distintas paletas, emparejamientos tipográficos, posturas de layout. Eliges una.
6. El agente escribe en disco. Un iframe en sandbox muestra el resultado. Puedes exportar a HTML, PDF, PPTX, ZIP o Markdown.

Recórrelo de vuelta a través de las primitivas y todo el conjunto es legible: el paso 3 eligió un skill, el paso 5 fijó un system, el agente detrás vino a través de un adapter, y el daemon ejecutó el bucle de cuatro pasos. La salida es real. Los archivos son tuyos. Puedes editarlos en cualquier editor, entregárselos a un diseñador, o alimentarlos de vuelta a otro skill.

Por qué archivos, no una base de datos

Cada primitiva — skills, systems, adapters — es una carpeta de archivos de texto. No hay base de datos central. No hay «cuenta de Open Design». No hay servicio alojado que tenga que seguir funcionando para que tu trabajo siga funcionando.

Esto es un compromiso deliberado. Renunciamos a la capacidad de hacer analíticas ingeniosas entre usuarios, memoria entre proyectos, o colaboración alojada. A cambio recibimos: portabilidad, longevidad, auditabilidad, y la capacidad de que cualquiera bifurque la biblioteca entera y distribuya su propia variante. Un SKILL.md escrito hoy se lee idéntico para un agente dentro de dos años y para un humano sin herramienta alguna — no puede decirse lo mismo de un plugin anclado a la API del año pasado.

Si has visto morir a una generación de herramientas de diseño llevándose tus archivos con ellas, entenderás por qué este compromiso vale la pena.

Lecturas relacionadas

• Por qué construimos Open Design como una capa de skills, no como un producto — la apuesta detrás de las cuatro primitivas
• Flujo de trabajo de diseño BYOK: ejecuta Claude, Codex o Qwen con tu propia clave — cómo se conectan los adapters al agente que ya pagas
• La capa de layout que el canvas solía ocultar — por qué las reglas de postura en un DESIGN.md superan a arrastrar cajas en un canvas