oh-my-kimi (OMK)

---

The 10-second version

OMK turns Kimi Code CLI into a bounded coding team with isolated worktrees, DAG-based execution, evidence gates before completion, local graph memory, and a live HUD/cockpit for operator control.

• Not a prompt pack.
• Not a model buffet.
• A Kimi-native control plane for shipping code with verification.

npm install -g @oh-my-kimi/cli
omk init
omk doctor
omk chat

Need the full agent harness?

omk parallel "refactor auth module with tests"
omk verify --json
omk summary-show
omk cockpit

Current stable package: v1.1.9. Stable daily-use core with alpha/experimental orchestration surfaces clearly labelled in CLI help and docs.

---

Why OMK

Problem	OMK answer
Agents say "done" too early	Evidence gates require files, diffs, summaries, or passing commands before completion is accepted.
Parallel workers corrupt context	Run-scoped state and Git worktrees keep agent lanes isolated until review or merge.
Long sessions lose memory	Local graph memory stores goals, decisions, risks, commands, files, evidence, and concepts.
Kimi needs operator visibility	HUD and cockpit expose run state, TODOs, ETA, usage, workers, and changed files.
Extra models create chaos	Kimi keeps write/merge authority; provider lanes stay advisory, review, QA, or research scoped.
Hooks, MCP, and skills drift	omk doctor, omk skill, omk mcp, and generated project assets make the runtime inspectable.

Mental model: Kimi writes. OMK coordinates, verifies, remembers, and guards.

---

CLI screenshots

Live HUD

Sidecar cockpit

Graph memory viewer

Open Design bridge

---

Current CLI shape

Start Here
  omk menu       Interactive OMK main menu
  omk init       Project scaffold: AGENTS.md, DESIGN.md, .omk/
  omk doctor     Environment check: CLI, Git, hooks, MCP, skills
  omk chat       Kimi interactive execution
  omk plan       Plan-only execution
  omk hud        Execution status and system usage HUD

Stable / daily-use
  omk cockpit    Sidecar cockpit for run state, TODOs, and ETA
  omk design     DESIGN.md and Open Design integration
  omk lsp        Built-in TypeScript LSP run/config output
  omk runs       List past OMK runs with status and dates

Advanced / inspectable
  omk graph      Inspect OMK ontology graph
  omk mcp        Inspect MCP configuration and server health

Alpha / Experimental
  omk parallel   Parallel Kimi coordinator + workers + reviewer
  omk run        DAG-based long-running task execution
  omk verify     Evidence-gate verification for a run
  omk goal       Goal lifecycle management
  omk team       tmux-based multi-agent team execution

Stable and daily-use commands are the normal operator path. Advanced, alpha, and experimental commands expose stronger orchestration primitives without pretending every surface has the same maturity level.

---

How the engine works

flowchart LR
  U[User prompt] --> I[OMK intake]
  I --> P[Prompt shaping + project rules]
  P --> G[Goal / DAG compiler]
  G --> S[Scheduler]
  S --> A[Agents, skills, hooks, MCP]
  A --> K[Kimi writer]
  A --> D[Advisory lanes]
  K --> E[Evidence gates]
  D --> E
  E --> M[Graph memory + run state]
  M --> H[HUD / cockpit]
  H --> U

1. Kimi-native control plane

OMK is built around Kimi Code instead of treating Kimi as a generic backend. Project rules, generated agents, hooks, slash skills, MCP configuration, and run state are shaped so Kimi remains the primary writer and merger.

2. DAG execution

A request can become a task graph instead of a single linear prompt. Nodes can carry roles, dependencies, retries, fallback routing, and evidence requirements. This makes long-running work explicit enough to inspect, resume, verify, or block.

3. Evidence gates

OMK does not accept completion by narration alone. A node can require evidence such as:

• file exists
• command passes
• git diff is non-empty
• summary or evidence marker is present

If evidence fails, the runtime can retry, skip, block dependents, or route to fallback handling.

4. Local graph memory

OMK stores durable project memory as a graph: goals, decisions, risks, tasks, commands, files, evidence, and concepts. The graph gives Kimi a smaller, safer context target before it edits a large repository.

5. Worktree isolation

Parallel lanes can run in isolated Git worktrees. That keeps experiments reversible and makes review/merge a deliberate step instead of a side effect of several agents editing the same files at once.

6. Skills, hooks, MCP, and agents as runtime inputs

OMK treats project instructions, agent skills, generated hooks, and MCP servers as part of the control plane:

• AGENTS.md and DESIGN.md define project behavior and UI taste.
• .omk/ stores run state, memory, plans, reports, and generated runtime assets.
• omk skill manages Kimi-facing skills and slash workflows.
• omk mcp inspects project and user MCP configuration.
• omk doctor checks Kimi, Git, hooks, MCP, skills, and runtime health.

7. Live operator visibility

omk hud and omk cockpit expose active work instead of hiding agent state inside logs. The goal is simple: humans should see what is running, what changed, what is blocked, and what still needs proof.

8. Advisory provider lanes

OMK can route research, review, QA, or risk analysis through provider lanes such as DeepSeek, but the run stays bounded. Kimi keeps write/merge authority, and external model output is advisory evidence rather than uncontrolled patch authority.

9. Open Design bridge

omk design open-design --open launches a local Open Design workflow and connects it back to OMK. Use it when the task needs a visual design surface, then bring the output through DESIGN.md-aware implementation and quality gates.

10. Native safety path

v1.1.9 includes a Rust native safety loader path and CI-backed artifact matrix. JavaScript remains the CLI surface; native safety helpers are selected when available and fall back safely when they are not.

---

Five operating rituals

Ritual	Use when	Commands
Ship	You want Kimi to implement with verification	omk chat, omk parallel "...", omk verify
Inspect	You need run history or current state	omk runs, omk summary-show, omk hud
Design	You need visual/product direction	omk design, omk design open-design --open
Remember	You need durable project context	omk graph view --open, omk index
Guard	You need safety and release confidence	omk doctor, npm run release:check, omk review

---

Example: one prompt to a verified run

omk init
omk doctor
omk plan "Add a settings page with tests"
omk parallel "Implement the settings page from the plan"
omk verify --json
omk summary-show

Expected operator loop:

1. OMK loads project rules, skills, hooks, MCP status, and current Git state.
2. Kimi receives a shaped prompt with explicit constraints.
3. The scheduler creates bounded lanes for implementation, review, or QA.
4. Evidence gates check required files, diffs, summaries, or commands.
5. Graph memory records decisions, risks, files, and evidence for the next run.
6. HUD/cockpit shows progress and remaining blockers.

---

Reproducible examples

Example	Prompt -> output	Artifact
One-prompt landing page	Next.js + Tailwind landing page from a single sentence	RUN_REPORT.md, video, known limitations
Neon Courier 2D	Browser 2D runner game in TypeScript	RUN_REPORT.md, source, known limitations
Neon Courier FPS	Three.js first-person prototype	RUN_REPORT.md, source, known limitations

OMK examples are intentionally honest: prompts, generated outputs, run reports, and known limitations stay visible.

---

How OMK differs from other oh-my harnesses

Harness	Best when	Core idea
OMC	You live inside Claude Code	Team-first Claude Code orchestration
OMX	You want a stronger Codex CLI workflow	Codex workflow layer with reusable modes
OMO	You want open multi-model routing	Open multi-model agent team with aggressive routing
OMK	You want Kimi Code with verification	Kimi-native DAG runtime with evidence gates and graph memory

OMK is intentionally Kimi-first. Other models can advise, review, or QA, but the run remains bounded by OMK state, safety hooks, graph memory, and evidence gates.

---

Installation

npm install -g @oh-my-kimi/cli
omk --version
omk doctor

Requirements:

• Node.js 20+
• Git
• Kimi Code CLI installed and authenticated
• tmux for team/HUD workflows on Unix-like systems
• Node.js 24 when launching upstream Open Design locally

Project bootstrap:

mkdir my-project
cd my-project
omk init
omk doctor

Optional DeepSeek advisory setup:

printf '%s' "$DEEPSEEK_API_KEY" | omk deepseek api
omk deepseek doctor --soft

Do not commit provider keys. Keep secrets in environment variables, local keychains, or ignored local config.

---

Command map

Area	Commands
Bootstrap	omk init, omk doctor, omk menu, omk update
Kimi execution	omk chat, omk plan, omk parallel, omk run
Verification	omk verify, omk review, npm run verify, npm run release:check
Operator UI	omk hud, omk cockpit, omk runs, omk summary-show
Context	omk index, omk graph, omk sync, omk skill
Providers	omk provider, omk deepseek, omk research
Design	omk design, omk design open-design --open, omk open-design-agent
Advanced	omk goal, omk dag, omk team, omk merge, omk screenshot

---

Safety and maturity

OMK is designed for daily use with explicit maturity labels:

• Stable / daily-use core: init, doctor, chat, plan, runs, cockpit, HUD, design, LSP, and project inspection surfaces.
• Advanced inspection: graph, MCP, sync, screenshots, provider diagnostics, and design bridges are inspectable but may depend on local project assets.
• Alpha orchestration: parallel, run, verify, review, goal, and long-running evidence-gated flows.
• Experimental surfaces: tmux team mode, merge automation, agent registry, skill manager, spec/DAG, cron, and provider-routing integrations.

Release confidence is built from local and CI gates:

npm run verify
npm run native:build
npm run pack:dry
npm run audit:package
npm run smoke:pack

The v1.1.9 release line includes package audit, smoke-pack checks, Rust native artifact normalization, and CI release gates.

---

Documentation

• Getting started
• Local graph memory
• HUD and parallel UX
• Design and Open Design workflow
• Kimi OAuth and usage status
• Roadmap
• Maturity
• Security

---

Repository topics

kimi-code · verified-agent-runtime · dag-execution · evidence-gates · graph-memory · worktree-isolation · mcp · agent-skills · safety-hooks · open-design · deepseek-advisory

---

Acknowledgements

OMK is part of the broader oh-my agent harness family and is built specifically for Kimi Code users who want stronger execution state, verification, memory, and operator visibility without giving up Kimi as the primary coding authority.

---

Star history