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.
Scanned 9/3/2026
Install to Claude Code
npx -y skills add boringmarketer/kimi-first --skill kimi-first --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Kimi First?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/boringmarketer-kimi-first)More formats (shields.io, HTML) on the badges page.
---
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](https://github.com/steipete/agent-scripts/blob/main/skills/codex-first/SKILL.md)
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:
```bash
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
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!