kimi

kimi-plugin-cc

Use Kimi as Claude Code's second reviewer, independent thinker, and delegated worker — without building your own multi-agent stack.

This is a Claude Code plugin that drives the kimi-code CLI (the Node.js successor to Kimi CLI) as a subprocess. Claude can ask Kimi for a structured code review, delegate a bug hunt, or have Kimi double-check its own work before stopping — all through slash commands, with persistent job state, session resume, and per-command safety enforced by a PreToolUse hook installed in ~/.kimi-code/config.toml.

• Independent model, independent perspective. Kimi reasons differently from Claude. A second opinion from a different model catches things self-review misses.
• No orchestration layer required. No ACP, no cloud broker, no shared API keys. The plugin talks directly to a locally-installed kimi binary using kimi -p --output-format stream-json.
• Full agent capabilities, safely bounded. Kimi can read files, write code, run shell commands, and resume where it left off — all bounded by a workspace allowlist invoked via the PreToolUse hook. Read-only commands enforce read-only at the hook layer, not the prompt.

Migrating from v0.4? v0.4.x targeted the Python Kimi CLI and stays available at the v0.4.0 tag (v0.4-maintenance branch is cut from that tag for ongoing fixes — see the linked tag if the branch is not yet pushed). v1.0 is a hard cut to kimi-code — install kimi-code first, then /plugin update kimi will upgrade you in place. See docs/migration.md for the step-by-step upgrade.

Try it in 60 seconds

# Prerequisite: install kimi-code from https://kimi.com/code/docs
/plugin marketplace add linxule/kimi-plugin-cc
/plugin install kimi@kimi-marketplace
/kimi:setup
/kimi:review "review my current diff"

Kimi reads your working-tree diff and returns a review as markdown:

## Verdict: concern

One high-confidence issue in the auth middleware; the rest looks fine.

### src/middleware/auth.ts:42-47 — JWT expiry not checked before token refresh

The refresh handler calls `getNewToken()` without first checking whether the
current token has actually expired. On a slow-clock client this triggers a
refresh on every request.

Suggested fix: add an expiry check before the refresh call.

Claude reads the review and can act on it directly. For programmatic access to the same content plus job metadata, companion.sh result <jobId> --json returns a structured envelope {job_id, kind, status, summary, error, artifact_path, body, ...} where body is the full markdown. To go further:

/kimi:rescue "fix the top review finding"

Kimi opens the file, writes the fix, runs the relevant tests, and reports back. The session persists — if you restart Claude Code, /kimi:rescue --resume picks up where it left off.

When to use what

Command	What it does	Kimi can write?	Session persists?
/kimi:ask	Free-form Q&A — "explain this module"; supports --background / --wait like rescue	No	Fresh by default, -r to resume
/kimi:review	Structured code review of your diff	No	Fresh each time
/kimi:challenge	Adversarial review with a custom focus	No	Fresh each time
/kimi:rescue	Delegate real work — bug hunts, refactors, fixes	Yes (allowlisted)	Persists + resumable
/kimi:pursue	Experimental — pursue an objective autonomously across turns, bounded by a hard --budget	Yes (allowlisted, every turn)	Foreground-only; resume not yet exposed
/kimi:swarm	Fan out a read-only review across files/modules in parallel (via AgentSwarm), bounded by a hard --budget	No (every subagent)	Foreground-only
Review gate	Kimi checks Claude's work before stopping	No	Per-stop-event

The plugin ships four Claude Code subagents that the main thread can dispatch proactively via the Agent tool: kimi-rescue (write-capable delegation), plus kimi-review, kimi-challenge, and kimi-ask (read-only forwarders to the matching companion surfaces). Each agent's description is Kimi's own statement of what it's good for — Claude matches the moment and dispatches; no prescriptive skill manual in between.

How it works

The architecture is modeled after OpenAI's codex-plugin-cc. Both follow the same pattern: thin plugin shell, rich local runtime, one process per job.