# Kimi Widget

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

- Skill: `serejaris/kimi-widget` (Agent Skill, multi-file: 122 files)
- Install (CLI): `npx skillmds@latest add serejaris/kimi-widget`
- Raw SKILL.md: https://api.skillmd.com/api/skills/serejaris/kimi-widget/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Design & Media
- Author: serejaris (https://skillmd.com/u/serejaris)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/serejaris/kimi-widget

---


# 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](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](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.