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.