Diseñando con Sleek

Resumen

sleek.design es una herramienta de diseño de aplicaciones móviles impulsada por IA. Se interactúa con ella a través de una API REST en /api/v1/* para crear proyectos, describir lo que deseas construir en lenguaje natural, y obtener pantallas renderizadas. Toda la comunicación es HTTP estándar con autenticación mediante token portador.

URL base: https://sleek.design Autenticación: Authorization: Bearer $SLEEK_API_KEY en cada solicitud /api/v1/* Tipo de contenido: application/json (solicitudes y respuestas) CORS: Habilitado en todos los endpoints /api/v1/* Parseo de respuestas: escribe el cuerpo en un archivo (curl -o run.json) y analiza el archivo. No pases JSON a través de echo: en zsh expande los \n escapados dentro de los valores de cadena en nuevas líneas reales, lo que hace que el cuerpo sea JSON inválido. Documentación de API: Especificación OpenAPI en https://sleek.design/api/v1/spec.json; documentación navegable en https://sleek.design/api/v1/docs. Obtén la especificación para cualquier detalle del contrato no cubierto aquí.

Prerrequisitos: Clave API

Si SLEEK_API_KEY no está configurada, usa el flujo de dispositivo para que el usuario nunca maneje la clave en bruto:

POST https://sleek.design/api/v1/device/start (sin autenticación) con el cuerpo {"source": "slug-de-tu-herramienta"}. La respuesta contiene una verificationUrl, un userCode comprobable por humanos, un deviceCode secreto y un interval de sondeo en segundos.
Muestra al usuario la verificationUrl y el userCode, e indícale que confirme que el código coincide antes de aprobar.
Sondea POST https://sleek.design/api/v1/device/poll con {"deviceCode": "..."} cada interval segundos. Cuando el usuario apruebe, el sondeo devuelve {"status": "approved", "key": "sk_..."} exactamente una vez: guárdalo como SLEEP_API_KEY. Los códigos caducan después de 15 minutos; en caso de expired, comienza de nuevo.

Alternativa: envía al usuario a https://sleek.design/agents/setup, que maneja el inicio de sesión, la actualización del plan y la creación de clave en un solo lugar, y pídele que pegue la clave de vuelta. Las claves también se pueden gestionar en https://sleek.design/dashboard/api-keys. El valor completo de la clave se muestra solo una vez en la creación.

Planes: las cuentas gratuitas pueden probar la API con sus créditos de prueba únicos (aproximadamente una ejecución de diseño), por lo que un nuevo usuario puede ver su primer diseño antes de cualquier decisión de pago. El uso sostenido requiere el plan Pro o superior ($49.99/mes, o $30/mes facturado anualmente a $360/año; incluye 20,000 créditos de IA mensuales, aproximadamente 650 pantallas). Cuando el costo sea relevante (el usuario pregunta, se necesita una actualización para continuar, o estás a punto de enviarlo a una página de pago), indica este precio claramente, incluyendo la opción anual. Nunca permitas que un paso de pago sea una sorpresa.

Ámbitos de clave

Ámbito	Lo que desbloquea
`projects:read`	Listar / obtener proyectos
`projects:write`	Crear / eliminar proyectos
`components:read`	Listar componentes en un proyecto
`chats:read`	Obtener estado de ejecución del chat
`chats:write`	Enviar mensajes de chat
`screenshots`	Renderizar capturas de pantalla de componentes

Crea una clave solo con los ámbitos necesarios para la tarea.

Seguridad y Privacidad

Host único: Todas las solicitudes van exclusivamente a https://sleek.design. No se envían datos a terceros.
Solo HTTPS: Toda la comunicación usa HTTPS. La clave API se transmite solo en el encabezado Authorization a los endpoints de Sleek.
Ámbitos mínimos: Crea claves API solo con los ámbitos requeridos para la tarea. Prefiere claves de corta duración o revocables.
URLs de imágenes: Al usar imageUrls en mensajes de chat, esas URLs son obtenidas por los servidores de Sleek. Evita pasar URLs que contengan contenido sensible.

Diseñando

Las formas completas de solicitud/respuesta para cada endpoint utilizado a continuación están en la referencia de API.

1. Crear un proyecto

Crea un proyecto con POST /api/v1/projects si aún no existe. Deriva un nombre de la solicitud.

Cada proyecto tiene su propio tema, estilo y sistema de diseño. Si el usuario quiere múltiples variaciones de diseño, crea un proyecto separado para cada variación.

2. Enviar un mensaje de chat

Envía la solicitud con POST /api/v1/projects/:id/chat/messages. Sleek planifica el contenido y diseño de la pantalla a partir de tu mensaje, e inventará un estilo visual si no le das uno. No descompongas la solicitud en pantallas ni agregues detalles del producto que el usuario no pidió; envía la intención completa como un solo mensaje. Si el usuario describió pantallas específicas, inclúyelas. Sleek produce diseños más ricos cuando se le da espacio para planificar.

Redacta una dirección de estilo: escríbela siempre que el usuario te haya dado algo para basarse: imágenes de referencia, aplicaciones que le gustan, adjetivos de ambiente, cosas a evitar, o cuando estés produciendo variaciones, una dirección por variación. Pasa la solicitud sin cambios solo cuando esté desnuda. Una dirección de estilo es un párrafo completo, incluido en el mensaje, que cubre el estado de ánimo (2–3 adjetivos), la estrategia de color (la lógica, no los códigos hex), la sensación tipográfica, la filosofía de diseño, el estilo de los componentes (radios, bordes vs sombras, tratamiento de navegación), estilo de imágenes e ilustraciones, y uno o dos detalles distintivos. Comprométete con una paleta, una dirección tipográfica y una sensación general; cualquier cosa que solo establezca un ambiente se lee como una sugerencia, no como una dirección. Sé firme; no evites. Pon la personalidad en color, tipo e imágenes en lugar de en un diseño o navegación inusual.

Extiende lo que el usuario te dio y nunca lo contradigas. Cuando apunten a imágenes de referencia o aplicaciones que les gusten, estudia cada una y lleva lo que tomes a la dirección; Sleek solo ve imágenes pasadas como imageUrls, así que para cualquier cosa local, la dirección es cómo esas referencias llegan a él. Toma prestados patrones, nunca la marca, el contenido o el nombre de la fuente.

Usa una dirección de estilo o un referenceId, no ambos; una referencia ya lleva su propia guía de estilo completa.

Siembra un estilo con una referencia: Sleek mantiene un catálogo de referencias de diseño. Cuando el usuario quiera un aspecto específico o pida opciones de estilo, enuméralas con GET /api/v1/references (cada una tiene un name y previewImageUrls que puedes mostrar) y pasa el id elegido como referenceId en el primer mensaje a un proyecto, para que su guía de estilo siembre todo el diseño.

Identifica tu herramienta: envía siempre source, el slug de la herramienta que realiza la solicitud. El editor de Sleek lo usa para mostrar al usuario quién está diseñando mientras se transmite la ejecución. Valores reconocidos: claude-code, claude, codex, chatgpt, cursor, openclaw, grok. Si tu herramienta no está listada, envía un slug corto en kebab-case para ella de todos modos (máx. 64 caracteres). Los valores no reconocidos están bien y reciben una etiqueta genérica.

Míralo en vivo: las ejecuciones se renderizan en el editor de Sleek en tiempo real. Después de enviar el primer mensaje a un proyecto, informa al usuario de que puede ver sus pantallas siendo diseñadas en vivo en Sleek, y comparte el enlace del editor: https://sleek.design/project/:projectId. No abras un navegador tú mismo a menos que el usuario lo pida.

Sondeo: los mensajes de chat son asíncronos por defecto: obtienes un runId y sondeas GET /api/v1/projects/:id/chat/runs/:runId. Comienza con intervalo de 2s, retrocede a 5s después de 10s, abandona después de 5 minutos. Sale en completed o failed; si no puedes leer el estado, detente e infórmalo en lugar de contarlo como "aún no terminado". También puedes usar ?wait=true para una llamada bloqueante (hasta 300s; retrocede al sondeo si se agota el tiempo con 202).

Editando una pantalla específica: usa target.screenId para dirigir los cambios a la pantalla correcta. El screenId proviene de result.operations de la ejecución o del campo screenId en cada componente devuelto por GET /api/v1/projects/:id/components; no es el ID del componente.

Una ejecución a la vez: solo se permite una ejecución activa por proyecto. Si obtienes 409 CONFLICT, espera a que la ejecución actual termine antes de enviar el siguiente mensaje. Si el usuario cambió de opinión o una ejecución obsoleta está bloqueando el proyecto, cancélala (ver Cancelar ejecución). Los mensajes a diferentes proyectos pueden ejecutarse en paralelo; usa sondeo asíncrono (no ?wait=true) cuando ejecutes múltiples proyectos concurrentemente.

Reintentos seguros: agrega un encabezado idempotency-key (≤255 caracteres) para reenvíos seguros contra reproducciones. El servidor devuelve la ejecución existente en lugar de crear un duplicado.

3. Mostrar los resultados

Después de cada ejecución de chat que produzca operaciones screen_created o screen_updated, toma capturas de pantalla y muéstraselas al usuario usando POST /api/v1/screenshots. El paso está completo solo cuando el usuario ha visto una captura de pantalla de cada pantalla que la ejecución creó o actualizó; nunca completes una ejecución en silencio.

Nuevas pantallas: una captura de pantalla por pantalla + una captura combinada de todas las pantallas en el proyecto.
Pantallas actualizadas: una captura de pantalla por pantalla afectada.

Usa background: "transparent" a menos que el usuario solicite explícitamente un color de fondo específico.

Guarda las capturas de pantalla en el directorio del proyecto (no en una carpeta temporal) para que el usuario pueda verlas fácilmente.

Mostrar vs revisar: los valores predeterminados capturan solo el viewport, que es el encuadre correcto para el usuario: las pantallas se ven como pantallas de teléfono. Son el encuadre incorrecto para juzgar tu propio trabajo, porque todo lo que está debajo del pliegue se recorta. Cuando estés revisando lo que produjo una ejecución, vuelve a tomar la pantalla con fullHeight: true (una pantalla por solicitud) para ver toda la página desplazable.

Las solicitudes de captura de pantalla son independientes, así que emítelas en paralelo: la toma orientada al usuario y tu toma de revisión fullHeight salen juntas, al igual que las tomas para diferentes pantallas. "Una pantalla por solicitud" rige lo que entra en cada imagen, no la velocidad a la que las envías; no es una razón para esperar a una respuesta antes de comenzar la siguiente. Retrocede solo si realmente obtienes un 429.

Nunca llames incompleta a una pantalla a partir de una captura de viewport. El contenido que parece faltante casi siempre está justo debajo del pliegue. Antes de decirle al usuario que algo está ausente, o enviar un mensaje de seguimiento pidiendo a Sleek que lo agregue, confírmalo contra la pantalla completa: una captura fullHeight: true, o el código HTML del componente de GET /api/v1/projects/:id/components/:componentId, que es la verdad fundamental de lo que hay en la pantalla. La captura de pantalla es el valor predeterminado y responde la mayoría de las preguntas de revisión por sí sola; no vayas al código para verificar algo que ya muestra. Recurre al código solo cuando estés a punto de afirmar que algo falta: un render puede omitir lo que realmente está allí (más allá del límite de altura, en una sección colapsada, en una diapositiva posterior de un carrusel), por lo que una conclusión negativa es la que vale una segunda fuente. Ten en cuenta también lo inverso: un elemento presente en el HTML puede no ser visible para el usuario.

Implementando Diseños

Cuando el usuario quiera implementar los diseños en código (no solo previsualizarlos), siempre obtén el código HTML del componente. No te bases solo en las capturas de pantalla.

Usa GET /api/v1/projects/:id/components/:componentId para obtener el código de cada pantalla. El componentId proviene de result.operations de la ejecución del chat.

El código del componente puede ser grande. Al guardarlo en archivos, evita escribir el contenido a través de tu salida de texto: es lento y desperdicia tokens. En su lugar, usa comandos de shell para obtener la respuesta de la API y escribirla directamente en el disco (por ejemplo, canaliza el cuerpo de la respuesta a un archivo).

Qué versión usar

Cada componente lleva un array versions[] y un activeVersion: number. Por defecto, usa la entrada donde versions[i].version === activeVersion: ese es el código que se muestra actualmente en Sleek.

Si el mensaje del usuario fija versiones específicas, sigue esas en su lugar (ver Versiones fijadas a continuación).

Versiones fijadas

El mensaje del usuario puede incluir un bloque de fijación que te indique implementar versiones históricas específicas en lugar de las actuales, como esto:

... en este estado exacto en lugar de la versión actual del proyecto:
- componente cmp_abc: versión ver_001
- componente cmp_def: versión ver_002
- tema thm_ghi: versión ver_003

Cuando veas un bloque de fijación, implementa esas versiones exactas en lugar de activeVersion. Los componentes no nombrados en el bloque de fijación continúan usando su versión activa. Los IDs de los temas aparecen solo dentro de los bloques de fijación; esta habilidad no expone un endpoint separado para enumerarlos.

Obteniendo el código correcto

Para cada componente fijado, encuentra la entrada en versions[] donde versions[i].id coincide con el id de versión dado (por ejemplo, ver_001) y usa su code. No recurras a activeVersion para los componentes fijados.

Capturas de pantalla de versiones fijadas

Pasa componentVersionOverrides y themeVersionOverrides a POST /api/v1/screenshots:

{
  "componentIds": ["cmp_abc"],
  "projectId": "proj_xyz",
  "componentVersionOverrides": { "cmp_abc": "ver_001" },
  "themeVersionOverrides": { "thm_ghi": "ver_003" }
}

Las claves son ids públicos de componente/tema; los valores son los versions[i].id correspondientes. Las entidades faltantes en un mapa recurren a su versión activa. Incluye los mapas de anulación siempre que el mensaje haya especificado versiones fijadas.

Prototipos HTML

El code del componente es un documento HTML completo. Guárdalo directamente en un archivo .html. No se necesita paso de compilación.

Frameworks nativos (React Native, SwiftUI, etc.)

Usa tanto el código HTML como las capturas de pantalla juntos:

Código HTML es la referencia de implementación: contiene la estructura exacta, diseño, estilo, colores, espaciado, contenido, URLs de imágenes y nombres de iconos.
Capturas de pantalla son el objetivo visual: úsalas para verificar que tu implementación coincida con el aspecto deseado.

El HTML te dice cómo construirlo; la captura de pantalla te dice cómo debería verse.

Iconos

Sleek usa iconos de Iconify en el formato prefijo:nombre (por ejemplo, solar:heart-bold, material-symbols:search-rounded, lucide:settings). Los conjuntos más comunes son Solar, Hugeicons, Material Symbols y MDI.

Usa los iconos exactos del código HTML. No los sustituyas con un conjunto de iconos diferente.

diseñar-aplicaciones-moviles

¿Qué es diseñar-aplicaciones-moviles?

Preguntar en tu IA favorita

Vista previa

Documentación