kimi-first

name	kimi-first
description	Route implementation work-orders to Kimi k3 lanes via the Kimi Code CLI; Claude specs, orchestrates, reviews, verifies. Use when a task is a frozen-spec build, mechanical migration, test fill, bulk sweep, or CI fix — anything that reads as a work order rather than a design problem.

Kimi First

Claude Code sessions only. Rationale: Kimi k3 lanes run flat-rate on the Kimi membership and are strong at implementation throughput; Claude's edge is judgment, specs, orchestration, review. Kimi types, Claude thinks and verifies. (Adapted from codex-first in steipete/agent-scripts.)

Route

Delegate to Kimi (default for hands-on volume):

• implementation from a frozen spec; refactors; mechanical migrations/sweeps
• bug fixes with a known repro; test writing; coverage fills
• CI fixes, dependency bumps, scripts/tooling
• bulk exploration where raw reading ≫ the answer

Keep in Claude (never delegate):

• design, architecture, naming, product judgment — tasks where writing the spec IS the work
• tiny edits (<~20 lines, single obvious change) — delegation overhead loses
• anything needing session tools: MCP servers, browser, analytics, memory
• prod operations, always: prod DB (psql), Railway env/deploys, Stripe, DNS, customer emails, anything reading .env/secrets. Kimi never touches prod credentials or runs with them in reach.
• destructive/irreversible ops, releases, pushes, merges — Claude-side per repo protocol
• review of Kimi output — never delegated, never skipped

Heuristic: prompt reads as a work order → delegate; writing it forces decisions → design, keep it. Mixed task: Claude designs, freezes spec, delegates build-out.

Model routing

• Default: omit -m, uses default_model from ~/.kimi-code/config.toml (currently kimi-code/k3)
• Latency-sensitive orders: -m kimi-code/kimi-for-coding-highspeed
• Escalate on failure, never on importance.

Invoke

Prompt via temp file in the scratchpad, never inline quoting. kimi has no -C/-o flags — cd into the repo and redirect stdout yourself:

P=$(mktemp "$SCRATCHPAD/kimi-XXXXXX"); cat >"$P" <<'EOF'
<goal · repo + key paths · constraints ("don't touch X") · non-goals ·
 proof expected (exact test command) · output shape ("report files changed + test output")>
EOF
(cd <repo> && kimi -p "$(cat "$P")" > "$SCRATCHPAD/kimi-last.md" 2>/dev/null)

• -p is headless: no approvals asked, tool calls run under auto permission; static deny rules still apply. --yolo/--auto cannot combine with -p — and aren't needed.
• stdout is assistant text with a • transcript prefix (strip if parsing); thinking and tool progress go to stderr — keep 2>/dev/null, drop only to debug a failing run
• run long jobs with Bash run_in_background; read the output file on completion
• only delegate from repos without prod secrets in reach — headless mode auto-approves regular tool calls, there is no more-restricted non-interactive tier
• follow-ups: (cd <repo> && kimi --continue -p "$(cat "$P2")" > "$SCRATCHPAD/kimi-last.md" 2>/dev/null) — resumes the latest session in that dir, keeps context (verified: remembers prior run)
• parallel independent orders OK: separate repos/dirs, separate output files. --continue is cwd-filtered, so never run two concurrent sessions in the same dir — they'd race on the same "latest session"

Prompt contract

Kimi starts with ZERO session context. Every prompt: goal, exact repo/paths, constraints, non-goals, proof expected, output shape. Spec quality decides success.

Verify (Claude, always)

• git status -sb + read the FULL diff; judge like a hostile contributor-PR review
• run the focused tests yourself or demand proof output; Kimi claims are advisory
• iterate via --continue; after 2 failed rounds, take over and do it directly
• ship through normal repo protocol (commit/create-pr skills, CI watch) — Claude's hands on the merge button, never Kimi's
• substantive results feed a cross-vendor adversarial review (Claude attacks Kimi-built work) before merge