| name | kimi-widget |
| description | Kimi widget design system. Read this BEFORE rendering any inline widget. Defines when to use a widget and the runtime contract; the full visual style lives in references/design-system.md. Your widget runs in a sandboxed iframe with the Kimi design system pre-loaded — reference the provided CSS variables, never hardcode colors or fonts. |
Kimi Widget
A widget is a compact visual or interactive surface rendered inline in the conversation:
diagrams, dashboards, calculators, sliders, comparisons, timelines, state machines, small
simulations. Use one when seeing structure helps the user understand, compare, inspect, or act
on the answer better than prose alone.
When to generate a widget
- The answer has spatial, sequential, systemic, comparative, numeric, or interactive structure.
- The user does not need to say "show", "visualize", "chart", or "widget" — proactive widgets are
expected when the structure is there.
- If the user gives a compact visual spec without a verb ("REST vs GraphQL table", "checkout state
machine", "pricing calculator"), render it as a widget instead of only describing it.
Do not use a widget for: ordinary prose answers, routine line-by-line code explanations, file
lists / galleries / final deliverables, blocking input workflows, destructive or native actions,
or large long-lived apps.
Runtime contract
The widget runs in a sandboxed iframe with the Kimi design system CSS already loaded. All CSS
variables, form-element styles, and SVG classes are available at runtime — reference them, do not
redefine them.
- Allowed: HTML, SVG, CSS, inline JavaScript, native browser APIs.
- Not allowed: external scripts, modules, stylesheets, images, fonts, CDN libraries, npm
packages,
fetch, or WebSocket. For charts/diagrams use SVG, Canvas, CSS, or plain DOM.
- Text goes in your response, visuals go in the widget. All explanatory prose, intros, and
summaries live OUTSIDE the widget.
- After the widget renders, don't narrate it. Once you've called the widget tool and the widget
is done, do not re-summarize or repeat what you just did — the visual speaks for itself. Say only
what the widget cannot.
- Sending intent back. An interactive widget may call
window.sendPrompt(text) (when the host
injects it) to push the user's next intent into the conversation. Write text as a real user
message — what the user would actually type — never a robotic confirmation like "I selected
option A, please proceed."
- Never hardcode colors, fonts, or border-radius — always use
var(--xxx). Hardcoded values break
dark mode and look inconsistent with the host UI.
⚠️ Required: read the design system before you design
Unless the user has given you very explicit, precise styling instructions for this specific
widget, you MUST read references/design-system.md before writing the
widget code. It carries the full Kimi Perspective Widget style — visual rules, typography,
component patterns, runtime token map, and the application checklist. Do not decide a widget is too
simple, too static, or too small to need it. Skip it only when the user's instructions already fix
the visual decisions for you.
If the widget uses icons, also read references/icon-system.md: the
skill ships 105 Kimi icons (assets/icons/, indexed in references/icons/manifest.json) — pick
from the library and inline the SVG instead of drawing your own or using emoji.
