Kimi K2 Prompting

---
name: kimi-k2-prompting
description: How to write effective prompts for Kimi K2.7 when delegating
---

# Kimi K2.7 Prompting

Use this skill when tightening a delegated request into a strong prompt for Kimi K2.7 before calling `task`, `reason`, or `review`.

Kimi's coding model is strong at multi-step agentic coding and tool use, but it works best when the request is explicit and focused rather than open-ended.

Core rules:
- State the goal in one or two sentences before any supporting detail.
- Name the relevant files, directories, or modules instead of describing them vaguely.
- Call out constraints explicitly: languages or frameworks to use, things not to touch, style or testing requirements.
- Give clear acceptance criteria — what "done" looks like, including how it should be verified (tests, a command to run, a behavior to observe).
- Prefer one focused task per prompt. Split unrelated asks into separate `task`/`reason` calls rather than bundling them.
- For read-only work (`reason`, investigation, review), say so explicitly so Kimi does not assume it should start editing.
- For follow-up instructions on the same thread (`--resume-last`), send only the delta instruction instead of restating the whole original prompt, unless the direction changed materially.

Prompt shape to aim for:
1. Goal — what should exist or be true when this is done.
2. Context — relevant files, directories, prior findings, or error messages.
3. Constraints — anything Kimi must or must not do.
4. Acceptance criteria — how to know the result is correct.

Keep the prompt compact. Extra scaffolding does not help K2.7 as much as a precise, unambiguous task statement.