--- name: design-live description: Give a coding agent real design judgment. Use the design.live MCP to fetch brand identity, validated brand assets, ranked real-product screens and workflows, and a build-ready interface plan before writing any UI code. --- # design.live — agent setup skill Fetched from https://design.live/agent-onboarding/SKILL.md ## What design.live is design.live is the design-intelligence layer between a brief and an agent's code. It answers three questions your model cannot answer from memory: 1. **What is this brand?** Identity, logos, colors, typography, voice, audience and positioning, with source provenance and freshness. 2. **How do strong products actually behave?** Real product screens, ordered workflows, component anatomy, states, edge cases and reusable interaction patterns. 3. **What should I build?** A ranked, cited, implementation-ready plan for a specific brief, framework and platform — plus an evidence-grounded review of what you built. Current public coverage: 227 tracked brands, 8,480 indexed screens, 887 mapped workflows. ## When to use it Use design.live **before** generating interface code whenever the task involves visual design, a named brand ("make it look like Stripe"), a product flow (checkout, onboarding, settings, empty states), or a request to improve an existing interface. Do not guess at a brand's colors, logo or interaction patterns — retrieve them. Do not copy a source screen pixel for pixel. Evidence is a reasoning reference. Every returned item carries a source URL, capture time, product, platform and permission state; keep that provenance attached when you cite it. ## 1. Get a key design.live is in private beta. Keys are `dl_live_…` bearer tokens, scoped per organization and stored only as SHA-256 hashes — the raw value is shown exactly once. - Founding access (£99/year, 10,000 requests per month) issues a key immediately after checkout: - Existing customers issue, rotate and revoke keys in the dashboard: Self-serve free-tier key issuance is not open yet. If you are an agent and no key is present in the environment, stop and ask your human to complete . Never invent, guess or brute-force a key. Store the key as `DESIGN_LIVE_API_KEY` in the environment. Do not write it into a file that is committed to version control. ## 2. Configure the MCP Endpoint: `https://design.live/mcp` Transport: Streamable HTTP, `POST` only, JSON-RPC 2.0. Auth: `Authorization: Bearer $DESIGN_LIVE_API_KEY` Protocol versions: `2025-11-25`, `2025-06-18`, `2025-03-26`. ### Claude Code ```bash claude mcp add --transport http design-live https://design.live/mcp \ --header "Authorization: Bearer $DESIGN_LIVE_API_KEY" ``` Adds the MCP to the current project. Run /mcp afterwards to confirm design-live is connected. ### Cursor File: `~/.cursor/mcp.json` ```json { "mcpServers": { "design-live": { "url": "https://design.live/mcp", "headers": { "Authorization": "Bearer ${env:DESIGN_LIVE_API_KEY}" } } } } ``` Add to ~/.cursor/mcp.json for every project, or .cursor/mcp.json for one repository. ### Codex ```bash export DESIGN_LIVE_API_KEY='dl_live_…' codex mcp add design-live \ --url https://design.live/mcp \ --bearer-token-env-var DESIGN_LIVE_API_KEY ``` Codex reads the key from the environment, so the raw value never lands in a config file. ### Any MCP client ```bash curl -s https://design.live/mcp \ -H "Authorization: Bearer $DESIGN_LIVE_API_KEY" \ -H "Content-Type: application/json" \ -H "Accept: application/json, text/event-stream" \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' ``` Stateless Streamable HTTP. Protocol versions 2025-11-25, 2025-06-18 and 2025-03-26. POST only. Verify the connection by listing tools. A healthy response contains exactly 12 tools: ```bash curl -s https://design.live/mcp \ -H "Authorization: Bearer $DESIGN_LIVE_API_KEY" \ -H "Content-Type: application/json" \ -H "Accept: application/json, text/event-stream" \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' ``` ## 3. The tools | Tool | Tier | Cost | Returns | | --- | --- | --- | --- | | `search_brands` | free | 1 unit | Ranked canonical brands for a name, domain, category, audience or visual style, each with normalized context and evidence coverage. | | `resolve_brand` | free | 1 unit existing · 5 new | An existing canonical kit for a public company URL or domain, or one deduplicated, quota-aware acquisition with a pollable status. | | `get_brand` | free | 1 unit | Identity, validated logos and assets, taxonomy, freshness, capture counts, workflows and source provenance for one brand. | | `get_brand_context` | free | 1 unit | Versioned identity snapshots with design taxonomy, voice, visual style, audience, company data and freshness signals. | | `get_brand_asset` | free | 1 unit | The validated icon, logo or symbol image itself, inline, with source, freshness, storage, safety and SHA-256 integrity metadata. | | `get_brand_assets` | free | 1 unit per image | Up to six validated brand images in one deduplicated call, with a manifest mapping every image back to its canonical brand. | | `get_design_evidence` | paid | 1 unit | Hybrid-ranked real product screens, workflows and UI pattern packs for a design task, with citations, quality signals and inline screen previews. | | `get_screen` | paid | 1 unit | The canonical PNG or JPEG for an evidence hash, with product, platform, capture time, source URL, permission and integrity metadata. | | `get_workflow` | paid | 1 unit | Every ordered state in a permissioned product workflow: user actions, system responses, screen hashes and capture provenance. | | `compare_interfaces` | paid | 4–6 units | A side-by-side decision matrix of how two to four brands solve the same task, with differences, risks and an agent-ready synthesis. | | `plan_interface` | paid | 1 unit | A build-ready plan: state machine, components, data and validation contracts, edge states, accessibility, acceptance tests, citations and a saveable DESIGN.md. | | `review_implementation` | paid | 10 units | Prioritized, evidence-cited findings on an implementation screenshot against the plan, brand direction and acceptance criteria. The image is never retained. | Every tool publishes a JSON Schema 2020-12 `outputSchema`, and every successful call returns the same schema-valid JSON in both `structuredContent` and a text block. Read `structuredContent` when your client supports it. Usage is metered in units and enforced *before* execution, so a quota cannot be overspent. Prompts, screenshots and returned evidence are never written to the usage ledger. ## 4. Three example calls ### a. Get brand context before styling anything ```json { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "get_brand_context", "arguments": { "identifier": "stripe.com" } } } ``` Expected shape (abbreviated): ```json { "brand": { "slug": "stripe", "name": "Stripe", "domain": "stripe.com" }, "context": { "colors": [{ "hex": "#635BFF", "role": "primary" }], "fonts": [{ "family": "…", "role": "display" }], "voice": "…", "positioning": "…", "audience": ["developers", "businesses"], "visual_style": ["…"] }, "taxonomy": { "vertical": "…", "archetype": "…", "interaction_domains": ["payments-billing"] }, "freshness": { "last_checked_at": "…", "last_changed_at": "…", "next_refresh_at": "…" } } ``` ### b. Retrieve ranked evidence for the actual task ```json { "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "get_design_evidence", "arguments": { "query": "subscription checkout with plan comparison and card entry", "platform": "web", "limit": 8, "preview_count": 3 } } } ``` Expected shape (abbreviated): a ranked `results` array of screens, workflows and pattern packs, each with `entity_type`, `brand`, `platform`, `sha256` or workflow id, `source_url`, `captured_at`, `permission`, quality signals and rank scores; plus `previews[]` with inline images mapped back through `content_index`, and `retrieval` declaring hybrid or lexical mode. ### c. Turn evidence into a plan you can execute ```json { "jsonrpc": "2.0", "id": 3, "method": "tools/call", "params": { "name": "plan_interface", "arguments": { "brief": "Build a subscription checkout that feels like Stripe: plan comparison, card entry, clear failure states.", "platform": "web", "framework": "Next.js", "limit": 8 } } } ``` Expected shape (abbreviated): ```json { "brief": "…", "brand_direction": { "brand": "stripe", "principles": ["…"], "palette": ["…"], "type": ["…"] }, "state_machine": { "states": ["…"], "transitions": ["…"] }, "components": [{ "name": "PlanCard", "anatomy": ["…"], "states": ["…"] }], "data_contracts": ["…"], "validation": ["…"], "edge_states": ["…"], "accessibility": ["…"], "acceptance_tests": ["…"], "citations": [{ "sha256": "…", "source_url": "…", "captured_at": "…", "permission": "…" }], "design_md": "# DESIGN.md …" } ``` Save `design_md` next to the code you are about to write, then implement against the plan. ## 5. Close the loop After you build, call `review_implementation` with a PNG or JPEG screenshot (base64, no data-URL prefix, 2 MB maximum) and the original brief. It returns prioritized, evidence-cited findings and is explicit about what a screenshot cannot prove. The screenshot is processed transiently and is never retained. This call costs 10 units. ## Rules - Retrieve before you style. Never invent a brand's colors, logo or type. - Keep source URL, capture time, product, platform and permission state attached to any evidence you cite in code comments or a DESIGN.md. - Treat evidence as reasoning input, not protected expression to reproduce. - Never log, print or commit the API key. - If a call returns `monthly_limit_reached`, stop and tell your human — do not retry in a loop. ## More - Platform documentation: - Machine-readable index: - REST contracts: - Asset CDN pattern: `https://cdn.design.live/v1/domain/{domain}/{variant}`