The core value of Kimi Code CLI is that it constrains an AI coding assistant into a controllable execution agent. It primarily addresses three common pain points: forgotten rules, unsafe Git operations, and loss of control in complex tasks. This article distills its system instruction hierarchy, practical use of Plan Mode, and effective AGENTS.md patterns. Keywords: Kimi Code CLI, system instructions, AGENTS.md.
Technical Specification Snapshot
| Parameter | Details |
|---|---|
| Subject | Kimi Code CLI |
| Article Language | Chinese |
| Interaction Language Strategy | Follows the user’s language by default |
| Typical Runtime Environment | Windows / PowerShell |
| Key Mechanisms | System Instructions, Plan Mode, AGENTS.md |
| Git Safety Policy | Do not commit / push / rebase / reset without explicit authorization |
| Planning Artifact | plans/*.plan.md |
| Reference Protocol / Standard | MCP (Model Context Protocol) |
| Official Reference | moonshotai.github.io/kimi-cli/zh/ |
| Repository Star Count | Not provided in the source |
| Core Dependencies | Processing 4.5.2, JDK 17, jorbis, tritonus, vorbisspi (example project) |
The key challenge in Kimi Code CLI is not capability, but making constraints stick reliably
For many developers using AI coding assistants, the real pain is not weak code generation. The real issue is that rules do not keep applying consistently. You may instruct the assistant not to push to the main branch, to reply in Chinese, or to follow the project’s coding style, but as the conversation grows longer, the AI often starts to drift.
This behavior usually does not mean the model has completely forgotten everything. More often, it reflects the fact that platform-injected system instructions, project-level rules, and the current conversational context exist at different priority levels. Understanding that hierarchy is the prerequisite for using Kimi Code CLI reliably.
System instructions are platform-injected behavioral boundaries
System instructions are not ordinary chat messages. They are low-level constraints injected when the session starts. They behave more like runtime governance rules that define the AI’s default behavior for tool usage, Git operations, task decomposition, and response language.
The original source emphasizes an important fact: the AI cannot print the full system instructions the way it can export a file. It can only describe the constraints it is currently able to perceive. What we see is therefore a behavioral projection, not the platform’s source-level truth.
The priority order can usually be understood as:
1. The user's current explicit instruction
2. Rules defined in the project's AGENTS.md
3. The platform's default system instructionsThis hierarchy explains why saying something once earlier in the session does not always mean it will remain effective forever.
Git safety constraints are among the most stable high-priority rules in Kimi Code CLI
Kimi Code CLI applies a conservative default policy to Git-changing operations. Without explicit user authorization, the AI should not run commands such as commit, push, reset, or rebase, because they can be destructive or irreversible.
The design goal is clear: restrict the AI to a boundary where it may modify the working tree, but must not change version history on its own. This is safer for team collaboration, branch protection, and auditability.
# Incorrect example: pushing directly without authorization
# The AI should not proactively execute commands like these
git add .
git commit -m "fix: update logic"
git push origin mainThis command chain is sensitive because it directly crosses the line between generating suggestions and changing team reality.
Plan Mode makes complex tasks go through design before execution
For non-trivial tasks, Kimi Code CLI tends to enter Plan Mode first. In this mode, it explores the codebase and requirements, creates a plan file, and waits for user approval before proceeding. In essence, it adds a blueprint review step for the AI.
The source notes that plans are typically persisted as .plan.md files under the plans/ directory. Unlike pure chat context, these files do not disappear immediately because of context compression, which makes them well suited to serve as intermediate contracts for complex changes.
# plans/refactor-auth.plan.md
## Goal
Refactor the authentication module without directly modifying the main flow
## Steps
1. Scan the call chain first <!-- Confirm the impact scope -->
2. Design an interface compatibility layer <!-- Reduce change risk -->
3. Replace the implementation in batches <!-- Make rollback easier -->
4. Wait for user confirmation before executionThe purpose of this plan file is to turn “how to change the system” into a reviewable artifact, instead of letting the AI rush straight into the code.
AGENTS.md is currently the most practical project-level rule injection point
In the absence of a mature global project rules center, AGENTS.md is the mechanism that comes closest to a project-level governance entry point in Kimi Code CLI. It can live in different directories, and deeper files can override parent-level rules, which makes it suitable for monorepos and multi-module repositories.
This means you can encode coding style, architectural boundaries, Git workflow, comment language, and similar conventions into a project contract. During long sessions, you can repeatedly instruct the AI to reread this file to resist context dilution.
# AGENTS.md
## Coding Standards
- New code must be compatible with JDK 17 # Standardize the runtime
- Use Chinese for comments and English for variables # Improve collaboration consistency
## Git Rules
- Generate a commit message draft first
- Do not push to main without confirmation
## Architecture Constraints
- The render loop may only exist inside a PApplet subclassThe value of this file does not come from formal correctness alone. Its real strength is that every session can reread it, verify it, and override it where needed.
System instructions and environment information must be kept strictly separate
One of the most valuable judgments in the source is this: system instructions are behavioral constraints, while environment information is state description. For example, PowerShell, Windows, JDK 17, and the current directory are environment details. In contrast, rules such as “use tools by default” or “reply in the same language as the user” are actual instructions.
If you do not separate these two categories, it becomes easy to misdiagnose why the AI behaved unexpectedly. Most so-called forgotten rules are actually caused by project state being compressed in a long conversation, not by the complete failure of the underlying system instructions.
When AI forgets rules, the usual cause is context dilution, not deliberate disobedience
Context windows are finite, and platforms compact conversations over time. System instructions usually remain because their position is stable, but project structure, temporary notes, and your spoken coding preferences are often summarized or even dropped.
As a result, the best practice for stable collaboration is not to keep complaining that the AI has a bad memory. Instead, write high-value rules into files, require secondary confirmation for high-risk actions, and convert complex tasks into a plan review workflow.
A recommended collaboration loop
def ai_workflow(task_complexity, has_agents_md):
if task_complexity == "high":
return "Generate a plan file first and wait for confirmation" # Plan complex tasks before execution
if has_agents_md:
return "Read AGENTS.md before execution" # Load project rules first
return "Reconfirm key constraints before execution" # Avoid context driftThis pseudocode captures the minimum viable process for reliable AI coding collaboration: plan complex tasks first, read rules before project work, and confirm high-risk actions in advance.
The most effective workaround today is to turn rules into files, workflows, and repeatable inputs
If your goal is to make Kimi Code CLI behave more like a team member than a one-off script generator, use a three-layer strategy: understand the default constraints at the platform layer, codify project rules in AGENTS.md at the project layer, and keep refreshing critical constraints at the conversation layer.
For more complex scenarios, you can also use MCP to integrate custom tools such as a get_project_rules interface into the workflow, so project conventions are actively injected at the start of each task. This is more reliable than depending entirely on chat memory.
FAQ
Q: Why does the AI still drift later even after I already said “do not push”?
A: Because verbal constraints are easy to lose during context compression. You should write the rule into AGENTS.md and require the AI to reread the file before high-risk steps.
Q: When is Plan Mode most worth enabling?
A: You should enable it when the task involves cross-module refactoring, architecture changes, bulk replacement, or any modification with a high rollback cost. Generate plans/*.plan.md first, then execute.
Q: Can AGENTS.md completely replace system instructions?
A: No. System instructions are platform-wide constraints, while AGENTS.md is a project-level supplement. Effective behavior depends on layered priority, not single-point replacement.
Core summary: This article reconstructs the key mechanisms behind Kimi Code CLI system instructions, with a focus on Git safety constraints, Plan Mode, tool usage norms, and AGENTS.md project rules. It explains why AI appears to “forget” instructions and offers an executable collaboration model at the project level.