| 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.
