Kimi CLI for design.

What Kimi CLI actually is

Kimi CLI is an open-source (Apache-2.0) AI agent that Moonshot AI ships for the terminal. It reads your repository, edits files, runs shell commands, searches files, fetches web pages, and chooses its next step from the feedback it gets — planning and verifying work from natural-language tasks rather than just completing lines. It is a Python tool, installed with uv, and it drives the Kimi K2 model family behind the scenes.

For design work, two properties stand out. The Kimi K2 models are explicitly tuned for agentic, long-horizon coding and tool use, so the agent can carry a multi-step build through to a working result. And the context window reaches up to 256k tokens on recent K2 releases, large enough to hold your whole design system, component library, and reference set at once instead of summarizing them away.

• Context files: Kimi CLI reads an AGENTS.md file for persistent project context — the natural place to encode your design conventions, tokens, and review checklists. Run /init to scaffold one for a project that does not have it.
• MCP, ACP + subagents: It manages MCP servers conversationally with /mcp-config, exposes a session over the Agent Client Protocol (kimi acp) to Zed and JetBrains, and can dispatch built-in coder, explore, and plan subagents in isolated contexts.
• Login or BYOK: On first launch, /login lets you authorize via OAuth (Kimi Code) or enter your own Moonshot API key; Kimi’s platform also exposes OpenAI- and Anthropic-compatible endpoints.

• Vendor: Moonshot AI
• Credential: Moonshot API key (BYOK), or OAuth login via Kimi Code
• License: Apache-2.0, open source

Why agentic K2 models and a large context fit design

Kimi CLI’s design edge comes from two model properties — but, as with every agent, taste still has to be supplied.

• Agentic, long-horizon coding: The Kimi K2 models are optimized for tool use and multi-step work, so the agent can take a reference and a brief and actually build, run, and refine the UI rather than stopping at a first draft.
• A large context window: Up to 256k tokens on recent K2 releases means the whole design system, tokens, and many reference states fit at once, so the agent reuses your real primitives rather than inventing one-off styles.
• Conventions in AGENTS.md: An AGENTS.md (plus an MCP server like Figma) points the agent at your tokens, components, and real specs, so it works against a brand instead of a default look.

The lesson is the same one every agent teaches: Kimi CLI does not have taste by default. It produces good design when you give it constraints — a design system, an aesthetic skill, and concrete references. Open Design packages exactly those inputs, which is why the two fit together (more below).

Set up Kimi CLI for design work, from zero

Here is the full path from a clean machine to a Kimi CLI that can build and verify UI.

# 1. Install Kimi CLI (uses uv; Python 3.12–3.14, 3.13 recommended)
curl -LsSf https://code.kimi.com/install.sh | bash
# or, if you already have uv:
uv tool install --python 3.13 kimi-cli

# 2. Start it in your project and authenticate on first run
cd your-project
kimi              # then run /login: OAuth via Kimi Code, or paste a Moonshot API key

# 3. Generate project context
/init             # scaffolds an AGENTS.md for this project

# 4. Wire an MCP server (optional, e.g. Figma for design handoff)
/mcp-config       # add, edit, and authenticate MCP servers conversationally

• Encode your design rules: Put your tokens, primitives, and conventions in AGENTS.md and point Kimi at them, so output matches a brand instead of defaulting to a generic look.
• Add browser verification: Wire a Playwright or browser MCP so Kimi renders in a real browser and checks its output across breakpoints instead of only confirming the build passes.

The reference-to-UI workflow

The highest-leverage design loop with Kimi CLI is turning reference material into working, responsive UI and iterating until it matches — feeding the agent your references and having it compare its rendered output back to them in a real browser.

1. Start from the clearest references you have — and include multiple states (desktop and mobile, hover, empty, loading), not just one hero shot.
2. Be specific in the prompt; vague prompts produce generic UI even with a strong agent.
3. Keep your design system and conventions in AGENTS.md, and tell Kimi where the tokens and canonical primitives live.
4. Run a dev server and have Kimi render in a real browser, resizing to breakpoints to check the result.
5. Iterate by having Kimi compare its implementation back to the references — not merely confirm it builds.

Point Kimi at your references and the dev server, then give concrete constraints:

kimi
# in the prompt:
> Implement the design in ./references (reference-desktop.png,
  reference-mobile.png) using React + Vite + Tailwind + TypeScript.
  Reuse my existing design-system components and tokens from AGENTS.md.
  Match spacing, layout, and hierarchy; make it responsive.
  Run the dev server, render it in the browser, and iterate until it
  matches the references across breakpoints.

Keep prompts small and focused, commit good iterations and revert bad ones (telling Kimi when you revert), so each pass builds on a clean base. Kimi CLI can also take a short screen recording or demo clip when a flow is hard to describe in words.

AGENTS.md, MCP, and subagents

Three extension points make Kimi CLI practical for sustained design work, and all three map cleanly onto an open design workflow.

• AGENTS.md context: Project rules live in an AGENTS.md at the repo root. It is the durable home for your design conventions, read on every run — and it is the same portable format other agents use.
• MCP servers: Add MCP servers conversationally with /mcp-config — the portable way to bring in design context and external tools, most relevantly the Figma MCP server, that work across agents, not just Kimi.
• Subagents and the plugin marketplace: Dispatch built-in coder, explore, and plan subagents in isolated contexts, and install skills, MCP servers, and data sources from the marketplace or any GitHub repo to gather references and run the verification loop.

These are portable, multi-agent capabilities — exactly the kind of thing Open Design is built to orchestrate, rather than re-create per project.

Kimi CLI vs Codex vs Claude Code vs Cursor vs Gemini CLI for design

There is no single winner for design work — each agent has a different strength, and experienced teams stack them. A fair summary:

The recurring community verdict is that taste comes from humans: all of them default to a generic aesthetic without skills, references, and constraints. That is the real problem to solve — and it is design-tool-shaped, not model-shaped.

Pitfalls, and how to avoid the “AI slop” look

The most common complaint about AI-generated design is that it looks generic — soft gradients, floating panels, oversized rounded corners, dramatic shadows, an Inter-and-purple vibe that “screams an AI made this.” Other reported issues include broken mobile layouts and instructions leaking into UI copy. None of these are unique to Kimi CLI; they are what happens when any agent runs without a curated design context.

• Add an aesthetic skill: A curated design skill forces the agent to commit to a real direction instead of the default look.
• Verify in a real browser: Have Kimi render and self-check across breakpoints so layouts do not silently break on mobile.
• Supply tokens and references: Real design tokens and reference screenshots are the single biggest lever on output quality.
• Encode rules in AGENTS.md: Put “no hero cards, max two typefaces, brand-first hierarchy” style rules where the agent reads them every run.

Notice that every mitigation is about giving the agent a curated design context. Maintaining that context by hand, per project, is the toil Open Design removes.

Designing with Kimi CLI inside Open Design

Open Design is the open-source design layer the workflow above keeps asking for. It treats Kimi CLI as a first-party adapter and wraps it in a curated skill and design-system library, a structured render pipeline, and a local desktop UI — so the design context that makes Kimi good is there from the first run, not assembled by hand each time. Both are open-source and local-first, which makes the pairing a natural fit.

1. Install Open Design and select Kimi CLI as your agent.
2. Authenticate with your Moonshot API key (BYOK) — credentials stay on your machine and are never proxied through us.
3. Pick a design system and a skill, then generate decks, prototypes, and landing pages with consistent taste.
4. Every artifact and DESIGN.md file lives in your own repo, not a hosted cloud.

Same Kimi CLI agent, same key — plus a real, portable, open-source design workflow around it. It is local-first and Apache-2.0, so nothing about your work or your credentials leaves your machine.

Frequently asked questions

1. 01 Can Kimi CLI really do design work? +

   Yes — with an aesthetic skill, a design system, and real reference images in context, Kimi CLI produces production-quality, responsive UI, and its agentic Kimi K2 models can render and verify output against references. Without that context it tends to default to a generic look, which is the gap Open Design fills.

2. 02 Do I need to pay to design with Kimi CLI? +

   You bring your own credentials: authorize via the Kimi Code OAuth login or paste a Moonshot API key (BYOK), billed by Moonshot’s platform. Open Design never proxies your credentials either way.

3. 03 What makes Kimi CLI good for design specifically? +

   Two things: the Kimi K2 models are tuned for agentic, long-horizon coding and tool use, so the agent can build and refine through to a working result, and the context window reaches up to 256k tokens, enough to hold a whole design system and reference set at once. Both help — but taste still comes from the design system, skill, and references you supply.

4. 04 Kimi CLI or Claude Code for frontend design? +

   Both are strong. Claude Code is known for specific, codebase-aware design decisions; Kimi CLI’s edge is its agentic Kimi K2 models and a large context with BYOK economics. Many teams use both — Open Design lets you switch agents without changing your design workflow.

5. 05 How do I connect Kimi CLI to Figma? +

   Run /mcp-config inside Kimi CLI to add and authenticate the Figma MCP server. Kimi can then pull real design context — components, variables, layout data — so the generated code matches the source instead of approximating it.

6. 06 Is Open Design affiliated with Moonshot AI? +

   No. Kimi CLI is a product of Moonshot AI; Open Design is an independent open-source project that supports it as a first-party adapter. Kimi is a trademark of Moonshot AI.

7. 07 Are my files and credentials safe? +

   Yes — Open Design is local-first and Apache-2.0. Your files, artifacts, and DESIGN.md stay in your own repo, and your Moonshot credentials are used directly by your agent, never routed through Open Design servers.