Projetando com Sleek

Visão Geral

sleek.design é uma ferramenta de design de aplicativos móveis com tecnologia de IA. Você interage com ela por meio de uma API REST em /api/v1/* para criar projetos, descrever o que deseja construir em linguagem simples e obter telas renderizadas. Toda a comunicação é HTTP padrão com autenticação via token bearer.

URL Base: https://sleek.design Autenticação: Authorization: Bearer $SLEEK_API_KEY em toda requisição /api/v1/* Content-Type: application/json (requisições e respostas) CORS: Habilitado em todos os endpoints /api/v1/* Análise de respostas: grave o corpo em um arquivo (curl -o run.json) e analise o arquivo. Não direcione o JSON via echo: no zsh, isso expande os \n escapados dentro dos valores de string em novas linhas reais, o que torna o corpo JSON inválido. Documentação da API: Especificação OpenAPI em https://sleek.design/api/v1/spec.json; documentação navegável em https://sleek.design/api/v1/docs. Consulte a especificação para qualquer detalhe de contrato não abordado aqui.

Pré-requisitos: Chave de API

Se SLEEK_API_KEY não estiver definida, use o fluxo de dispositivo para que o usuário nunca manipule a chave bruta:

POST https://sleek.design/api/v1/device/start (sem autenticação) com corpo {"source": "your-tool-slug"}. A resposta contém um verificationUrl, um userCode verificável por humanos, um deviceCode secreto e um intervalo de interval em segundos.
Mostre ao usuário o verificationUrl e o userCode, e diga a ele para confirmar se o código corresponde antes de aprovar.
Consulte POST https://sleek.design/api/v1/device/poll com {"deviceCode": "..."} a cada interval segundos. Quando o usuário aprovar, a consulta retorna {"status": "approved", "key": "sk_..."} exatamente uma vez: armazene-o como SLEEP_API_KEY. Os códigos expiram após 15 minutos; em caso de expired, recomece.

Alternativa: envie o usuário para https://sleek.design/agents/setup, que lida com login, upgrade de plano e criação de chave em um só lugar, e peça para ele colar a chave de volta para você. As chaves também podem ser gerenciadas em https://sleek.design/dashboard/api-keys. O valor completo da chave é mostrado apenas uma vez na criação.

Planos: contas gratuitas podem testar a API com seus créditos de teste únicos (cerca de uma execução de design), para que um novo usuário possa ver seu primeiro design antes de qualquer decisão de pagamento. O uso contínuo requer o plano Pro ou superior (US$ 49,99/mês, ou US$ 30/mês cobrados anualmente a US$ 360/ano; inclui 20.000 créditos de IA mensais, aproximadamente 650 telas). Quando o custo se tornar relevante (o usuário perguntar, um upgrade for necessário para continuar ou você estiver prestes a enviá-lo para uma página de pagamento), declare este preço claramente, incluindo a opção anual. Nunca deixe uma etapa de pagamento ser uma surpresa.

Escopos da chave

Escopo	O que desbloqueia
`projects:read`	Listar / obter projetos
`projects:write`	Criar / excluir projetos
`components:read`	Listar componentes em um projeto
`chats:read`	Obter status de execução do chat
`chats:write`	Enviar mensagens de chat
`screenshots`	Renderizar capturas de tela de componentes

Crie uma chave apenas com os escopos necessários para a tarefa.

Segurança e Privacidade

Host único: Todas as requisições vão exclusivamente para https://sleek.design. Nenhum dado é enviado a terceiros.
HTTPS apenas: Toda a comunicação usa HTTPS. A chave de API é transmitida apenas no cabeçalho Authorization para os endpoints do Sleek.
Escopos mínimos: Crie chaves de API apenas com os escopos necessários para a tarefa. Prefira chaves de curta duração ou revogáveis.
URLs de imagem: Ao usar imageUrls em mensagens de chat, essas URLs são buscadas pelos servidores do Sleek. Evite passar URLs que contenham conteúdo sensível.

Projetando

As formas completas de requisição/resposta para cada endpoint usado abaixo estão na referência da API.

1. Criar um projeto

Crie um projeto com POST /api/v1/projects se ainda não existir um. Derive um nome da requisição.

Cada projeto tem seu próprio tema, estilo e sistema de design. Se o usuário quiser múltiplas variações de design, crie um projeto separado para cada variação.

2. Enviar uma mensagem de chat

Envie a requisição com POST /api/v1/projects/:id/chat/messages. O Sleek planeja o conteúdo e layout da tela a partir da sua mensagem e inventará um estilo visual se você não fornecer um. Não decomponha a requisição em telas e não adicione detalhes de produto que o usuário não pediu; envie a intenção completa como uma única mensagem. Se o usuário descreveu telas específicas, inclua-as. O Sleek produz designs mais ricos quando tem espaço para planejar.

Crie uma direção de estilo: escreva uma sempre que o usuário tiver fornecido algo para fundamentá-la — imagens de referência, aplicativos que eles gostam, adjetivos de ambiente, coisas a evitar — ou sempre que estiver produzindo variações, uma direção por variação. Passe a requisição sem alterações apenas quando ela estiver nua. Uma direção de estilo é um único parágrafo abrangente, incluído na mensagem, cobrindo humor (2-3 adjetivos), estratégia de cores (a lógica, não códigos hexadecimais), sensação tipográfica, filosofia de layout, estilo de componentes (raios, bordas vs sombras, tratamento de navegação), estilo de imagens e ilustrações, e um ou dois detalhes distintivos. Comprometa-se com uma paleta, uma direção de tipo e uma sensação geral — qualquer coisa que apenas define um humor é lida como uma dica, não uma direção. Seja opinativo; não tergiverse. Coloque a personalidade em cor, tipo e imagens, em vez de em layout ou navegação incomuns.

Estenda o que o usuário forneceu e nunca o contradiga. Quando eles apontarem para imagens de referência ou aplicativos de que gostam, estude cada um e carregue o que você captar na direção — o Sleek vê apenas imagens passadas como imageUrls, então, para qualquer coisa local, a direção é como essas referências o alcançam. Pegue emprestado padrões, nunca a marca, conteúdo ou nome da fonte.

Use uma direção de estilo ou um referenceId, não ambos — uma referência já carrega um guia de estilo completo próprio.

Semeie um estilo com uma referência: o Sleek seleciona um catálogo de referências de design. Quando o usuário quiser um visual específico ou pedir opções de estilo, liste-as com GET /api/v1/references (cada uma tem um name e previewImageUrls que você pode mostrar) e passe o id escolhido como referenceId na primeira mensagem para um projeto, para que seu guia de estilo semeie todo o design.

Identifique sua ferramenta: sempre envie source, o slug da ferramenta que está fazendo a requisição. O editor do Sleek o usa para mostrar ao usuário quem está projetando enquanto a execução é transmitida. Valores reconhecidos: claude-code, claude, codex, chatgpt, cursor, openclaw, grok. Se sua ferramenta não estiver listada, envie um slug curto em kebab-case para ela de qualquer forma (máx. 64 caracteres). Valores não reconhecidos são aceitos e recebem um rótulo genérico.

Assista ao vivo: as execuções são renderizadas no editor do Sleek em tempo real. Após enviar a primeira mensagem para um projeto, informe ao usuário que ele pode assistir suas telas sendo projetadas ao vivo no Sleek e compartilhe o link do editor: https://sleek.design/project/:projectId. Não abra um navegador você mesmo, a menos que o usuário peça.

Consulta: as mensagens de chat são assíncronas por padrão: você recebe um runId e consulta GET /api/v1/projects/:id/chat/runs/:runId. Comece com intervalo de 2s, reduza para 5s após 10s, desista após 5 minutos. Saia em completed ou failed; se não conseguir ler o status, pare e relate-o em vez de contar como "ainda não concluído". Você também pode usar ?wait=true para uma chamada bloqueante (até 300s; volta para consulta se expirar com 202).

Editando uma tela específica: use target.screenId para direcionar alterações à tela correta. O screenId vem do result.operations da execução ou do campo screenId em cada componente retornado por GET /api/v1/projects/:id/components; não é o ID do componente.

Uma execução por vez: apenas uma execução ativa é permitida por projeto. Se você receber 409 CONFLICT, aguarde a conclusão da execução atual antes de enviar a próxima mensagem. Se o usuário mudou de ideia ou uma execução obsoleta está bloqueando o projeto, cancele-a (veja Cancelar Execução). Mensagens para projetos diferentes podem ser executadas em paralelo; use consulta assíncrona (não ?wait=true) ao executar vários projetos simultaneamente.

Tentativas seguras: adicione um cabeçalho idempotency-key (≤255 caracteres) para reenvios seguros. O servidor retorna a execução existente em vez de criar uma duplicata.

3. Mostrar os resultados

Após cada execução de chat que produz operações screen_created ou screen_updated, capture as telas e mostre-as ao usuário usando POST /api/v1/screenshots. A etapa só é concluída quando o usuário tiver visto uma captura de tela de cada tela que a execução criou ou atualizou; nunca conclua uma execução silenciosamente.

Novas telas: uma captura de tela por tela + uma captura de tela combinada de todas as telas no projeto.
Telas atualizadas: uma captura de tela por tela afetada.

Use background: "transparent" a menos que o usuário solicite explicitamente uma cor de fundo específica.

Salve as capturas de tela no diretório do projeto (não em uma pasta temporária) para que o usuário possa visualizá-las facilmente.

Mostrar vs revisar: os padrões capturam apenas a viewport, que é o enquadramento correto para o usuário — as telas parecem telas de telefone. Eles são o enquadramento errado para julgar seu próprio trabalho, porque tudo abaixo da dobra é cortado. Ao revisar o que uma execução produziu, recapture a tela com fullHeight: true (uma tela por requisição) para ver toda a página rolável.

As requisições de captura de tela são independentes, portanto, emita-as em paralelo — a captura voltada para o usuário e sua captura de revisão fullHeight saem juntas, assim como as capturas para telas diferentes. "Uma tela por requisição" rege o que vai em cada imagem, não a rapidez com que você as envia; não é motivo para esperar uma resposta antes de iniciar a próxima. Reduza a velocidade apenas se você realmente receber um 429.

Nunca chame uma tela de incompleta a partir de uma captura de viewport. O conteúdo que parece faltar quase sempre está abaixo da dobra. Antes de dizer ao usuário que algo está ausente, ou enviar uma mensagem de acompanhamento pedindo ao Sleek para adicioná-lo, confirme na tela inteira: uma captura de tela com fullHeight: true, ou o HTML do componente de GET /api/v1/projects/:id/components/:componentId, que é a verdade fundamental do que está na tela. A captura de tela é o padrão e responde à maioria das perguntas de revisão por si só — não vá ao código para verificar algo que ela já mostra. Recorra ao código apenas quando estiver prestes a afirmar que algo está faltando: uma renderização pode omitir o que realmente está lá (além do limite de altura, em uma seção recolhida, em um slide de carrossel posterior), então uma conclusão negativa é a que merece uma segunda fonte. Observe também o inverso — um elemento presente no HTML pode ainda não estar visível para o usuário.

Implementando Designs

Quando o usuário quiser implementar os designs em código (não apenas visualizá-los), sempre busque o código HTML do componente. Não confie apenas em capturas de tela.

Use GET /api/v1/projects/:id/components/:componentId para buscar o código de cada tela. O componentId vem do result.operations da execução do chat.

O código do componente pode ser grande. Ao salvá-lo em arquivos, evite escrever o conteúdo através da sua saída de texto: é lento e desperdiça tokens. Em vez disso, use comandos shell para buscar a resposta da API e escrevê-la diretamente no disco (por exemplo, direcione o corpo da resposta para um arquivo).

Qual versão usar

Cada componente carrega um array versions[] e um activeVersion: number. Por padrão, use a entrada onde versions[i].version === activeVersion: esse é o código atualmente mostrado no Sleek.

Se a solicitação do usuário fixar versões específicas, siga-as (veja Versões fixadas abaixo).

Versões fixadas

A solicitação do usuário pode incluir um bloco de fixação dizendo para implementar versões históricas específicas em vez das atuais, como este:

... neste estado exato, em vez da versão atual do projeto:
- componente cmp_abc: versão ver_001
- componente cmp_def: versão ver_002
- tema thm_ghi: versão ver_003

Quando você vir um bloco de fixação, implemente essas versões exatas em vez de activeVersion. Os componentes não nomeados no bloco de fixação continuam usando sua versão ativa. Os IDs de tema aparecem apenas dentro de blocos de fixação; esta skill não expõe um endpoint separado para enumerá-los.

Buscando o código correto

Para cada componente fixado, encontre a entrada em versions[] onde versions[i].id corresponde ao ID de versão fornecido (por exemplo, ver_001) e use seu code. Não recorra a activeVersion para componentes fixados.

Capturas de tela de versões fixadas

Passe componentVersionOverrides e themeVersionOverrides para POST /api/v1/screenshots:

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

As chaves são IDs públicos de componente / tema; os valores são os versions[i].id correspondentes. As entidades ausentes de um mapa recorrem à sua versão ativa. Inclua os mapas de substituição sempre que a solicitação especificar versões fixadas.

Protótipos HTML

O code do componente é um documento HTML completo. Salve-o diretamente em um arquivo .html. Nenhuma etapa de compilação necessária.

Frameworks nativos (React Native, SwiftUI, etc.)

Use o código HTML e as capturas de tela juntos:

Código HTML é a referência de implementação: contém a estrutura exata, layout, estilo, cores, espaçamento, conteúdo, URLs de imagem e nomes de ícones.
Capturas de tela são o alvo visual: use-as para verificar se sua implementação corresponde à aparência pretendida.

O HTML diz como construir; a captura de tela diz como deve parecer.

Ícones

O Sleek usa ícones do Iconify no formato prefixo:nome (por exemplo, solar:heart-bold, material-symbols:search-rounded, lucide:settings). Os conjuntos mais comuns são Solar, Hugeicons, Material Symbols e MDI.

Use os ícones exatos do código HTML. Não substitua por um conjunto de ícones diferente. Corresponder ícones de forma aproximada quebra o design. Encontre os ícones exatos nas bibliotecas de ícones e mapeie-os para a sintaxe correta do framework de destino.

Implementações de componentes

Quando a execução retorna múltiplas operações component_created, cada uma com seu próprio componentId, siga estas regras:

Componentes de tela (component.type === "screen"): esses são componentes de tela completos. Eles são o foco principal. Crie um arquivo de implementação separado para cada um.
Componentes de elemento (component.type === "element"): esses são blocos de construção reutilizáveis que pertencem a um componente de tela. Extraia e implemente-os junto com o componente de tela pai, ou como arquivos separados, se apropriado.
Código de tema: o endpoint de componentes retorna um themecode no nível do projeto. Inclua cores, tipografia e tokens de design. Escreva-o em um arquivo de tema central que todos os componentes importam.

Dividir o tema e os componentes de tela/elemento em arquivos separados facilita a manutenção e a consistência.

Objetos de tema imutáveis no desenvolvimento nativo

Ao gerar um tema para React Native (ou qualquer outro framework nativo), considere cada token de design (cor, tipografia, espaço, raio) como imutável. Seu código gerado nunca deve embutir um hex ou um valor de espaço onde uma referência de token deveria estar. Use as constantes nomeadas do tema em todos os lugares.

A estrutura de tema do Sleek reflete a saída direta do designer: tokens planos, aninhados de forma rasa, nenhum operador. Cada variante (claro/escuro) é uma árvore de tokens autocontida. O código gerado deve espelhar isso.

Não adicione modos claro/escuro ou variantes a componentes individuais — o tema já os carrega. Apenas os consuma.

Não adicione recursos ausentes no design (por exemplo, Pressable quando o botão não tem um estado pressionado no tema). Se não houver um token para ele, não o invente.

Caminhos de recursos e pastas

Para cada componente de tela criado, crie uma subpasta dentro do diretório do projeto (por exemplo, projeto-x/tela-inicial). Coloque o arquivo de implementação e quaisquer submódulos ou subcomponentes dentro dela. Use caminhos relativos das subpastas para o arquivo de tema central.

Referência Rápida: Todos os Endpoints

Device Auth

Método	Caminho	Descrição
`POST`	`/api/v1/device/start`	Iniciar fluxo de dispositivo sem autenticação
`POST`	`/api/v1/device/poll`	Consultar status de aprovação

Projetos

Método	Caminho	Descrição
`POST`	`/api/v1/projects`	Criar um projeto
`GET`	`/api/v1/projects`	Listar projetos
`GET`	`/api/v1/projects/:id`	Obter detalhes do projeto
`DELETE`	`/api/v1/projects/:id`	Excluir um projeto

Componentes

Método	Caminho	Descrição
`GET`	`/api/v1/projects/:id/components`	Listar componentes de um projeto
`GET`	`/api/v1/projects/:id/components/:componentId`	Obter código e versões de um componente

Chat

Método	Caminho	Descrição
`POST`	`/api/v1/projects/:id/chat/messages`	Enviar uma mensagem de chat
`GET`	`/api/v1/projects/:id/chat/runs/:runId`	Consultar status de execução
`POST`	`/api/v1/projects/:id/chat/runs/:runId/cancel`	Cancelar execução em andamento

Capturas de Tela

Método	Caminho	Descrição
`POST`	`/api/v1/screenshots`	Gerar capturas de tela

Referências (Pesquisáveis)

Método	Caminho	Descrição
`GET`	`/api/v1/references`	Listar referências de design

Utilitários

Método	Caminho	Descrição
`GET`	`/api/v1/spec.json`	Especificação OpenAPI
`GET`	`/api/v1/docs`	Documentação navegável

Limpeza e Encerramento

Depois que o usuário confirmar que terminou com um projeto, pergunte se ele gostaria que você o excluísse. Se sim, use DELETE /api/v1/projects/:id. Se eles quiserem manter o projeto no Sleek para edição futura, deixe-o.

Nunca exclua um projeto sem confirmação explícita do usuário.

Se SLEEK_API_KEY foi criada apenas para esta sessão (por exemplo, por meio do fluxo de dispositivo ou colada para uma única execução), ofereça-se para revogá-la quando o trabalho estiver concluído. As chaves podem ser revogadas via https://sleek.design/dashboard/api-keys.

Perguntar na sua IA favorita

Prévia

Documentação