Por qué construimos Open Design como una capa de skills, no como un producto
La mayoría de las herramientas de diseño con IA intentan reemplazar el agente que ya tienes en tu portátil. Open Design apuesta por lo contrario: ofrecer una capa ligera de skills, sistemas y adaptadores que convierten cualquier coding agent en un motor de diseño, sin atarte a una nueva aplicación.
El coding agent más potente que tienes ahora mismo en tu portátil es Claude, Codex, Cursor, Gemini, OpenCode o Qwen. No creemos que necesites otro. Lo que falta no es inteligencia bruta, sino gusto, estructura y un flujo de trabajo que respete el diseño como un oficio.
Open Design es nuestro intento de aportar esa capa que falta. No es un producto de chat. No es una herramienta de diseño que «usa IA por debajo». Es una capa ligera de skills: una carpeta de archivos SKILL.md, una biblioteca portátil de sistemas de diseño y un daemon que detecta automáticamente tus agentes CLI existentes y los conecta entre sí.
Este artículo explica por qué tomamos esa decisión, qué implica para la forma en que usarás Open Design y por qué «capa, no producto» es una apuesta por la longevidad y no un atajo.
Un producto tendría la forma equivocada
El instinto, al iniciar un proyecto de diseño con IA en 2026, es construir una nueva aplicación: una interfaz de chat, un lienzo, un sistema de facturación, una factura de modelo que crece linealmente con tu número de usuarios. Consideramos ese camino y lo descartamos por tres razones.
La interfaz de chat es un commodity
Cada usuario ya tiene un agente capaz y un cuadro de chat en el que confía. Añadir uno peor —envuelto en nuestra marca, sin la memoria muscular que han construido— no ayuda a nadie. El valor no está en la interfaz. El valor está en lo que el agente hace después de que pulsas enter: si produce una presentación que parece diseñada o un muro de divs.
La factura del modelo es un impuesto sobre la creatividad
Si integras la inferencia en el producto, la economía te fuerza la mano. Tienes que aplicar un margen a los tokens, limitar las sesiones largas y racionar el acceso a los modelos más nuevos para que tu margen sobreviva. Cada uno de esos movimientos castiga precisamente el comportamiento que una herramienta de diseño debería premiar: iterar, explorar y volver a ejecutar el agente porque el tercer borrador es donde el trabajo se vuelve bueno.
El lock-in es el valor por defecto equivocado
Los diseñadores deberían poder marcharse con sus archivos, sus sistemas y sus skills intactos. Un producto envuelve todo en un estado propietario: lo exportas y obtienes una sombra aplanada de lo real. Una capa de skills no tiene nada que envolver, porque los artefactos son los archivos. Marcharse no cuesta nada, y por eso precisamente quedarse significa algo.
Así que construimos la capa en su lugar. Suelta una carpeta, reinicia el daemon y la skill aparece. Llévate la carpeta contigo, suéltala en un agente distinto y la skill también funciona allí.
Qué es realmente una skill
Una skill en Open Design es un archivo SKILL.md más recursos de apoyo opcionales en la misma carpeta. El archivo Markdown describe:
- Qué hace la skill: un párrafo, en lenguaje sencillo
- Cuándo invocarla: las condiciones de activación, escritas para que el agente pueda enrutar correctamente
- La forma de la salida: HTML, PDF, diapositivas, un brief en Markdown
- Las restricciones: paleta en OKLch, pila tipográfica, postura de maquetación, vocabulario de marca
El agente lee el archivo, decide si invocarla y escribe la salida en disco. No hay sistema de plugins, ni superficie de API, ni matriz de compatibilidad de versiones. Si sabes escribir Markdown, puedes publicar una skill.
Anatomía de una skill
En concreto, una skill es un directorio que el daemon descubre al arrancar:
skills/
magazine-poster/
SKILL.md # the contract: trigger, output shape, constraints
examples/
launch.html # a known-good artifact the agent can pattern-matchEl front matter de SKILL.md nombra la skill y sus activadores; el cuerpo es la guía que el agente lee como un brief. Nada registra la skill salvo su presencia en disco: ningún manifiesto que actualizar, ningún paso de compilación, ninguna cola de revisión.
Por qué los archivos ganan a los plugins
Esto es intencionado. Hemos visto cómo los ecosistemas de plugins se deterioran desde hace quince años, cada uno un compromiso entre expresividad y longevidad, sin ganar ninguna de las dos. Un plugin es una instantánea de la API de alguien en un año concreto; el runtime evoluciona, la API se rompe y el flujo de trabajo del que dependías desaparece. Los archivos no se rompen. Un SKILL.md escrito hoy se leerá exactamente igual para un agente dentro de dos años, y para un humano sin herramienta alguna.
Por qué los sistemas también son Markdown
Open Design incluye decenas de sistemas de diseño —Linear, Vercel, Stripe, Apple, Cursor, Figma y más— como archivos DESIGN.md. La misma idea: portátiles, legibles, ingeribles por el agente.
Un sistema de diseño, en este contexto, no es una biblioteca de Figma. Es un contrato:
## 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.El agente lee el contrato y produce un trabajo que lo respeta: colores en OKLch para que se mantengan perceptualmente uniformes, una escala tipográfica de la que no se desvía y una postura de maquetación que hace que diez pantallas generadas se sientan como un solo producto.
Mezcla, bifurca y hazlo tuyo
Como un sistema es solo texto, puedes bifurcar uno y editarlo en su sitio, publicar una variante o escribir el tuyo desde cero en treinta minutos. Incluso puedes mezclar sistemas a mitad de proyecto —tomar la tipografía de Linear, la lógica de color de Vercel, la maquetación de una especificación interna a medida— porque no hay ningún formato binario interponiéndose entre tú y las reglas. La mecánica completa de cómo se componen las skills y los sistemas se cubre en 31 skills, 72 sistemas: cómo funciona la biblioteca de Open Design.
BYOK es el único modelo honesto
Open Design funciona con bring-your-own-key. Pegas una URL base y una API key de cualquier endpoint compatible con OpenAI —DeepSeek, Groq, OpenRouter, tu propio vLLM autoalojado— y listo:
OPENAI_BASE_URL=https://api.deepseek.com/v1
OPENAI_API_KEY=sk-…No ejecutamos inferencia. No aplicamos margen a los tokens. No tenemos una relación de facturación contigo. Eso no es un problema de sostenibilidad: es la única respuesta honesta a la pregunta «¿quién paga cuando el agente se ejecuta?».
La privacidad se deriva de la misma decisión
Como el daemon llama al proveedor directamente desde tu máquina, tus prompts nunca pasan por nuestros servidores. No hay ningún proxy que los registre, ni una canalización de analítica que retenga en silencio tu trabajo aún sin publicar. Para el trabajo de agencia o cualquier cosa bajo NDA, «¿dónde se ejecuta esto?» deja de ser una conversación de compras y se convierte en una opción de configuración. Las concesiones más profundas —y las asperezas que aún existen— están en el chequeo de realidad de BYOK.
La respuesta a quién paga es: tú, directamente, al proveedor del modelo que elegiste. Nosotros nos apartamos del camino.
Qué significa esto para ti
Si quieres un SaaS pulido con un bonito cuadro de chat y una única suscripción, no somos la herramienta adecuada. Hay buenos productos con esa forma; úsalos.
Si quieres un flujo de trabajo donde:
- el agente en el que ya confías hace el trabajo,
- las skills son archivos que puedes leer y editar,
- los sistemas de diseño son portátiles entre proyectos y agentes,
- y la factura va al proveedor del modelo, no a nosotros,
entonces Open Design está hecho para ti. Entra en el repositorio de GitHub, ejecuta pnpm tools-dev, apunta tu agente a una skill y publica.
La capa de skills gana porque no compite con el agente de tu portátil. Lo potencia.
Lecturas relacionadas
- 31 skills, 72 sistemas: cómo funciona la biblioteca de Open Design: las cuatro primitivas con las que se construye esta capa
- Flujo de trabajo de diseño BYOK: ejecuta Claude, Codex o Qwen con tu propia key: el modelo bring-your-own-key en la práctica
- La alternativa de código abierto a Figma: dónde aterriza la apuesta de «capa, no producto» frente al titular del sector