Entwerfen mit Sleek

Übersicht

sleek.design ist ein KI-gestütztes Tool zum Entwerfen mobiler Apps. Sie interagieren damit über eine REST-API unter /api/v1/*, um Projekte zu erstellen, das, was Sie bauen möchten, in einfacher Sprache zu beschreiben und gerenderte Bildschirme zu erhalten. Die gesamte Kommunikation erfolgt über Standard-HTTP mit Bearer-Token-Authentifizierung.

Basis-URL: https://sleek.design Authentifizierung: Authorization: Bearer $SLEEK_API_KEY bei jeder /api/v1/*-Anfrage Inhaltstyp: application/json (Anfragen und Antworten) CORS: Aktiviert für alle /api/v1/*-Endpunkte Antworten parsen: Schreiben Sie den Body in eine Datei (curl -o run.json) und parsen Sie die Datei. Leiten Sie JSON nicht durch echo: In zsh werden die escaped \n innerhalb von String-Werten in echte Zeilenumbrüche umgewandelt, wodurch der Body ungültiges JSON wird. API-Dokumentation: OpenAPI-Spezifikation unter https://sleek.design/api/v1/spec.json; browserbasierte Dokumentation unter https://sleek.design/api/v1/docs. Rufen Sie die Spezifikation für jedes Vertragsdetail ab, das hier nicht abgedeckt ist.

Voraussetzungen: API-Key

Wenn SLEEK_API_KEY nicht gesetzt ist, verwenden Sie den Device-Flow, damit der Benutzer den rohen Key nie direkt handhaben muss:

POST https://sleek.design/api/v1/device/start (keine Authentifizierung) mit Body {"source": "your-tool-slug"}. Die Antwort enthält eine verificationUrl, einen vom Menschen überprüfbaren userCode, einen geheimen deviceCode und ein Poll-interval in Sekunden.
Zeigen Sie dem Benutzer die verificationUrl und den userCode und sagen Sie ihm, er solle bestätigen, dass der Code übereinstimmt, bevor er zustimmt.
Führen Sie alle interval Sekunden einen Poll POST https://sleek.design/api/v1/device/poll mit {"deviceCode": "..."} durch. Wenn der Benutzer zustimmt, gibt der Poll genau einmal {"status": "approved", "key": "sk_..."} zurück: speichern Sie es als SLEEP_API_KEY. Codes laufen nach 15 Minuten ab; bei expired beginnen Sie von vorne.

Fallback: Senden Sie den Benutzer zu https://sleek.design/agents/setup, das Anmeldung, Plan-Upgrade und Key-Erstellung an einem Ort abwickelt, und bitten Sie ihn, den Key zurückzupasten. Keys können auch unter https://sleek.design/dashboard/api-keys verwaltet werden. Der vollständige Key-Wert wird nur bei der Erstellung einmal angezeigt.

Pläne: Kostenlose Konten können die API mit ihren einmaligen Testguthaben (etwa für einen Design-Durchlauf) ausprobieren, sodass ein neuer Benutzer sein erstes Design sehen kann, bevor er eine Zahlungsentscheidung trifft. Die dauerhafte Nutzung erfordert den Pro-Plan oder höher (49,99 $/Monat oder 30 $/Monat bei jährlicher Abrechnung mit 360 $/Jahr; beinhaltet 20.000 monatliche KI-Guthabenpunkte, etwa 650 Bildschirme). Wenn Kosten relevant werden (der Benutzer fragt, ein Upgrade ist erforderlich, um fortzufahren, oder Sie sind dabei, ihn auf eine Zahlungsseite zu schicken), geben Sie diese Preise klar an, einschließlich der Jahresoption. Lassen Sie einen Zahlungsschritt niemals überraschend kommen.

Key-Bereiche

Bereich	Wird freigeschaltet
`projects:read`	Projekte auflisten / abrufen
`projects:write`	Projekte erstellen / löschen
`components:read`	Komponenten in einem Projekt auflisten
`chats:read`	Chat-Run-Status abrufen
`chats:write`	Chat-Nachrichten senden
`screenshots`	Komponenten-Screenshots rendern

Erstellen Sie einen Key nur mit den Bereichen, die für die Aufgabe benötigt werden.

Sicherheit und Datenschutz

Einzelner Host: Alle Anfragen gehen ausschließlich an https://sleek.design. Es werden keine Daten an Dritte gesendet.
Nur HTTPS: Die gesamte Kommunikation verwendet HTTPS. Der API-Key wird nur im Authorization-Header an Sleek-Endpunkte übertragen.
Minimale Bereiche: Erstellen Sie API-Keys nur mit den Bereichen, die für die Aufgabe erforderlich sind. Bevorzugen Sie kurzlebige oder widerrufbare Keys.
Bild-URLs: Wenn Sie imageUrls in Chat-Nachrichten verwenden, werden diese URLs von Sleeks Servern abgerufen. Vermeiden Sie die Übergabe von URLs, die sensible Inhalte enthalten.

Entwerfen

Die vollständigen Anfrage-/Antwort-Formate für jeden der unten verwendeten Endpunkte finden Sie in der API-Referenz.

1. Ein Projekt erstellen

Erstellen Sie ein Projekt mit POST /api/v1/projects, falls noch keines existiert. Leiten Sie einen Namen aus der Anfrage ab.

Jedes Projekt hat sein eigenes Thema, seinen eigenen Stil und sein eigenes Designsystem. Wenn der Benutzer mehrere Design-Varianten wünscht, erstellen Sie für jede Variante ein separates Projekt.

2. Eine Chat-Nachricht senden

Senden Sie die Anfrage mit POST /api/v1/projects/:id/chat/messages. Sleek plant Bildschirminhalt und -layout aus Ihrer Nachricht und erfindet einen visuellen Stil, wenn Sie keinen vorgeben. Zerlegen Sie die Anfrage nicht in Bildschirme und fügen Sie keine Produktdetails hinzu, die der Benutzer nicht verlangt hat; senden Sie die gesamte Absicht als eine einzige Nachricht. Wenn der Benutzer bestimmte Bildschirme beschrieben hat, fügen Sie diese ein. Sleek produziert reichhaltigere Designs, wenn man ihm Raum zum Planen gibt.

Formulieren Sie eine Stilrichtung: Schreiben Sie eine, wann immer der Benutzer Ihnen etwas gegeben hat, auf das Sie sich stützen können — Referenzbilder, Apps, die ihnen gefallen, Stimmungs-Adjektive, Dinge, die vermieden werden sollen — oder wann immer Sie Varianten produzieren, eine Richtung pro Variante. Leiten Sie die Anfrage nur dann unverändert weiter, wenn sie nackt ist. Eine Stilrichtung ist ein einziger umfassender Absatz, der in die Nachricht aufgenommen wird, und der die Stimmung (2-3 Adjektive), die Farbstrategie (die Logik, keine Hex-Codes), das Schriftgefühl, die Layout-Philosophie, den Komponentenstil (Radien, Rahmen vs. Schatten, Navigationsbehandlung), den Stil von Bildern und Illustrationen sowie ein oder zwei charakteristische Details abdeckt. Legen Sie sich auf eine Palette, eine Schriftrichtung und ein Gesamtgefühl fest — alles, was nur eine Stimmung setzt, wird als Hinweis und nicht als Richtung gelesen. Seien Sie meinungsstark; machen Sie keine halben Sachen. Setzen Sie die Persönlichkeit in Farbe, Schrift und Bilder, nicht in ungewöhnlichem Layout oder Navigation.

Erweitern Sie das, was der Benutzer gegeben hat, und widersprechen Sie ihm niemals. Wenn sie auf Referenzbilder oder Apps verweisen, die ihnen gefallen, studieren Sie jedes einzelne und übertragen Sie das, was Sie mitnehmen, in die Richtung — Sleek sieht nur Bilder, die als imageUrls übergeben werden, daher ist die Richtung bei lokalen Dateien der Weg, wie diese Referenzen es erreichen. Entlehnen Sie Muster, niemals die Markenidentität, den Inhalt oder den Namen der Quelle.

Verwenden Sie eine Stilrichtung oder eine referenceId, nicht beides — eine Referenz trägt bereits einen vollständigen eigenen Styleguide.

Einen Stil mit einer Referenz säen: Sleek kuratiert einen Katalog von Design-Referenzen. Wenn der Benutzer einen bestimmten Look wünscht oder nach Stiloptionen fragt, listen Sie sie mit GET /api/v1/references auf (jede hat einen name und previewImageUrls, die Sie anzeigen können) und übergeben Sie die gewählte ID als referenceId in der ersten Nachricht an ein Projekt, damit ihr Styleguide das gesamte Design speist.

Identifizieren Sie Ihr Tool: Senden Sie immer source, den Slug des Tools, das die Anfrage stellt. Der Sleek-Editor verwendet es, um dem Benutzer zu zeigen, wer entwirft, während der Durchlauf streamt. Erkannte Werte: claude-code, claude, codex, chatgpt, cursor, openclaw, grok. Wenn Ihr Tool nicht aufgeführt ist, senden Sie trotzdem einen kurzen kebab-case-Slug dafür (max. 64 Zeichen). Nicht erkannte Werte sind in Ordnung und erhalten eine generische Bezeichnung.

Beobachten Sie es live: Durchläufe werden in Echtzeit im Sleek-Editor gerendert. Nachdem Sie die erste Nachricht an ein Projekt gesendet haben, teilen Sie dem Benutzer mit, dass er seine Bildschirme live in Sleek beim Entwerfen zusehen kann, und geben Sie den Editor-Link: https://sleek.design/project/:projectId. Öffnen Sie selbst keinen Browser, es sei denn, der Benutzer bittet darum.

Polling: Chat-Nachrichten sind standardmäßig asynchron: Sie erhalten eine runId und führen einen Poll mit GET /api/v1/projects/:id/chat/runs/:runId durch. Starten Sie mit einem Intervall von 2s, reduzieren Sie es nach 10s auf 5s, geben Sie nach 5 Minuten auf. Beenden Sie bei completed oder failed; wenn Sie den Status nicht lesen können, stoppen Sie und melden Sie es, anstatt es als "noch nicht erledigt" zu zählen. Sie können auch ?wait=true für einen blockierenden Aufruf verwenden (bis zu 300s; fällt auf Polling zurück, wenn es mit 202 zeitlich ausläuft).

Bearbeiten eines bestimmten Bildschirms: Verwenden Sie target.screenId, um Änderungen an den richtigen Bildschirm zu lenken. Die screenId stammt aus den result.operations des Durchlaufs oder aus dem Feld screenId jeder Komponente, das von GET /api/v1/projects/:id/components zurückgegeben wird; es ist nicht die Komponenten-ID.

Ein Durchlauf nach dem anderen: Pro Projekt ist nur ein aktiver Durchlauf erlaubt. Wenn Sie 409 CONFLICT erhalten, warten Sie, bis der aktuelle Durchlauf abgeschlossen ist, bevor Sie die nächste Nachricht senden. Wenn der Benutzer seine Meinung geändert hat oder ein veralteter Durchlauf das Projekt blockiert, brechen Sie ihn ab (siehe Durchlauf abbrechen). Nachrichten an verschiedene Projekte können parallel laufen; verwenden Sie asynchrones Polling (nicht ?wait=true), wenn Sie mehrere Projekte gleichzeitig ausführen.

Sichere Wiederholungen: Fügen Sie einen idempotency-key-Header (max. 255 Zeichen) für wiederholungssichere erneute Sendungen hinzu. Der Server gibt den vorhandenen Durchlauf zurück, anstatt ein Duplikat zu erstellen.

3. Ergebnisse anzeigen

Nach jedem Chat-Durchlauf, der screen_created- oder screen_updated-Operationen erzeugt, machen Sie Screenshots und zeigen Sie sie dem Benutzer mit POST /api/v1/screenshots. Der Schritt ist nur abgeschlossen, wenn der Benutzer einen Screenshot von jedem Bildschirm gesehen hat, den der Durchlauf erstellt oder aktualisiert hat; beenden Sie einen Durchlauf niemals stillschweigend.

Neue Bildschirme: ein Screenshot pro Bildschirm + ein kombinierter Screenshot aller Bildschirme im Projekt.
Aktualisierte Bildschirme: ein Screenshot pro betroffenem Bildschirm.

Verwenden Sie background: "transparent", es sei denn, der Benutzer fordert ausdrücklich eine bestimmte Hintergrundfarbe an.

Speichern Sie Screenshots im Projektverzeichnis (nicht in einem temporären Ordner), damit der Benutzer sie leicht anzeigen kann.

Anzeigen vs. Überprüfen: Die Standardeinstellungen erfassen nur den sichtbaren Bereich, was die richtige Rahmung für den Benutzer ist — Bildschirme sehen aus wie Telefonbildschirme. Sie sind die falsche Rahmung, um Ihre eigene Arbeit zu beurteilen, da alles unterhalb der Falte abgeschnitten wird. Wenn Sie überprüfen, was ein Durchlauf produziert hat, machen Sie erneut einen Screenshot des Bildschirms mit fullHeight: true (ein Bildschirm pro Anfrage), um die gesamte scrollbare Seite zu sehen.

Screenshot-Anfragen sind unabhängig voneinander, senden Sie sie also parallel — der benutzergerichtete Screenshot und Ihr fullHeight-Überprüfungs-Screenshot gehen zusammen raus, ebenso wie die Screenshots für verschiedene Bildschirme. "Ein Bildschirm pro Anfrage" regelt, was in jedes Bild geht, nicht wie schnell Sie sie senden; es ist kein Grund, auf eine Antwort zu warten, bevor Sie mit der nächsten beginnen. Verlangsamen Sie nur, wenn Sie tatsächlich einen 429 erhalten.

Bezeichnen Sie einen Bildschirm niemals anhand eines Viewport-Screenshots als unvollständig. Inhalte, die zu fehlen scheinen, befinden sich fast immer nur unterhalb der Falte. Bevor Sie dem Benutzer mitteilen, dass etwas fehlt, oder eine Folgenachricht senden, in der Sleek gebeten wird, es hinzuzufügen, bestätigen Sie es gegen den gesamten Bildschirm: ein fullHeight: true-Screenshot oder das Komponenten-HTML von GET /api/v1/projects/:id/components/:componentId, das die Grundwahrheit für das ist, was auf dem Bildschirm ist. Der Screenshot ist die Standardeinstellung und beantwortet die meisten Überprüfungsfragen von selbst — greifen Sie nicht auf den Code zurück, um etwas zu überprüfen, das er bereits zeigt. Greifen Sie nur dann auf den Code zu, wenn Sie kurz davor sind zu behaupten, dass etwas fehlt: Ein Rendering kann weglassen, was tatsächlich da ist (hinter der Höhenbegrenzung, in einem eingeklappten Abschnitt, auf einer späteren Karussell-Folie). Daher lohnt sich eine negative Schlussfolgerung für eine zweite Quelle. Beachten Sie auch die Umkehrung — ein im HTML vorhandenes Element kann für den Benutzer dennoch nicht sichtbar sein.

Implementieren von Designs

Wenn der Benutzer die Designs in Code implementieren möchte (nicht nur eine Vorschau anzeigen), rufen Sie immer den Komponenten-HTML-Code ab. Verlassen Sie sich nicht nur auf Screenshots.

Verwenden Sie GET /api/v1/projects/:id/components/:componentId, um den Code jedes Bildschirms abzurufen. Die componentId stammt aus den result.operations des Chat-Durchlaufs.

Komponenten-Code kann groß sein. Vermeiden Sie beim Speichern in Dateien, den Inhalt über Ihre Textausgabe zu schreiben: das ist langsam und verschwendet Tokens. Verwenden Sie stattdessen Shell-Befehle, um die API-Antwort abzurufen und direkt auf die Festplatte zu schreiben (z. B. leiten Sie den Antwort-Body in eine Datei um).

Welche Version verwenden

Jede Komponente führt ein versions[]-Array und eine activeVersion: number. Standardmäßig verwenden Sie den Eintrag, bei dem versions[i].version === activeVersion: das ist der Code, der derzeit in Sleek angezeigt wird.

Wenn die Aufforderung des Benutzers bestimmte Versionen festlegt, folgen Sie stattdessen diesen (siehe Fixierte Versionen unten).

Fixierte Versionen

Die Aufforderung des Benutzers kann einen Pin-Block enthalten, der Ihnen sagt, dass Sie bestimmte historische Versionen anstelle der aktuellen implementieren sollen, wie folgt:

... in diesem exakten Zustand anstelle der aktuellen Version des Projekts:
- Komponente cmp_abc: Version ver_001
- Komponente cmp_def: Version ver_002
- Thema thm_ghi: Version ver_003

Wenn Sie einen Pin-Block sehen, implementieren Sie diese exakten Versionen anstelle von activeVersion. Komponenten, die nicht im Pin-Block genannt werden, verwenden weiterhin ihre aktive Version. Themen-IDs tauchen nur innerhalb von Pin-Blöcken auf; dieses Skill setzt keinen separaten Endpunkt frei, um sie aufzulisten.

Den richtigen Code abrufen

Finden Sie für jede fixierte Komponente den Eintrag in versions[], bei dem versions[i].id mit der angegebenen Versions-ID übereinstimmt (z. B. ver_001), und verwenden Sie dessen code. Fallen Sie für fixierte Komponenten nicht auf activeVersion zurück.

Screenshots von fixierten Versionen

Übergeben Sie componentVersionOverrides und themeVersionOverrides an POST /api/v1/screenshots:

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

Keys sind die öffentlichen IDs der Komponenten / Themen; Werte sind die entsprechenden versions[i].id. Entitäten, die in einer Map fehlen, fallen auf ihre aktive Version zurück. Fügen Sie die Überschreibungs-Maps immer dann ein, wenn die Aufforderung fixierte Versionen angegeben hat.

HTML-Prototypen

Der code der Komponente ist ein vollständiges HTML-Dokument. Speichern Sie es direkt in einer .html-Datei. Kein Build-Schritt erforderlich.

Native Frameworks (React Native, SwiftUI usw.)

Verwenden Sie sowohl den HTML-Code als auch die Screenshots zusammen:

HTML-Code ist die Implementierungsreferenz: Er enthält die genaue Struktur, das Layout, das Styling, die Farben, Abstände, Inhalte, Bild-URLs und Icon-Namen.
Screenshots sind das visuelle Ziel: Verwenden Sie sie, um zu überprüfen, ob Ihre Implementierung dem beabsichtigten Aussehen entspricht.

Das HTML sagt Ihnen, wie Sie es bauen sollen; der Screenshot sagt Ihnen, wie es aussehen soll.

Icons

Sleek verwendet Iconify-Icons im Format prefix:name (z. B. solar:heart-bold, material-symbols:search-rounded, lucide:settings). Die gebräuchlichsten Sets sind Solar, Hugeicons, Material Symbols und MDI.

Verwenden Sie die exakten Icons aus dem HTML-Code. Ersetzen Sie sie nicht durch ein anderes Icon-Set. Das passende Icon für jede Plattform (z. B. React Native, SwiftUI) zu finden, ist Teil der Implementierung.

Kurzreferenz: Alle Endpunkte

Dieser Abschnitt listet die Anfrage- und Antwort-Formate für alle in diesem Skill verwendeten Endpunkte auf. Details zu Endpunkten, die nicht aufgeführt sind (z. B. /api/v1/references oder /api/v1/spec.json), finden Sie in der API-Spezifikation unter https://sleek.design/api/v1/spec.json.

Operation	Endpunkt	Details
Projekt erstellen	`POST /api/v1/projects`	Body: `{"name": string}`. Antwort mit Status 201: `{"project": { "id": string, "name": string, "createdAt": string, ... }}`
Projekt abrufen	`GET /api/v1/projects/:id`	Antwort: `{"project": { ... }}`
Projekte auflisten	`GET /api/v1/projects`	Antwort: `{"projects": [ ... ]}`
Projekt löschen	`DELETE /api/v1/projects/:id`	Antwort mit Status 200: `{"success": true}`
Nachricht senden	`POST /api/v1/projects/:id/chat/messages`	Header: `Idempotency-Key: string` (optional). Body: `{ "source": string, "message": string?, "referenceId": string?, "imageUrls": string[]?, "target": { "screenId": string }? }`. Antwort mit Status 201: `{"runId": string}`
Durchlauf abrufen	`GET /api/v1/projects/:id/chat/runs/:runId`	Abfrage: `?wait=true` (optional). Antwort: siehe unten
Komponenten auflisten	`GET /api/v1/projects/:id/components`	Antwort: `{"components": [ { "id": string, "name": string, "screenId": string, "versions": [ { "id": string, "version": number, "code": string, "createdAt": string } ], "activeVersion": number } ]}`
Komponente abrufen	`GET /api/v1/projects/:id/components/:componentId`	Antwort: `{"component": { ... }}` (identisch zur obigen Form, aber für eine einzelne Komponente)
Screenshot erstellen	`POST /api/v1/screenshots`	Body: `{ "componentIds": string[], "projectId": string, "background": string?, "fullHeight": boolean?, "componentVersionOverrides": object?, "themeVersionOverrides": object? }`. Antwort: `{"screenshots": [ { "componentId": string, "url": string, "versionId": string } ]}`
Geräte-Flow starten	`POST /api/v1/device/start`	Body: `{"source": string}`. Antwort: `{"verificationUrl": string, "userCode": string, "deviceCode": string, "interval": number}`
Geräte-Flow Poll	`POST /api/v1/device/poll`	Body: `{"deviceCode": string}`. Antwort: `{"status": string, "key": string?}`
Chat-Durchlauf abbrechen	`POST /api/v1/projects/:id/chat/runs/:runId/cancel`	Kein Body. Antwort mit Status 200: `{"success": true}`

Durchlauf-Antwortformat

Die Antwort von GET /api/v1/projects/:id/chat/runs/:runId hat die folgende Struktur:

{
  "status": "pending" | "running" | "completed" | "failed" | "cancelled",
  "runId": string,
  "createdAt": string,
  "result": {
    "message": string?,
    "operations": [
      {
        "type": "screen_created" | "screen_updated" | "component_created" | "component_updated",
        "projectId": string,
        "screenId": string?,
        "componentId": string?,
        "versionId": string?,
        "sourceVersionId": string?
      }
    ],
    "project": { ... }
  } | null
}

Fehlerbehandlung

Status	Edge Case	Umgang
`400`	Ungültige Anfrage (fehlerhafte Nutzdaten)	Überprüfen Sie die Anfrage; korrigieren Sie die Nutzdaten und wiederholen Sie den Vorgang
`401`	Fehlender oder ungültiger API-Key	Zeigen Sie dem Benutzer die Aufforderung zur Key-Einrichtung an; wiederholen Sie den Vorgang nach der Aktualisierung nicht automatisch
`403`	Key ist gültig, aber der Bereich reicht nicht aus	Erstellen Sie einen neuen Key mit den erforderlichen Bereichen
`404`	Projekt, Komponente oder Ressource nicht gefunden	Überprüfen Sie die Gültigkeit der IDs; möglicherweise wurde das Projekt gelöscht
`409`	Ein Chat-Durchlauf ist bereits aktiv	Siehe Ein Durchlauf nach dem anderen
`429`	Ratenbegrenzung	Führen Sie einen exponentiellen Backoff durch, beginnend mit 2s
`5xx`	Serverfehler	Wiederholen Sie es mit einem angemessenen Backoff (z. B. 5s, 10s, 30s) und geben Sie auf, wenn es erneut fehlschlägt
Keine Antwort	Langsame / ausfallende API	30s Timeout

Tipps zur Fehlerbehebung

Zeitüberschreitung beim Start der Chat-Nachricht: Die Chat-Nachricht kann beim Senden zeitlich auslaufen. Antwort mit 202 erhalten? Starten Sie einen Poll für den Durchlauf mit der erhaltenen runId.
Der Bildschirm sieht leer aus: Das passiert, wenn die Anfrage kein source-Feld enthielt. Überprüfen Sie den Body der Chat-Nachricht noch einmal.
"Ein Projekt hat zu viele Bildschirme"-Fehler: Sleek erlaubt bis zu 25 Bildschirme pro Projekt. Versuchen Sie, ein neues Projekt zu erstellen.
Sleek überschreibt meine Formatierung: Sleek stimmt den Code auf die aktuelle aktive Version ab. Wenn Sie ein Code-Snippet verwenden, um einen bestimmten Stil zu erreichen, stellen Sie sicher, dass Sie die Vorschau verwenden, um den Stil zunächst zu validieren, anstatt zu erwarten, dass der endgültige Code mit Ihren Anmerkungen übereinstimmt.

Häufig gestellte Fragen

F: Was ist Sleek? A: Ein KI-gestütztes Tool, das in Sekunden mobile App-Designs aus Textbeschreibungen erstellt.

F: Funktioniert das mit meinem vorhandenen Code? A: Sleek produziert eigenständige HTML-Prototypen; die Implementierung in Ihrem nativen Framework (React Native, SwiftUI, Jetpack Compose) liegt bei Ihnen.

F: Kann ich Designs in Sleek bearbeiten? A: Ja. Sie können die Ausgabe von Sleek mit target.screenId erneut an Sleek senden, um bestimmte Bildschirme zu verfeinern.

F: Was passiert nach der Testversion? A: Sie benötigen ein kostenpflichtiges Abonnement, um weiterzumachen. Der Pro-Plan kostet 49,99 $/Monat oder 30 $/Monat bei jährlicher Abrechnung.

F: Wie lösche ich ein Projekt? A: Senden Sie eine DELETE /api/v1/projects/:id-Anfrage.

F: Kann ich in mehreren Projekten gleichzeitig arbeiten? A: Ja, Nachrichten an verschiedene Projekte können parallel laufen. Verwenden Sie asynchrones Polling für mehrere Projekte.

F: Wohin geht mein Code? Werden meine Designdaten gespeichert? A: Code-Exporte sind temporär und liegen in Ihrem Besitz; Projekt-Daten und Assets werden gemäß der Datenschutzerklärung von Sleek gespeichert.

Mobile-Apps-Design

Was ist Mobile-Apps-Design?

In Ihrer bevorzugten KI fragen

Vorschau

Dokumentation