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 connects to Kimi CLI's Wire mode — an experimental streaming protocol that gives full programmatic access to a Kimi agent session. 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 and session resume.

• 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 CLI over stdio.
• Full agent capabilities. Kimi can read files, write code, run shell commands, and resume where it left off — all bounded by a companion-side approval allowlist that the plugin enforces.

Try it in 60 seconds

/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 structured findings:

{
  "summary": "One high-confidence issue in the auth middleware.",
  "verdict": "concern",
  "findings": [
    {
      "severity": "high",
      "confidence": "high",
      "title": "JWT expiry not checked before token refresh",
      "file": "src/middleware/auth.ts",
      "start_line": 42,
      "end_line": 47,
      "body": "The refresh handler calls getNewToken() without first checking whether the current token has actually expired...",
      "suggested_fix": "Add an expiry check before the refresh call."
    }
  ]
}

Claude reads these findings and can act on them directly. 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
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.

  /kimi:review "check the auth flow"
       │
       └─ companion.sh → node dist/companion.js
               │
               ├─ spawns: kimi --wire --session <uuid> --agent-file review.yaml
               ├─ streams JSON-RPC events over stdio (Wire protocol)
               ├─ turn capture: buffers ContentParts after last ToolResult
               ├─ approval dispatcher: auto-approves reads, allowlists writes
               ├─ persists job + event log to SQLite (node:sqlite, zero native deps)
               └─ returns structured result to Claude

Wire-first transport. The plugin implements a full Wire client in TypeScript — JSON-RPC over stdio with start, initialize, prompt, approval dispatch, turn capture, and close-based exit semantics. Each command mode runs a custom Kimi agent profile (--agent-file) that controls which tools Kimi has access to. This is one of the first third-party consumers of Kimi CLI's Wire protocol.

Job lifecycle. Every job gets a client-assigned UUID, a SQLite record (created before the Wire connection opens), and a full event log. Jobs go through running → completed/failed/cancelled. Use /kimi:status, /kimi:result, /kimi:cancel, /kimi:replay to manage them.