kimi-swarm-write

kimi:swarm --write

Forward a write-capable parallel fan-out to the shared companion runtime and return the result verbatim. Kimi's AgentSwarm tool spawns coder subagents that edit disjoint targets inside an ephemeral throwaway git worktree off HEAD; the plugin captures the change set as a reviewable .patch and prints its path. The user's real working tree is never touched, and the main thread owns the merge — the plugin never applies or commits.

Runtime instructions

When invoked:

• confirm BOTH signals are present before dispatching: (1) MANY disjoint WRITE targets and (2) an explicit request to fan the edits out in parallel. If the user wants a single edit, use kimi-rescue; a read-only fan-out, kimi-swarm; an autonomous multi-turn loop, kimi-pursue. When in doubt, prefer kimi-rescue — do not shard one task into a swarm
• preserve the user's objective and the disjoint target list with minimal reframing; partition into NON-overlapping targets (the subagents edit in one shared worktree, so overlapping targets can clobber each other)
• call the shared companion runtime with exactly one Bash invocation: ${CLAUDE_PLUGIN_ROOT}/scripts/companion.sh task swarm --write <args> (the --write flag is REQUIRED — this agent is the write path)
• the companion accepts a strict allowlist of flags: --budget <duration> (HARD wall-clock ceiling; e.g. 30m, 1h, 90s; bare number = minutes; default 30m, max 24h), --cap <N> (SOFT total-subagent-count hint injected into the coordinator prompt — advisory, the hook is stateless and can't count subagents), --max-concurrency <N> (HARD ceiling on concurrent subagents on kimi-code 0.18.0+; defaults to 1 for --write — writes serialize because disjoint-target partitioning is prompt-only), and -m/--model <name>. Everything else is trailing objective text. Kimi's extended reasoning is always on; the parser hard-rejects --thinking/--no-thinking
• do not invent flags. The runtime hard-fails with INVALID_ARGS on unknown flag-shaped tokens — pass -- before flag-shaped objective text to forward it as objective text rather than a flag
• this is write-capable, but the blast radius is bounded by construction — and PATCH-ONLY is the load-bearing safety property. Every edit happens in an ephemeral worktree off HEAD; the coder subagents fire the index-0 PreToolUse hook on every tool call (the swarm-write label routes write/edit/shell through the rescue allowlist, scoped to a forge-proof trusted worktree root — not the payload cwd), so writes are confined to that worktree and out-of-worktree writes + git mutation are denied. The result is a .patch the user reviews and applies themselves — the plugin never applies or commits, and the user's real tree is never touched. Always pass an explicit --budget sized to the task (keep it at or below 30m unless the user named a larger window) and an explicit --max-concurrency (leave at 1 unless the user asks to parallelize writes and the targets are provably disjoint). Never try to remove these bounds
• swarm-write bases the worktree on HEAD: uncommitted changes are NOT included. If the user has a dirty tree the runtime warns; surface that and suggest committing or stashing first if the swarm needs those changes
• swarm-write is foreground-only at the runtime level — --background, --wait, --fresh, and --resume are rejected with INVALID_ARGS. How you make the Bash call is a separate question: default to run_in_background: true. A fan-out routinely outlives a foreground shell timeout (Claude Code caps foreground Bash at 10 minutes; --budget defaults to 30m), and detaching costs nothing here because the run is patch-only and worktree-confined — it cannot reach the user's tree whether or not anyone is watching. Keep --budget and --max-concurrency finite; never make a detached run open-ended
• the user should never have to type a job id (it is a raw UUID), and you will not have one either — a detached run prints nothing at launch; the job id only reaches you with the final report. So cancel by omitting it: ${CLAUDE_PLUGIN_ROOT}/scripts/companion.sh cancel targets the latest RUNNING job for this repo (findLatestJob({runningOnly:true})), which is the run you just launched. Pass an explicit id only if you already have one from a completed report. Note the ambiguity: with two runs in flight, the no-id form takes the most recent — if the user has more than one going, confirm which they mean before cancelling
• prefer companion.sh cancel over an Esc/interrupt, and say so if the user asks how to stop it. A harness interrupt gives the companion only ~1.35s before SIGKILL (measured), which is less than its own 1500ms child-escalation plus quiescence plus git diff --binary patch capture — so interrupting can kill the run mid-teardown and lose the patch. The cancel command signals the job from a separate process that is not racing that deadline, so teardown completes and the partial patch survives
• swarm-write REFUSES without the /kimi:setup PreToolUse hook (a write fan-out with no per-subagent enforcement is an N-fold blast radius). If the companion refuses, surface that and tell the user to run /kimi:setup; do not reach for KIMI_PLUGIN_CC_SKIP_HOOK_CHECK
• requires kimi-code >= 0.18.0 (the hard concurrency cap) and a git repo with a committed HEAD — surface WRITE_SWARM_NOT_A_REPO / WRITE_SWARM_NO_HEAD plainly if the runtime reports them
• /kimi:result <jobId> --json returns a structured envelope with metadata plus the artifact body.