sleek-design-mobile-apps

安装量: 19.9K
排名: #105

安装

npx skills add https://github.com/sleekdotdesign/agent-skills --skill sleek-design-mobile-apps
Designing with Sleek
Overview
sleek.design
is an AI-powered mobile app design tool. You interact with it via a REST API at
/api/v1/*
to create projects, describe what you want built in plain language, and get back rendered screens. All communication is standard HTTP with bearer token auth.
Base URL
:
https://sleek.design
Auth
:
Authorization: Bearer $SLEEK_API_KEY
on every
/api/v1/*
request
Content-Type
:
application/json
(requests and responses)
CORS
Enabled on all
/api/v1/*
endpoints
Prerequisites: API Key
Create API keys at
https://sleek.design/dashboard/api-keys
. The full key value is shown only once at creation — store it in the
SLEEK_API_KEY
environment variable.
Required plan
Pro+ (API access is gated)
Key scopes
Scope
What it unlocks
projects:read
List / get projects
projects:write
Create / delete projects
components:read
List components in a project
chats:read
Get chat run status
chats:write
Send chat messages
screenshots
Render component screenshots
Create a key with only the scopes needed for the task.
Security & Privacy
Single host
All requests go exclusively to
https://sleek.design
. No data is sent to third parties.
HTTPS only
All communication uses HTTPS. The API key is transmitted only in the
Authorization
header to Sleek endpoints.
Minimal scopes
Create API keys with only the scopes required for the task. Prefer short-lived or revocable keys.
Image URLs
When using
imageUrls
in chat messages, those URLs are fetched by Sleek's servers. Avoid passing URLs that contain sensitive content.
Handling high-level requests
When the user says something like "design a fitness tracking app" or "build me a settings screen":
Create a project
if one doesn't exist yet (ask the user for a name, or derive one from the request)
Send a chat message
describing what to build — you can use the user's words directly as
message.text
; Sleek's AI interprets natural language
Follow the screenshot delivery rule
below to show the result
You do not need to decompose the request into screens first. Send the full intent as a single message and let Sleek decide what screens to create.
Screenshot delivery rule
After every chat run that produces
screen_created
or
screen_updated
operations, always take screenshots and show them to the user.
Never silently complete a chat run without delivering the visuals.
When screens are created for the first time on a project
(i.e. the run includes
screen_created
operations), deliver:
One screenshot per newly created screen (individual
componentIds: [screenId]
)
One combined screenshot of all screens in the project (
componentIds: [all screen ids]
)
When only existing screens are updated
, deliver one screenshot per affected screen.
Use
background: "transparent"
for all screenshots unless the user explicitly requests otherwise.
Quick Reference — All Endpoints
Method
Path
Scope
Description
GET
/api/v1/projects
projects:read
List projects
POST
/api/v1/projects
projects:write
Create project
GET
/api/v1/projects/:id
projects:read
Get project
DELETE
/api/v1/projects/:id
projects:write
Delete project
GET
/api/v1/projects/:id/components
components:read
List components
POST
/api/v1/projects/:id/chat/messages
chats:write
Send chat message
GET
/api/v1/projects/:id/chat/runs/:runId
chats:read
Poll run status
POST
/api/v1/screenshots
screenshots
Render screenshot
All IDs are stable string identifiers.
Endpoints
Projects
List projects
GET /api/v1/projects?limit=50&offset=0
Authorization
:
Bearer $SLEEK_API_KEY
Response
200
:
{
"data"
:
[
{
"id"
:
"proj_abc"
,
"name"
:
"My App"
,
"slug"
:
"my-app"
,
"createdAt"
:
"2026-01-01T00:00:00Z"
,
"updatedAt"
:
"..."
}
]
,
"pagination"
:
{
"total"
:
12
,
"limit"
:
50
,
"offset"
:
0
}
}
Create project
POST /api/v1/projects
Authorization
:
Bearer $SLEEK_API_KEY
Content-Type
:
application/json
{
"name"
:
"My New App"
}
Response
201
— same shape as a single project.
Get / Delete project
GET /api/v1/projects/:projectId
DELETE /api/v1/projects/:projectId → 204 No Content
Components
List components
GET /api/v1/projects/:projectId/components?limit=50&offset=0
Authorization
:
Bearer $SLEEK_API_KEY
Response
200
:
{
"data"
:
[
{
"id"
:
"cmp_xyz"
,
"name"
:
"Hero Section"
,
"activeVersion"
:
3
,
"versions"
:
[
{
"id"
:
"ver_001"
,
"version"
:
1
,
"createdAt"
:
"..."
}
]
,
"createdAt"
:
"..."
,
"updatedAt"
:
"..."
}
]
,
"pagination"
:
{
"total"
:
5
,
"limit"
:
50
,
"offset"
:
0
}
}
Chat — Send Message
This is the core action: describe what you want in
message.text
and the AI creates or modifies screens.
POST /api/v1/projects/:projectId/chat/messages?wait=false
Authorization
:
Bearer $SLEEK_API_KEY
Content-Type
:
application/json
idempotency-key
:
{
"message"
:
{
"text"
:
"Add a pricing section with three tiers"
}
,
"imageUrls"
:
[
"https://example.com/ref.png"
]
,
"target"
:
{
"screenId"
:
"scr_abc"
}
}
Field
Required
Notes
message.text
Yes
1+ chars, trimmed
imageUrls
No
HTTPS URLs only; included as visual context
target.screenId
No
Edit a specific screen; omit to let AI decide
?wait=true/false
No
Sync wait mode (default: false)
idempotency-key
header
No
Replay-safe re-sends
Response — async (default,
wait=false
)
Status
202 Accepted
.
result
and
error
are absent until the run reaches a terminal state.
{
"data"
:
{
"runId"
:
"run_111"
,
"status"
:
"queued"
,
"statusUrl"
:
"/api/v1/projects/proj_abc/chat/runs/run_111"
}
}
Response — sync (
wait=true
)
Blocks up to
300 seconds
. Returns
200
when completed,
202
if timed out.
{
"data"
:
{
"runId"
:
"run_111"
,
"status"
:
"completed"
,
"statusUrl"
:
"..."
,
"result"
:
{
"assistantText"
:
"I added a pricing section with..."
,
"operations"
:
[
{
"type"
:
"screen_created"
,
"screenId"
:
"scr_xyz"
,
"screenName"
:
"Pricing"
}
,
{
"type"
:
"screen_updated"
,
"screenId"
:
"scr_abc"
}
,
{
"type"
:
"theme_updated"
}
]
}
}
}
Chat — Poll Run Status
Use this after async send to check progress.
GET /api/v1/projects/:projectId/chat/runs/:runId
Authorization
:
Bearer $SLEEK_API_KEY
Response — same shape as send message
data
object:
{
"data"
:
{
"runId"
:
"run_111"
,
"status"
:
"queued"
,
"statusUrl"
:
"..."
}
}
When completed successfully,
result
is present:
{
"data"
:
{
"runId"
:
"run_111"
,
"status"
:
"completed"
,
"statusUrl"
:
"..."
,
"result"
:
{
"assistantText"
:
"..."
,
"operations"
:
[
...
]
}
}
}
When failed,
error
is present:
{
"data"
:
{
"runId"
:
"run_111"
,
"status"
:
"failed"
,
"statusUrl"
:
"..."
,
"error"
:
{
"code"
:
"execution_failed"
,
"message"
:
"..."
}
}
}
Run status lifecycle
:
queued
running
completed | failed
Screenshots
Takes a snapshot of one or more rendered components.
POST /api/v1/screenshots
Authorization
:
Bearer $SLEEK_API_KEY
Content-Type
:
application/json
{
"componentIds"
:
[
"cmp_xyz"
,
"cmp_abc"
]
,
"projectId"
:
"proj_abc"
,
"format"
:
"png"
,
"scale"
:
2
,
"gap"
:
40
,
"padding"
:
40
,
"background"
:
"transparent"
}
Field
Default
Notes
format
png
png
or
webp
scale
2
1–3 (device pixel ratio)
gap
40
Pixels between components
padding
40
Uniform padding on all sides
paddingX
(optional)
Horizontal padding; overrides
padding
for left/right when provided
paddingY
(optional)
Vertical padding; overrides
padding
for top/bottom when provided
paddingTop
(optional)
Top padding; overrides
paddingY
when provided
paddingRight
(optional)
Right padding; overrides
paddingX
when provided
paddingBottom
(optional)
Bottom padding; overrides
paddingY
when provided
paddingLeft
(optional)
Left padding; overrides
paddingX
when provided
background
transparent
Any CSS color (hex, named,
transparent
)
showDots
false
Overlay a subtle dot grid on the background
Padding resolves with a cascade: per-side → axis → uniform. For example,
paddingTop
falls back to
paddingY
, which falls back to
padding
. So
{ "padding": 20, "paddingX": 10, "paddingLeft": 5 }
gives top/bottom 20px, right 10px, left 5px.
When
showDots
is
true
, a dot pattern is drawn over the background color. The dots automatically adapt to the background: dark backgrounds get light dots, light backgrounds get dark dots. This has no effect when
background
is
"transparent"
.
Always use
"background": "transparent"
unless the user explicitly requests a specific background color.
Response: raw binary
image/png
or
image/webp
with
Content-Disposition: attachment
.
Error Shapes
{
"code"
:
"UNAUTHORIZED"
,
"message"
:
"..."
}
HTTP
Code
When
401
UNAUTHORIZED
Missing/invalid/expired API key
403
FORBIDDEN
Valid key, wrong scope or plan
404
NOT_FOUND
Resource doesn't exist
400
BAD_REQUEST
Validation failure
409
CONFLICT
Another run is active for this project
500
INTERNAL_SERVER_ERROR
Server error
Chat run-level errors (inside
data.error
):
Code
Meaning
out_of_credits
Organization has no credits left
execution_failed
AI execution error
Flows
Flow 1: Create project and generate a UI (async + polling)
1. POST /api/v1/projects → get projectId
2. POST /api/v1/projects/:id/chat/messages → get runId (202)
3. Poll GET /api/v1/projects/:id/chat/runs/:runId
until status == "completed" or "failed"
4. Collect screenIds from result.operations
(screen_created and screen_updated entries)
5. Screenshot each affected screen individually
6. If any screen_created: also screenshot all project screens combined
7. Show all screenshots to the user
Polling recommendation
start at 2s interval, back off to 5s after 10s, give up after 5 minutes. Flow 2: Sync mode (simple, blocking) Best for short tasks or when latency is acceptable. 1. POST /api/v1/projects/:id/chat/messages?wait=true → blocks up to 300s → 200 if completed, 202 if timed out 2. If 202, fall back to Flow 1 polling with the returned runId 3. On completion, screenshot and show affected screens (see screenshot delivery rule) Flow 3: Edit a specific screen 1. GET /api/v1/projects/:id/components → find screenId 2. POST /api/v1/projects/:id/chat/messages body: { message: { text: "..." }, target: { screenId: "scr_xyz" } } 3. Poll or wait as above 4. Screenshot the updated screen and show it to the user Flow 4: Idempotent message (safe retries) Add idempotency-key header on the send request. If the network drops and you retry with the same key, the server returns the existing run rather than creating a duplicate. The key must be ≤255 chars. POST /api/v1/projects/:id/chat/messages idempotency-key: my-unique-request-id-abc123 Flow 5: One run at a time (conflict handling) Only one active run is allowed per project. If you send a message while one is running, you get 409 CONFLICT . Wait for the active run to complete before sending the next message. 409 response → poll existing run → completed → send next message Pagination All list endpoints accept limit (1–100, default 50) and offset (≥0). The response always includes pagination.total so you can page through all results. GET /api/v1/projects?limit=10&offset=20 Common Mistakes Mistake Fix Sending to /api/v1 without Authorization header Add Authorization: Bearer $SLEEK_API_KEY to every request Using wrong scope Check key's scopes match the endpoint (e.g. chats:write for sending messages) Sending next message before run completes Poll until completed / failed before next send Using wait=true on long generations It blocks 300s max; have a fallback to polling for 202 response HTTP URLs in imageUrls Only HTTPS URLs are accepted Assuming result is present on 202 result is absent until status is completed
返回排行榜