How to make Kimi better at UI design

To make Kimi better at UI design, define the product workflow before asking for code. Give Kimi durable repository rules, one reusable UI skill, a focused set of InterfaceKit references, and screenshots of the running result. Then make it plan, build, and review the interface in separate passes.

Kimi Code CLI is a practical surface for this work because it can read and edit a repository, run shell commands, reference project files, and accept images in its terminal interface. It still cannot decide what your product should do from a vague prompt. You must supply the user, content, actions, states, and definition of done.

This Kimi UI design tutorial uses a workspace usage and limits page as its example. The Kimi-specific commands and file formats below were checked against the official documentation. Kimi Code CLI is not installed in our current test environment, so we did not run this exact workflow end to end. Test it in your project before treating it as a team standard.

What you will build

The finished page lets a workspace owner:

1. See current monthly usage and the billing period.
2. Understand which products are using the allowance.
3. Set a warning threshold.
4. Prevent an accidental second save while the first request is pending.
5. Recover from loading, permission, and request errors.

The page must also handle a new workspace with no usage, a workspace near its limit, a limit already exceeded, long product names, and narrow screens.

This is a useful test for Kimi AI UI design because it combines data, settings, permissions, feedback, and responsive behavior. It cannot be solved by styling one dashboard card.

Before you start

You need:

• Kimi Code CLI installed and authenticated
• a frontend repository that runs locally
• the route and data flow for the target feature
• the project’s development, lint, type, test, and build commands
• realistic data or fixtures for every required state
• one relevant system from the InterfaceKit library
• a way to capture the page at 1440px, 768px, and 390px

Check the installed version, move to the project root, and start Kimi:

kimi --version
cd /path/to/your-project
kimi

Replace /path/to/your-project with the real repository path. If this is the first launch, run /login inside Kimi and follow the authentication flow.

Kimi asks before file writes and shell commands by default. Read each approval instead of switching to an unattended mode for an unfamiliar repository.

Step 1: Write the product contract

Do not start with “make a modern usage dashboard.” Write the decisions the interface must express:

Route: /settings/usage
User: A workspace owner managing monthly product usage
Outcome: Understand current usage and set a warning threshold
Primary action: Save warning threshold
Secondary action: View usage details
Data:
- Current usage
- Monthly allowance
- Billing period
- Product
- Product usage
- Warning threshold
- Last updated time
Rules:
- Only workspace owners can change the threshold
- Threshold must be between 50% and 100%
- Saving cannot submit twice while the request is pending
- Read-only members can inspect usage
Required states:
- Loading
- No usage
- Normal usage
- Near limit
- Limit exceeded
- Request error
- Save pending
- Save success
- Save error
- Permission denied
Breakpoints: 1440px, 768px, 390px
Must preserve: Existing routes, API contracts, analytics, and keyboard behavior

The contract gives Kimi product facts instead of visual guesses.

Step 2: Define what done means

Turn the contract into checks before any code changes:

• Current usage, allowance, period, and warning threshold are easy to scan.
• The interface explains the difference between an allowance and a warning threshold.
• Normal, near-limit, and exceeded states do not rely on color alone.
• Product usage adds up to the displayed total or explains why it does not.
• The save action names what will change.
• A pending save cannot submit twice.
• Read-only users understand why editing is unavailable.
• Loading, empty, error, pending, and success states are reachable.
• Long product names and large values do not break the layout.
• The complete workflow works with a keyboard.
• Information priority survives all three target widths.
• Project checks pass.

These are observable outcomes. “Looks polished” is not.

Step 3: Put stable rules in AGENTS.md

Use AGENTS.md for rules that should apply to future work in the repository. Kimi Code’s own GitHub repository uses a root AGENTS.md and more specific nested files, which is a useful pattern for agent-assisted projects.

Add a short root file, or extend the one the repository already has:

# Frontend UI

- Inspect existing components before creating new ones.
- Use tokens from `src/styles/tokens.css`.
- Do not add a UI or icon library without approval.
- Preserve route, data, analytics, and accessibility behavior.
- Make loading, empty, error, success, disabled, and permission states reachable.
- Review changed UI at 1440px, 768px, and 390px.
- Keep temporary review screenshots out of version control.
- Run `npm run lint`, `npm run test`, and `npm run build` before finishing.
- Report checks, renders reviewed, deliberate deviations, and remaining gaps.

Replace the paths and commands with the project’s real values.

For a monorepo, add a smaller AGENTS.md inside the frontend application:

# Web application

- Routes live in `src/routes`.
- Reuse components from `src/components`.
- Use the existing fixture system for visual states.
- Keep desktop, tablet, and mobile behavior in the same component.
- Review the running route before reporting completion.

Tell Kimi to read the applicable files at the start of the task. Do not assume a file name alone will repair missing product context.

Keep the current usage-page contract out of AGENTS.md. It belongs to this task, not every future task.

Step 4: Create a reusable Kimi UI design skill

Kimi Code CLI scans project skills from .kimi-code/skills/ and .agents/skills/. The shared .agents/skills/ path is useful when more than one coding agent works in the repository.

Create .agents/skills/ui-implementation/SKILL.md:

---
name: ui-implementation
description: Build or improve product UI with project components, focused references, reachable states, responsive renders, and evidence-based correction.
type: prompt
whenToUse: When implementing or correcting a product interface in this repository.
---

# UI implementation

1. Read the product contract and applicable `AGENTS.md` files.
2. Inspect the route, components, tokens, data conventions, and checks.
3. Map the supplied InterfaceKit references to existing project code.
4. List missing product decisions before editing.
5. Build the page frame and content hierarchy.
6. Implement the workflow and every required state.
7. Apply foundations through the existing token system.
8. Run the app and review 1440px, 768px, and 390px.
9. Compare structure, hierarchy, density, components, states, and styling.
10. Fix concrete differences and rerender.
11. Run project checks and review the diff.
12. Report evidence, deliberate deviations, and remaining gaps.

Do not add product sections, component libraries, or visual foundations that
are not supported by the task, repository, or supplied references.

Kimi’s official Agent Skills documentation requires name and description in a directory-form SKILL.md. It also explains project skill paths and manual invocation.

Start a new Kimi session after adding the skill, then invoke it with:

/skill:ui-implementation

Kimi can also select a skill from its description. Explicit invocation removes doubt when the workflow matters.

Step 5: Choose one InterfaceKit system

Choose an InterfaceKit system with settings, usage, or account-management patterns close to the page you are building.

Collect only the references the task needs:

Use one coherent system. Mixing unrelated screenshots can give Kimi conflicting rules for density, radius, spacing, and hierarchy.

If a reference contains data your product does not have, copy its layout logic, not its content. If your product needs a state the reference does not show, ask Kimi to extend the existing component pattern and report the new variant.

Step 6: Use Plan mode before editing

Kimi Code CLI has a Plan mode that produces a plan and waits for approval before changing files. Toggle it with Shift-Tab or /plan.

Enter Plan mode, invoke the skill, and reference exact files with @:

/plan

/skill:ui-implementation

Read @AGENTS.md, @src/routes/settings/usage.tsx,
@src/components/settings/, @src/styles/tokens.css, and the supplied product
contract and InterfaceKit references.

Do not edit yet.

Map each product requirement to current code and a selected reference.
List missing decisions, reusable components, required fixtures, affected tests,
and the commands needed to run and verify the route.
Return a four-pass implementation plan with a review stop after each pass.

Kimi’s interaction guide documents Plan mode and @ file completion. Select files from the completion menu so Kimi receives the intended paths.

Review the plan before approving it. Reject or revise a plan that:

• adds product sections not found in the contract
• creates new components before inspecting existing ones
• treats the happy path as the whole feature
• changes data behavior during a visual task without a reason
• postpones responsive behavior until the end
• has no rendered review step

Step 7: Build the UI in four passes

Pass 1: Structure

Build the settings frame, page header, summary hierarchy, product breakdown, and threshold section.

Review:

• heading and action order
• content grouping
• reading width
• desktop and mobile region changes
• whether the primary action belongs where Kimi placed it

Do not spend this pass tuning shadows and colors.

Pass 2: Behavior

Connect the real data and save flow. Preserve API contracts, validation, analytics, permissions, and keyboard behavior.

Review:

• what can be edited
• what happens while saving
• how validation is explained
• whether read-only members can still understand usage
• whether focus moves or returns correctly after feedback

Pass 3: Reachable states

Add fixtures, story routes, query parameters, or the project’s normal test controls for every required state.

Use a state matrix:

If a state cannot be opened on demand, the review is incomplete.

Pass 4: Visual correction

Apply the selected InterfaceKit foundations and compare the running page with the references.

Ask Kimi to report differences in this order:

1. Structure
2. Hierarchy
3. Density
4. Component shape
5. Typography
6. Spacing
7. Color, border, and radius

This order prevents surface polish from hiding a weak product layout.

Step 8: Paste screenshots into Kimi

Kimi Code CLI accepts pasted images and video when the active model supports that media type. On macOS and Linux, paste media with Ctrl-V. On Windows, use Alt-V.

Capture the same populated state at 1440px, 768px, and 390px. Paste the three renders with the matching InterfaceKit references and use this Kimi UI design review prompt:

Review the rendered usage page against the product contract and supplied
InterfaceKit references.

Compare structure, hierarchy, density, components, typography, spacing, color,
borders, radius, responsive behavior, and state clarity.

List issues by product impact before editing. For each issue, name the evidence
in the render or reference. Fix the high-impact issues, preserve data behavior,
rerun the page at all three widths, and report what changed.

Do not ask whether the page “looks good.” Ask for differences tied to evidence.

Then review narrow layouts with repeated checks:

Repeat the review with no usage, limit exceeded, save error, and permission denied. A clean populated screenshot does not prove the workflow is complete.

Step 9: Use a goal for final verification

After you approve the implementation passes, give Kimi a bounded goal:

/goal Verify /settings/usage at 1440px, 768px, and 390px for normal usage, no usage, limit exceeded, save error, and permission denied. Fix confirmed regressions without changing the approved product contract, run the project checks, and report the evidence and any remaining gaps.

Kimi’s Goals documentation recommends an objective with a clear finish line and evidence. Goal mode can continue across turns as Kimi finds and fixes issues.

Use /goal for this bounded verification pass, not for an open request such as “make the whole app better.” Keep human review stops during the earlier design work.

How to design better UI with AI

To design better UI with AI, separate product decisions from implementation. Define the user, outcome, content, actions, rules, and states first. Supply one coherent interface system. Then review the working page at real breakpoints and correct differences with visible evidence.

This method applies beyond Kimi. The AI should help inspect, build, and verify the interface. It should not invent missing product requirements and silently turn them into code.

How to use Figma with Kimi

If you searched for how to make Kimi better at UI design in Figma, treat Figma as a source of design decisions unless your Kimi environment has a verified Figma integration.

Provide:

• the exact frame or flow, not a whole unsorted file
• exported screenshots at the intended viewport
• component names and variants
• typography, spacing, color, and radius variables
• interaction notes for overlays, focus, validation, and responsive changes
• the source-code files that should receive the implementation

Ask Kimi to map Figma components to existing code before editing. A screenshot can show appearance, but it does not expose every variable, reusable component, state, or interaction. Do not claim a design-to-code handoff is complete until the running page preserves both the design system and product behavior.

Is Kimi good for web development?

Kimi Code CLI can be good for web development when the task is grounded in a real repository and has checks it can run. Its official documentation says it can read and modify code, run shell commands, search files, fetch pages, and plan work.

That capability does not guarantee good UI. Judge Kimi on:

• how well it understands the existing code
• whether it reuses the component system
• whether the implementation works
• whether all product states are reachable
• whether responsive behavior preserves priority
• whether visual corrections match evidence
• whether tests and builds pass
• whether the same rules hold on a second route

The right Kimi UI design review covers code, behavior, and rendered output. A first screenshot is only one piece of evidence.

What about Kimi K2 UI design?

Model names change faster than a repository’s design rules. If you are evaluating Kimi K2 UI design or another current Kimi model, record the model and Kimi Code version used for the test. Then run the same product contract, reference map, state matrix, breakpoints, and project checks.

A stronger model may follow context or images better, but the model name does not replace missing requirements or verification. Use Kimi’s /model control to inspect the choices available in your installed version instead of hard-coding one model into the team workflow.

Where to find Kimi UI design examples on GitHub

The official MoonshotAI Kimi Code repository on GitHub is the best primary source for Kimi Code itself. Its repository also shows real AGENTS.md and .agents/skills/ conventions.

For UI examples in other repositories, inspect more than the final screenshot. Look for:

• the product contract or issue
• the source components and tokens
• fixtures for non-happy states
• responsive behavior
• tests and build output
• screenshots from the actual application

A “Kimi UI design GitHub” example without those artifacts cannot show whether Kimi preserved the product or only produced a convincing image.

Kimi UI verification checklist

• The exact Kimi surface and version are recorded
• One product workflow and user outcome are defined
• Stable repository rules live in the right AGENTS.md
• The Kimi UI skill loads with /skill:ui-implementation
• One coherent InterfaceKit system is mapped to product needs
• The plan was reviewed before implementation
• Structure, behavior, states, and polish were separate passes
• Every required state can be opened on demand
• 1440px, 768px, and 390px renders were reviewed
• Accessibility and keyboard behavior were checked
• Project checks pass
• Deliberate deviations and remaining gaps are reported

Use How to prompt AI for UI design when the product contract still needs work. Use How to make UI not look AI-generated to repair an existing interface.

For another coding tool, follow the comparable workflow for Claude, Codex, Gemini, or Cursor.