Daniil
111 lines
4.7 KiB
Markdown
111 lines
4.7 KiB
Markdown
---
|
|
name: kimi
|
|
description: Use Kimi Code CLI as a design partner for web design decisions, UI direction, frontend visual critique, redesigns, layout, typography, color, spacing, interaction states, responsive behavior, screenshots, mockups, landing pages, dashboards, and overall design judgment. Use before making web design decisions or designs overall, and when invoking Kimi Code non-interactively.
|
|
---
|
|
|
|
# Kimi Design Partner
|
|
|
|
Use Kimi as a second design brain before committing to visual direction or UI structure. The goal is sharper product decisions, not outsourcing implementation blindly.
|
|
|
|
## Default Workflow
|
|
|
|
1. Gather the design context first: user goal, audience, page or component purpose, existing design tokens, relevant files, screenshots, routes, constraints, and any brand/product references.
|
|
2. Ask Kimi for a focused design opinion before implementing a substantial UI, redesign, layout, visual system, or interaction pattern.
|
|
3. Ask for a critique pass after implementation when screenshots, browser state, or rendered UI are available.
|
|
4. Keep final decisions with the coordinating agent. Treat Kimi output as expert input to weigh against project constraints, existing code, accessibility, performance, and the user's latest request.
|
|
|
|
## Kimi CLI Usage
|
|
|
|
Prefer non-interactive mode for design consultation:
|
|
|
|
```bash
|
|
kimi --quiet -p "Act as a senior product/frontend designer. Review this UI direction and return concise recommendations..."
|
|
```
|
|
|
|
Use `--print` when you want visible intermediate output or streaming:
|
|
|
|
```bash
|
|
kimi --print -p "Review the layout in src/widgets/Dashboard and recommend a cleaner information hierarchy." --final-message-only
|
|
```
|
|
|
|
Pass longer prompts through stdin to avoid shell quoting pain:
|
|
|
|
```bash
|
|
printf '%s\n' "Review this design direction. Context: ..." | kimi --print --final-message-only
|
|
```
|
|
|
|
Use JSONL for programmatic integration:
|
|
|
|
```bash
|
|
printf '%s\n' '{"role":"user","content":"Review this dashboard layout for hierarchy and density."}' \
|
|
| kimi --print --input-format=stream-json --output-format=stream-json
|
|
```
|
|
|
|
Helpful flags:
|
|
|
|
- `--work-dir PATH`: set the project root for file operations.
|
|
- `--add-dir PATH`: add extra workspace directories.
|
|
- `--skills-dir PATH`: set custom skills directories for Kimi; include every directory Kimi should see for that invocation.
|
|
- `--thinking`: enable deeper reasoning when the model supports it.
|
|
- `--output-format=stream-json`: stream JSONL output and avoid buffered text output.
|
|
- `--final-message-only` or `--quiet`: return only the final answer.
|
|
|
|
Be careful: Kimi docs describe print mode as non-interactive and auto-approving tool calls. For design advice, explicitly ask Kimi not to edit files unless that is intended. If tool safety must be enforced, use a restrictive Kimi agent file rather than relying only on prompt text.
|
|
|
|
## Prompt Shape
|
|
|
|
Give Kimi the decision boundary, not a vague taste test:
|
|
|
|
```text
|
|
Act as a senior product/frontend designer.
|
|
|
|
Task:
|
|
Decide the best UI direction for [page/component].
|
|
|
|
Context:
|
|
- Product/domain:
|
|
- Target user:
|
|
- Existing visual language:
|
|
- Files/routes/screenshots:
|
|
- Constraints:
|
|
|
|
Evaluate:
|
|
- Information hierarchy
|
|
- Layout density and rhythm
|
|
- Typography and spacing
|
|
- Color and contrast
|
|
- Interaction states
|
|
- Responsive behavior
|
|
- Accessibility risks
|
|
|
|
Return:
|
|
1. Recommended direction
|
|
2. Specific changes to make
|
|
3. Risks or tradeoffs
|
|
4. Anything to avoid
|
|
```
|
|
|
|
For implementation-ready feedback, ask Kimi to reference concrete files, components, CSS modules, tokens, or screenshots.
|
|
|
|
## Design Guardrails
|
|
|
|
- Prefer the repository's existing visual system, tokens, component patterns, and FSD boundaries.
|
|
- Ask for restrained, product-specific design decisions over generic "AI dashboard" moves.
|
|
- Request precise, implementable recommendations: spacing, hierarchy, component structure, responsive behavior, empty/loading/error states, and accessible affordances.
|
|
- For SaaS and operational interfaces, favor dense but calm scanning and repeated-use ergonomics over marketing composition.
|
|
- For landing pages or brand-first views, ask Kimi to evaluate first-viewport signal, imagery, hierarchy, and how the next section is hinted.
|
|
|
|
## Browser And Visual QA
|
|
|
|
Kimi Code can use skills, and Kimi can use the `agent-browser` skill when it is available. When rendered UI matters, include this instruction in the Kimi prompt:
|
|
|
|
```text
|
|
If you need to inspect the app visually, use the agent-browser skill to open the route, capture screenshots, and check desktop and mobile layouts before giving design feedback.
|
|
```
|
|
|
|
Use browser evidence when possible: screenshots, viewport sizes, route URLs, component names, and visible issues beat abstract description.
|
|
|
|
## Source Notes
|
|
|
|
Read `references/sources.md` when updating Kimi CLI flags, skill discovery behavior, or the prompting rules in this skill.
|