I Let Claude Think While Kimi Writes. This One Skill Makes It Surprisingly Effective.

AI coding assistants are getting better every month. But here’s something interesting. The best workflow isn’t using one AI model for everything anymore.

Instead, it’s giving different AI models different jobs.

One model handles the thinking.

Another handles the typing.

That’s exactly what the kimi-first skill does for Claude Code.

It lets Claude stay focused on architecture, planning, code review, and final decisions, while Kimi Code CLI handles the repetitive implementation work.

The idea is surprisingly simple.

Claude thinks. Kimi builds.

Let’s see how it works.

The Problem With Using One AI For Everything

Imagine you’re building a large project.

Your AI has to:

• Understand the requirements
• Design the architecture
• Write hundreds of files
• Rename variables
• Generate tests
• Fix lint errors
• Review the implementation
• Verify everything still works

These are completely different kinds of work.

Some require judgment.

Others are just mechanical.

Using an expensive reasoning model to rename 500 files is like hiring an architect to paint walls.

It works.

But it’s expensive and unnecessary.

The Main Idea

The kimi-first skill separates these responsibilities.

Instead of asking Claude to do every task, the workflow looks like this.

Planning
                 │
                 ▼
            Claude Code
                 │
                 │
       Creates detailed work order
                 │
                 ▼
        Kimi Code CLI executes
                 │
                 ▼
       Generates implementation
                 │
                 ▼
         Claude reviews everything
                 │
                 ▼
         Tests + Final approval

Notice something important.

Claude never disappears.

It remains the project lead.

Kimi is simply another engineer working on assigned tasks.

What Gets Delegated?

Not every task should be handed to Kimi.

The skill only delegates work-order style tasks.

That means all important decisions have already been made.

Examples include:

• generating unit tests
• fixing formatting
• adding boilerplate
• updating imports
• refactoring hundreds of files
• CI fixes
• dependency updates
• repetitive migrations

These jobs don’t need deep architectural thinking.

They just need accurate execution.

What Never Gets Delegated?

According to the workflow:

• architecture
• design decisions
• planning
• production operations
• final review
• merging code

Those always stay with Claude.

Think of it like this.

CEO
 │
 │ makes decisions
 ▼
Engineering Manager
 │
 │ assigns work
 ▼
Software Engineer
 │
 │ writes code
 ▼
Pull Request Review

Claude is both the engineering manager and reviewer.

Kimi is the engineer writing code.

How the Skill Actually Works

When Claude notices that a request looks like a frozen specification, it performs several steps.

Step 1

Claude writes an extremely detailed prompt.

It contains things like:

• project goal
• repository paths
• constraints
• coding standards
• expected output
• proof requirements
• files to modify

Something like this:

Goal:
Add JWT authentication.
Repository:
backend/
Do not modify:
frontend/
Constraints:
Use existing middleware.
Expected Output:
Working authentication with tests.
Proof:
All existing tests pass.

This prompt is saved into a temporary file.

Why?

Because Kimi starts with zero conversation history.

Everything it needs must be included in that prompt.

Step 2

Claude launches Kimi.

Example:

kimi -p

The CLI runs in headless mode.

Kimi performs the implementation.

Its answer is returned through standard output.

Its internal reasoning goes to standard error.

Step 3

Claude Reviews Everything

This is probably the most important step.

Claude does not trust Kimi blindly.

Instead it behaves like a strict pull request reviewer.

It checks:

• every changed file
• code quality
• architecture
• correctness
• test results

If something looks wrong…

Claude sends Kimi another work order.

Multiple Iterations

The process isn’t limited to one attempt.

It looks more like this.

Claude
   │
   ▼
Creates Work Order
   │
   ▼
Kimi Implementation
   │
   ▼
Claude Review
   │
   ├───────────────┐
   │               │
Looks Good?      Needs Changes
   │               │
   ▼               ▼
 Merge       Continue Session
                   │
                   ▼
          kimi --continue

The skill allows follow-up implementation rounds using:

kimi --continue

That lets Kimi continue from its previous session instead of starting over.

If two rounds still fail…

Claude simply finishes the work itself.

Why Prompt Quality Matters

Kimi begins with no prior context.

That means vague instructions usually produce vague results.

Poor prompt:

Add authentication.

Much better prompt:

Implement JWT authentication.
Use Express middleware.
Do not modify existing routes.
Store secret in environment variables.
Maintain backward compatibility.
Add tests.
Run lint.
Expected files:
auth.ts
middleware.ts
routes.ts

The more complete the work order…

the better the implementation.

Installation

Installing Kimi Code CLI is straightforward.

curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash

Then authenticate:

kimi login

After that, install the Claude Code skill.

mkdir -p ~/.claude/skills/kimi-first
curl -fsSL \
https://raw.githubusercontent.com/boringmarketer/kimi-first/main/skills/kimi-first/SKILL.md \
-o ~/.claude/skills/kimi-first/SKILL.md

Claude Code automatically detects the new skill.

Things Worth Knowing

The workflow has a few practical rules.

Headless mode

kimi -p

Runs Kimi without an interactive interface.

Continue previous session

kimi --continue

Keeps working from the previous conversation.

Don’t run parallel sessions

The continuation feature is tied to the current working directory.

Running multiple sessions inside the same repository can create conflicts.

Headless mode auto-approves tool calls

Because of this, it’s safer to avoid delegating work inside repositories that contain sensitive production secrets.

Why This Workflow Makes Sense

Reasoning models are becoming extremely capable.

But not every task needs expensive reasoning.

Many programming tasks are repetitive.

Examples include:

• changing import paths
• renaming APIs
• generating tests
• fixing formatting
• updating package versions
• replacing deprecated functions

These tasks benefit more from speed than deep analysis.

Meanwhile, architecture reviews, debugging difficult issues, and making trade-off decisions are where stronger reasoning models provide the most value.

Separating those responsibilities allows each model to focus on what it does best.

Final Thoughts

The most interesting part of kimi-first isn’t that it replaces Claude.

It doesn’t.

Instead, it treats AI models like members of a software team.

Claude becomes the architect, reviewer, and project manager.

Kimi becomes the implementation engineer that handles repetitive coding tasks.

The result is a workflow where planning and judgment stay with the reasoning model, while high-volume implementation is delegated to a dedicated execution lane.