design-mobile-apps

Concevoir avec Sleek

Aperçu

sleek.design est un outil de conception d'applications mobiles alimenté par l'IA. Vous interagissez avec lui via une API REST à /api/v1/* pour créer des projets, décrire ce que vous voulez construire en langage naturel, et obtenir des écrans rendus. Toute communication est en HTTP standard avec authentification par jeton.

URL de base : https://sleek.design Auth : Authorization: Bearer $SLEEK_API_KEY sur chaque requête /api/v1/* Content-Type : application/json (requêtes et réponses) CORS : Activé sur tous les points de terminaison /api/v1/* Analyse des réponses : écrire le corps dans un fichier (curl -o run.json) et analyser le fichier. Ne transmettez pas JSON via echo : dans zsh, il développe les \n échappés à l'intérieur des valeurs de chaîne en nouvelles lignes réelles, ce qui rend le corps du JSON invalide. Documentation API : Spécification OpenAPI à https://sleek.design/api/v1/spec.json ; documentation consultable à https://sleek.design/api/v1/docs. Récupérez la spécification pour tout détail de contrat non couvert ici.

---

Prérequis : Clé API

Si SLEEK_API_KEY n'est pas défini, utilisez le flux d'appareil pour que l'utilisateur ne manipule jamais la clé brute :

1. POST https://sleek.design/api/v1/device/start (sans authentification) avec le corps {"source": "votre-slug-d-outil"}. La réponse contient une verificationUrl, un userCode vérifiable par un humain, un deviceCode secret et un interval de sondage en secondes.
2. Montrez à l'utilisateur la verificationUrl et le userCode, et demandez-lui de confirmer que le code correspond avant d'approuver.
3. Sondez POST https://sleek.design/api/v1/device/poll avec {"deviceCode": "..."} toutes les interval secondes. Lorsque l'utilisateur approuve, le sondage renvoie exactement une fois {"status": "approved", "key": "sk_..."} : stockez-la comme SLEEP_API_KEY. Les codes expirent après 15 minutes ; en cas d'expiration, recommencez.

Alternative : envoyez l'utilisateur sur https://sleek.design/agents/setup, qui gère la connexion, la mise à niveau de plan et la création de clé en un seul endroit, et demandez-lui de vous coller la clé. Les clés peuvent également être gérées sur https://sleek.design/dashboard/api-keys. La valeur complète de la clé n'est affichée qu'une seule fois lors de la création.

Plans : les comptes gratuits peuvent essayer l'API avec leurs crédits d'essai uniques (environ une exécution de conception), donc un nouvel utilisateur peut voir sa première conception avant toute décision de paiement. Une utilisation soutenue nécessite le plan Pro ou supérieur (49,99 $/mois, ou 30 $/mois facturé annuellement à 360 $/an ; inclut 20 000 crédits IA mensuels, soit environ 650 écrans). Lorsque le coût devient pertinent (l'utilisateur demande, une mise à niveau est nécessaire pour continuer, ou vous êtes sur le point de l'envoyer vers une page de paiement), indiquez clairement ces prix, y compris l'option annuelle. Ne laissez jamais une étape de paiement surprendre.

Scopes de la clé

Scope	Ce qu'il déverrouille
projects:read	Lister / obtenir des projets
projects:write	Créer / supprimer des projets
components:read	Lister les composants d'un projet
chats:read	Obtenir le statut d'exécution du chat
chats:write	Envoyer des messages de chat
screenshots	Rendre des captures d'écran de composants

Créez une clé avec uniquement les scopes nécessaires pour la tâche.

---

Sécurité et confidentialité

• Hôte unique : Toutes les requêtes vont exclusivement à https://sleek.design. Aucune donnée n'est envoyée à des tiers.
• HTTPS uniquement : Toute communication utilise HTTPS. La clé API n'est transmise que dans l'en-tête Authorization aux points de terminaison Sleek.
• Scopes minimaux : Créez des clés API avec uniquement les scopes requis pour la tâche. Préférez les clés à durée de vie courte ou révocables.
• URLs d'images : Lorsque vous utilisez imageUrls dans les messages de chat, ces URLs sont récupérées par les serveurs Sleek. Évitez de passer des URLs contenant du contenu sensible.

---

Conception

Les formes complètes des requêtes/réponses pour chaque point de terminaison utilisé ci-dessous se trouvent dans la référence API.

1. Créer un projet

Créez un projet avec POST /api/v1/projects si aucun n'existe. Dérivez un nom de la demande.

Chaque projet a son propre thème, style et système de conception. Si l'utilisateur souhaite plusieurs variations de conception, créez un projet séparé pour chaque variation.

2. Envoyer un message de chat

Envoyez la requête avec POST /api/v1/projects/:id/chat/messages. Sleek planifie le contenu et la mise en page de l'écran à partir de votre message, et inventera un style visuel si vous n'en donnez pas. Ne décomposez pas la requête en écrans et n'ajoutez pas de détails de produit que l'utilisateur n'a pas demandés ; envoyez l'intention complète en un seul message. Si l'utilisateur a décrit des écrans spécifiques, incluez-les. Sleek produit des conceptions plus riches lorsqu'on lui donne de la place pour planifier.

Rédigez une direction de style : faites-le chaque fois que l'utilisateur vous a donné quelque chose pour la fonder — images de référence, applications qu'il aime, adjectifs d'ambiance, choses à éviter — ou lorsque vous produisez des variations, une direction par variation. Ne transmettez la requête inchangée que lorsqu'elle est nue. Une direction de style est un seul paragraphe complet, inclus dans le message, couvrant l'ambiance (2–3 adjectifs), la stratégie de couleur (la logique, pas les codes hexadécimaux), le ressenti typographique, la philosophie de mise en page, le style des composants (rayons, bordures vs ombres, traitement de la navigation), le style des images et illustrations, et un ou deux détails distinctifs. Engagez-vous sur une palette, une direction typographique et un ressenti global — tout ce qui ne fait que poser une ambiance est perçu comme une suggestion, pas une direction. Soyez tranché ; ne balancez pas. Mettez la personnalité dans la couleur, la typographie et l'imagerie plutôt que dans une mise en page ou une navigation inhabituelles.

Étendez ce que l'utilisateur vous a donné et ne le contredisez jamais. Lorsqu'il pointe vers des images de référence ou des applications qu'il aime, étudiez chacune et intégrez ce que vous prenez dans la direction — Sleek ne voit les images que si elles sont passées comme imageUrls, donc pour tout ce qui est local, la direction est la façon dont ces références l'atteignent. Empruntez des motifs, jamais la marque, le contenu ou le nom de la source.

Utilisez une direction de style ou un referenceId, pas les deux — une référence porte déjà son propre guide de style complet.

Initialisez un style avec une référence : Sleek conserve un catalogue de références de conception. Lorsque l'utilisateur souhaite un look spécifique ou demande des options de style, listez-les avec GET /api/v1/references (chacune a un name et previewImageUrls que vous pouvez montrer) et passez l'id choisi comme referenceId sur le premier message à un projet, afin que son guide de style sème toute la conception.

Identifiez votre outil : envoyez toujours source, le slug de l'outil faisant la requête. L'éditeur Sleek l'utilise pour montrer à l'utilisateur qui conçoit pendant que l'exécution se déroule. Valeurs reconnues : claude-code, claude, codex, chatgpt, cursor, openclaw, grok. Si votre outil n'est pas listé, envoyez un slug court en kebab-case pour lui quand même (max 64 caractères). Les valeurs non reconnues sont acceptables et reçoivent un libellé générique.

Regardez en direct : les exécutions se rendent en temps réel dans l'éditeur Sleek. Après avoir envoyé le premier message à un projet, dites à l'utilisateur qu'il peut regarder ses écrans être conçus en direct dans Sleek, et partagez le lien de l'éditeur : https://sleek.design/project/:projectId. N'ouvrez pas vous-même un navigateur sauf si l'utilisateur le demande.

Sondage : les messages de chat sont asynchrones par défaut : vous obtenez un runId et sondez GET /api/v1/projects/:id/chat/runs/:runId. Commencez à un intervalle de 2 s, passez à 5 s après 10 s, abandonnez après 5 minutes. Quittez sur completed ou failed ; si vous ne pouvez pas lire le statut, arrêtez-vous et signalez-le plutôt que de le compter comme "pas encore terminé". Vous pouvez également utiliser ?wait=true pour un appel bloquant (jusqu'à 300 s ; revient au sondage s'il expire avec 202).

Modifier un écran spécifique : utilisez target.screenId pour diriger les modifications vers le bon écran. Le screenId provient de result.operations de l'exécution ou du champ screenId de chaque composant renvoyé par GET /api/v1/projects/:id/components ; ce n'est pas l'ID du composant.

Une exécution à la fois : une seule exécution active est autorisée par projet. Si vous obtenez 409 CONFLICT, attendez la fin de l'exécution en cours avant d'envoyer le message suivant. Si l'utilisateur a changé d'avis ou qu'une exécution obsolète bloque le projet, annulez-la (voir Annuler l'exécution). Les messages vers différents projets peuvent s'exécuter en parallèle ; utilisez le sondage asynchrone (pas ?wait=true) lorsque vous exécutez plusieurs projets simultanément.

Réessais sécurisés : ajoutez un en-tête idempotency-key (≤255 caractères) pour les renvois sécurisés contre les doublons. Le serveur renvoie l'exécution existante plutôt que d'en créer une en double.

3. Afficher les résultats

Après chaque exécution de chat qui produit des opérations screen_created ou screen_updated, prenez des captures d'écran et montrez-les à l'utilisateur en utilisant POST /api/v1/screenshots. L'étape n'est terminée que lorsque l'utilisateur a vu une capture d'écran de chaque écran que l'exécution a créé ou mis à jour ; ne terminez jamais une exécution en silence.

• Nouveaux écrans : une capture d'écran par écran + une capture d'écran combinée de tous les écrans du projet.
• Écrans mis à jour : une capture d'écran par écran affecté.

Utilisez background: "transparent" sauf si l'utilisateur demande explicitement une couleur de fond spécifique.

Enregistrez les captures d'écran dans le répertoire du projet (pas un dossier temporaire) afin que l'utilisateur puisse facilement les visualiser.

Montrer vs réviser : les paramètres par défaut ne capturent que la zone visible, ce qui est le bon cadrage pour l'utilisateur — les écrans ressemblent à des écrans de téléphone. Ce sont les mauvais cadrages pour juger votre propre travail, car tout ce qui est en dessous du pli est rogné. Lorsque vous révisez ce qu'une exécution a produit, reprenez la capture d'écran avec fullHeight: true (un écran par requête) pour voir toute la page défilable.

Les requêtes de capture d'écran sont indépendantes, donc émettez-les en parallèle — la capture destinée à l'utilisateur et votre capture de révision fullHeight partent ensemble, de même que les captures pour différents écrans. "Un écran par requête" régit ce qui va dans chaque image, pas la rapidité avec laquelle vous les envoyez ; ce n'est pas une raison pour attendre une réponse avant de commencer la suivante. N'attendez que si vous obtenez effectivement un 429.

Ne qualifiez jamais un écran d'incomplet à partir d'une capture d'écran de la zone visible. Un contenu qui semble manquant est presque toujours juste en dessous du pli. Avant de dire à l'utilisateur que quelque chose est absent, ou d'envoyer un message de suivi demandant à Sleek de l'ajouter, confirmez-le par rapport à l'écran entier : une capture d'écran avec fullHeight: true, ou le HTML du composant de GET /api/v1/projects/:id/components/:componentId, qui est la vérité fondamentale de ce qui est sur l'écran. La capture d'écran est la valeur par défaut et répond à la plupart des questions de révision par elle-même — n'allez pas dans le code pour revérifier ce qu'elle montre déjà. N'utilisez le code que lorsque vous êtes sur le point d'affirmer que quelque chose manque : un rendu peut omettre ce qui est vraiment là (au-delà de la limite de hauteur, dans une section repliée, sur une diapositive de carrousel ultérieure), donc une conclusion négative mérite une seconde source. Notez également l'inverse — un élément présent dans le HTML peut ne pas être visible pour l'utilisateur.

---

Implémenter des conceptions

Lorsque l'utilisateur souhaite implémenter les conceptions en code (pas seulement les prévisualiser), récupérez toujours le code HTML du composant. Ne vous fiez pas uniquement aux captures d'écran.

Utilisez GET /api/v1/projects/:id/components/:componentId pour récupérer le code de chaque écran. Le componentId provient de result.operations de l'exécution du chat.

Le code des composants peut être volumineux. Lorsque vous l'enregistrez dans des fichiers, évitez d'écrire le contenu via votre sortie texte : c'est lent et gaspille des tokens. Utilisez plutôt des commandes shell pour récupérer la réponse de l'API et l'écrire directement sur le disque (par exemple, redirigez le corps de la réponse dans un fichier).

Quelle version utiliser

Chaque composant porte un tableau versions[] et un activeVersion: number. Par défaut, utilisez l'entrée où versions[i].version === activeVersion : c'est le code actuellement affiché dans Sleek.

Si l'invite de l'utilisateur épinglé des versions spécifiques, suivez-les à la place (voir Versions épinglées ci-dessous).

Versions épinglées

L'invite de l'utilisateur peut inclure un bloc d'épinglage vous demandant d'implémenter des versions historiques spécifiques au lieu des versions actuelles, comme ceci :

... dans cet état exact au lieu de la version actuelle du projet :
- composant cmp_abc : version ver_001
- composant cmp_def : version ver_002
- thème thm_ghi : version ver_003

Lorsque vous voyez un bloc d'épinglage, implémentez ces versions exactes au lieu de activeVersion. Les composants non nommés dans le bloc d'épinglage continuent d'utiliser leur version active. Les ID de thème n'apparaissent que dans les blocs d'épinglage ; cette compétence n'expose pas de point de terminaison séparé pour les énumérer.

Récupérer le bon code

Pour chaque composant épinglé, trouvez l'entrée dans versions[] où versions[i].id correspond à l'ID de version donné (par exemple ver_001) et utilisez son code. Ne repliez pas sur activeVersion pour les composants épinglés.

Captures d'écran des versions épinglées

Passez componentVersionOverrides et themeVersionOverrides à POST /api/v1/screenshots :

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

Les clés sont les ID publics du composant / thème ; les valeurs sont les versions[i].id correspondants. Les entités manquantes dans une carte reviennent à leur version active. Incluez les cartes de dérogation chaque fois que l'invite spécifiait des versions épinglées.

Prototypes HTML

Le code du composant est un document HTML complet. Enregistrez-le directement dans un fichier .html. Aucune étape de construction nécessaire.

Frameworks natifs (React Native, SwiftUI, etc.)

Utilisez ensemble le code HTML et les captures d'écran :

• Le code HTML est la référence d'implémentation : il contient la structure exacte, la mise en page, le style, les couleurs, les espacements, le contenu, les URLs d'images et les noms d'icônes.
• Les captures d'écran sont la cible visuelle : utilisez-les pour vérifier que votre implémentation correspond à l'aspect attendu.

Le HTML vous dit comment construire ; la capture d'écran vous dit à quoi cela devrait ressembler.

Icônes

Sleek utilise des icônes Iconify au format prefix:name (par exemple, solar:heart-bold, material-symbols:search-rounded, lucide:settings). Les ensembles les plus courants sont Solar, Hugeicons, Material Symbols et MDI.

Utilisez les icônes exactes du code HTML. Ne les remplacez pas par un autre ensemble d'icônes. Faire correspondre l'icône...