---
name: kite
description: Design in Kite (kite.new) — draw the visual assets you make (banners, posts, ads, logos, landing pages) into a design file the user's team edits and comments on.
---

# Kite skill

Use Kite when you make visual assets for the user — banners, social posts, ads, thumbnails, logos, icons, landing pages, an identity board — so they are kept in one design file the user and their team can edit and comment on, instead of being lost in the chat.

## Setup
In Claude, Kite is in the connector directory: the user clicks Connect at https://claude.ai/directory/connectors/kite. If your host supports MCP with OAuth, add https://cf.kite.new/api/mcp as a server and let the user sign in. Otherwise the user creates an API key at https://cf.kite.new/settings (Connect); ask them to paste it once, store it as KITE_API_KEY, never print it back. If the user has the Kite desktop app, the stdio command `~/.kite/bin/kite mcp` needs no sign-in and sees which files they have open.

## Working in Kite
POST https://cf.kite.new/api/mcp with the MCP Streamable HTTP protocol. Kite tells an agent this when it connects:

Kite is a design tool. Everything you make for the user — screens, banners, social posts, ads, logos, identity boards — goes in a design file, which the user and their team edit and comment on with you. file_new makes one (file_list or file_search finds one; editor_focus says which they have open); give the user its link.

You MUST call guide_read { topic: "drawing" } before your first layer_draw in a session: how to write layers, check them and stop. Its other topics: components, design-systems, comments-and-requests, files.

In short: system_read { file } first and draw with its variables; file_outline's agents says whether to build with components; layer_draw in small pieces, one section, card or row per call; layer_edit what is there rather than redrawing it; look at each change with layer_render before saying it is done; finish_working { file } when you have finished.

Say "file", "frame", "layer" and "link". Never say MCP, node id, slug, token or manifest to the user.

The guide's topics (guide_read { topic } returns each):

## Drawing
A file is a tree of nodes — frames, text, images, SVGs — with CSS on each, on pages. file_outline reads the outline (ids, sizes, positions); layer_source reads any node as HTML with its ids. layer_draw draws: each top-level element becomes a frame (an artboard) on the board, or pass parent to draw inside a node, or replace to swap one. layer_edit changes CSS, words, names and positions in place; layer_nest, layer_copy and layer_remove do the rest; layer_search finds layers by name or words. When the person says “this” or “the selected one”, editor_focus says what they have selected in the editor; without a file, it says which file they have open, so start there when they haven't named one.

Write in small pieces — one section, card or row per call — because the person watches each one appear live. Inline styles only (no <style>, classes or scripts), flexbox for layout, px sizes, images by https URL, or picture_add for a picture file (it returns the src); never base64 inside the HTML. Give every artboard an explicit width (and height when it is a fixed format, e.g. 1500×500 for a Twitter header). Draw plain layers; when the file or a library of its workspace already has components, use them instead of redrawing them (topic "components"). Alternative designs to choose between (not component variants) go beside the original, named "<name> (Option 1)", "(Option 2)". Change what is there rather than redrawing it: people edit the same file, and redrawing loses their work.

TYPE. Every Google Fonts family works, the system's, and the fonts the file's workspace uploaded. Before styling text in a font, check it with font_lookup and use only the weights it lists: a weight the family lacks is drawn as a faux bold, and a family Kite doesn't have falls back to another font.

LOOK BEFORE YOU SAY IT IS DONE. After each section, look at it with layer_render and check it as a designer would:
- Spacing: an even rhythm; related things close together, groups further apart; nothing cramped, no space left empty by accident.
- Type: a clear step between heading, body and caption; nothing too small to read; lines that don't collide.
- Contrast: every text readable at a glance on what is behind it; muted colours only for what really is secondary.
- Alignment: repeated rows (lists, tables, nav) keep their columns. Give icons and trailing actions a slot of fixed width (width and flex-shrink: 0), even in a row that leaves it empty; gap alone won't line them up.
- Fit: nothing clipped at a frame's edge. A frame that isn't a fixed format: remove its height (layer_edit, height: null) so it fits its content, rather than guessing a new one.
Fix what you find with layer_edit, in place. Don't delete a frame and draw it again: that loses the person's edits and where their comments are pinned.

When you have finished what you were asked in a file, call finish_working { file }, even if you couldn't finish, so the person sees you stop and can edit those frames again.

## Components
When the file, or a library of its workspace, already has components, use them instead of redrawing them: write <div data-component="Button" data-props='{"Size":"Large","Label":"Sign up"}'></div> in layer_draw's HTML and it becomes a real instance in that same call (by the component's name or id; data-library="<id>" for a library's; a style on it is the instance's own). Instances follow their main, and layer_edit on one changes only that instance.

Whether to make components of your own is the file's choice: file_outline says agents.components. Off (the default, while a direction is explored): draw plain layers, but once the same part (a nav, a sidebar, a tab bar, a header) is on 3 frames, offer the person once, in your conversation with them, to build the shared parts as components: slower to draw, and then edited once rather than on every frame. If they say yes, call file_settings { file, components: true }. On: draw a part that repeats across frames once, component_make it, and place it in the other frames as above; copies already drawn become instances with layer_draw { replace: <copy>, html: <the data-component div> }. What differs between frames (the item that is active) is that instance's own change, with layer_edit or instance_set. A part on one frame stays plain layers. Either way, make components whenever the person asks for them or for a design system.

A component's variants (sizes, states, a sidebar open or collapsed) are a component set: draw each, component_make each, name them "Size=Large, State=Hover", then component_combine them; component_properties adds boolean, text and swap properties and ties layers to them, and instance_set (or component_place { properties }) chooses an instance's variant and values.

A file can be published as a library (library_publish) for the other files of its workspace: library_list shows the libraries a file can use and their components, component_place { library } places one, and library_update brings its instances up to date when the library publishes changes.

## Design systems
A workspace keeps design systems — variables for colour, type, spacing and radii (in collections with modes such as Light and Dark), text and effect styles, each saying what it is for, and a written guide — and a file uses one. Before drawing in a file, call system_read { file }: write its variables as var(--name) in your inline styles (color: var(--text); background: var(--primary)) rather than raw values, and follow its guide. A frame picks a mode with data-mode-<collection>="<mode>" (system_read says which). Never paste its CSS into the design.

A file with none: draw with plain values; link one (system_apply, from system_list) or make one (system_new: from variables, a preset, or the user's website) only when the person asks for a design system, or to turn a design into one.

variable_edit { project | system, collections?, variables?, remove? } makes or changes collections, modes and variables by name (an alias is { alias: "name" }), made from a design or a codebase's CSS variables when asked; give each a description of what it is for. style_edit { project | system, styles?, remove? } does the same for text, effect, colour and grid styles; a style is written on a layer as its parts, var(--style--part).

## Comments and requests
comment_list is what people said and where: a pinned comment carries pin — on a frame, the frame, the layer that was clicked (pin.layer) and the spot on the frame (pin.at); on the empty board, the page and the spot in board px — so layer_source reads what it is about — use unread_only to get only what is new. comment_reply answers them as you, the agent, for the user.

People ask you for changes from inside Kite by writing @ and your name in a comment ("@Claude make this card denser"). When they say "do my Kite requests", or ask what is waiting, request_list returns the open ones with the file and where each pin is: "this" and "here" are the pin. On a frame, change pin.layer with layer_edit or draw into it with layer_draw { parent }; on the empty board, draw at layer_draw { page: pin.page.id, x: pin.at.x, y: pin.at.y } or component_place { page, x, y }. Carry each out, look at it with layer_render, then comment_reply { done: true } saying what you changed.

## Files
file_search looks inside files, not just at titles — use it whenever the user describes a file rather than names it, because file_list is newest-first only. file_archive archives one, reversible from the Archive; use it rather than leaving files behind that were made by mistake.

A file is shared by link, not published: anyone with the link can view it, and only view, or file_share { audience: "restricted", emails } makes it only the people invited — no code, no email gate. Viewers can always comment; only the owner and their workspace can download.