[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-80279":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":13,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":15,"stars7d":15,"stars30d":15,"stars90d":15,"forks30d":15,"starsTrendScore":15,"compositeScore":16,"rankGlobal":10,"rankLanguage":10,"license":17,"archived":18,"fork":18,"defaultBranch":19,"hasWiki":20,"hasPages":18,"topics":21,"createdAt":10,"pushedAt":10,"updatedAt":42,"readmeContent":43,"aiSummary":44,"trendingCount":15,"starSnapshotCount":15,"syncStatus":45,"lastSyncTime":46,"discoverSource":47},80279,"oh-my-kimi","dmae97\u002Foh-my-kimi","dmae97","Verified agent runtime for Kimi Code. Stable daily-use core with alpha orchestration surfaces; release-gated and evidence-gated workflows. | Kimi Code向け検証済みエージェント実行基盤。日常利用コアは安定、オーケストレーション面はalpha。","https:\u002F\u002Foh-my-kimi.sbs\u002F",null,"TypeScript",83,7,1,0,2.71,"MIT License",false,"main",true,[22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"agentic-coding","ai-agent","ai-coding","autonomous-agents","cli","cli-tool","code-generation","coding-agent","dag","developer-tools","kimi","kimi-cli","kimi-k2","llm","mcp","model-context-protocol","multi-agent","orchestration","parallel-execution","typescript","2026-06-12 02:04:00","# OMK — Open Multi-agent Kit\n\n\u003Cdiv align=\"center\">\n\n[![MseeP.ai Security Assessment Badge](https:\u002F\u002Fmseep.net\u002Fpr\u002Fdmae97-oh-my-kimi-badge.png)](https:\u002F\u002Fmseep.ai\u002Fapp\u002Fdmae97-oh-my-kimi)\n\n\u003C!-- Open Graph -->\n\u003Cmeta property=\"og:image\" content=\"https:\u002F\u002Fraw.githubusercontent.com\u002Fdmae97\u002Foh-my-kimi\u002Fmain\u002Freadmeasset\u002Fomk-social-preview.png\" \u002F>\n\u003Cmeta property=\"og:title\" content=\"oh-my-kimi\" \u002F>\n\u003Cmeta property=\"og:url\" content=\"https:\u002F\u002Foh-my-kimi.sbs\u002F\" \u002F>\n\u003Cmeta property=\"og:description\" content=\"Provider-neutral agent runtime for coding workflows. Stable daily-use core with orchestration surfaces.\" \u002F>\n\n\u003C!-- Twitter -->\n\u003Cmeta name=\"twitter:card\" content=\"summary_large_image\" \u002F>\n\u003Cmeta name=\"twitter:image\" content=\"https:\u002F\u002Fraw.githubusercontent.com\u002Fdmae97\u002Foh-my-kimi\u002Fmain\u002Freadmeasset\u002Fomk-social-preview.png\" \u002F>\n\n\u003Cimg src=\".\u002Freadmeasset\u002Fkimicat.gif\" alt=\"oh-my-kimi mascot and CLI demo\" width=\"720\" \u002F>\n\n\u003Ch1>oh-my-kimi\u003C\u002Fh1>\n\n\u003Cp>\u003Cstrong>Verified agent runtime for Kimi Code.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>\u003Csub>Stable daily-use core with orchestration surfaces.\u003C\u002Fsub>\u003C\u002Fp>\n\u003Cp>\u003Csub>Your agents write. OMK coordinates, verifies, remembers, and guards.\u003C\u002Fsub>\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Foh-my-kimi.sbs\u002F\">\u003Cstrong>oh-my-kimi.sbs\u003C\u002Fstrong>\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fdmae97\u002Foh-my-kimi\">GitHub\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002F@oh-my-kimi\u002Fcli\">npm\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Cp>\n  \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fdmae97\u002Foh-my-kimi\u002Factions\u002Fworkflows\u002Fci.yml\">\u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Factions\u002Fworkflow\u002Fstatus\u002Fdmae97\u002Foh-my-kimi\u002Fci.yml?branch=main&style=for-the-badge&logo=githubactions&label=CI\" alt=\"GitHub CI\" \u002F>\u003C\u002Fa>\n  \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fdmae97\u002Foh-my-kimi\u002Freleases\">\u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Fpackage-json\u002Fv\u002Fdmae97\u002Foh-my-kimi?style=for-the-badge&logo=github&label=GitHub%20version\" alt=\"GitHub package version\" \u002F>\u003C\u002Fa>\n  \u003Ca href=\"https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002F@oh-my-kimi\u002Fcli\">\u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fnpm\u002Fv\u002F@oh-my-kimi\u002Fcli?style=for-the-badge&color=cb3837&logo=npm\" alt=\"npm version\" \u002F>\u003C\u002Fa>\n  \u003Ca href=\"https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002F@oh-my-kimi\u002Fcli\">\u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fnpm\u002Fdm\u002F@oh-my-kimi\u002Fcli?style=for-the-badge&color=brightgreen&logo=npm\" alt=\"npm downloads\" \u002F>\u003C\u002Fa>\n  \u003Ca href=\".\u002FLICENSE\">\u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fnpm\u002Fl\u002F@oh-my-kimi\u002Fcli?style=for-the-badge&color=blue\" alt=\"license\" \u002F>\u003C\u002Fa>\n\u003C\u002Fp>\n\n\u003Cp>\n  \u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FTypeScript-3178C6?style=flat-square&logo=typescript&logoColor=white\" alt=\"TypeScript\" \u002F>\n  \u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FNode.js-20+-339933?style=flat-square&logo=node.js&logoColor=white\" alt=\"Node.js\" \u002F>\n  \u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FKimi_Code-K2.6-7C3AED?style=flat-square\" alt=\"Kimi Code K2.6\" \u002F>\n  \u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FDAG-runtime-111827?style=flat-square\" alt=\"DAG runtime\" \u002F>\n  \u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FEvidence-gated-059669?style=flat-square\" alt=\"Evidence gated\" \u002F>\n\u003C\u002Fp>\n\n\u003C\u002Fdiv>\n\n---\n\n## The 10-second version\n\nOMK turns your agent CLI into a bounded coding team with isolated worktrees, DAG-based execution, evidence gates before completion, local graph memory, and a live HUD\u002Fcockpit for operator control. It works with Kimi, Codex, Gemini, Claude Code, OpenRouter, Qwen, DeepSeek, and local models.\n\n- Not a prompt pack.\n- Not a model buffet.\n- A provider-native control plane for shipping code with verification.\n\n```bash\nnpm install -g @oh-my-kimi\u002Fcli\nomk init\nomk doctor\nomk chat\n```\n\nPublic site and install landing page: **[oh-my-kimi.sbs](https:\u002F\u002Foh-my-kimi.sbs\u002F)**.\n\nNeed the full agent harness?\n\n```bash\nomk parallel \"refactor auth module with tests\"\nomk verify --json\nomk summary-show\nomk cockpit\n```\n\n> Current source target: **v1.1.18**. Latest published release remains **v1.1.17** until release gates pass. Release-prep candidate with parallel orchestration, typed doctor repair plans, startup update prompts, and native safety packaging gates; publish\u002Ftag remains gated on `npm run release:check`.\n\n> **Share your verified run:** open a **Verified run** issue with your raw prompt, generated diff, `omk verify --json`, replay screenshot, and known limitation so others can inspect real evidence.\n\n> ⚠️ **Global MCP instability warning:** `omk init --global` can be unstable due to global MCP server dependency resolution.\n> - Input prompts during init: just press **Enter** to accept defaults.\n> - Some `npx`-based MCP servers require a timeout wait (default 15s) — **do not interrupt**.\n> - Global `~\u002F.kimi\u002Fmcp.json` is injected at runtime, not modified directly.\n\n---\n\n## Why OMK\n\n| Problem | OMK answer |\n| --- | --- |\n| Agents say \"done\" too early | Evidence gates require files, diffs, summaries, or passing commands before completion is accepted. |\n| Parallel workers corrupt context | Run-scoped state and Git worktrees keep agent lanes isolated until review or merge. |\n| Long sessions lose memory | Local graph memory stores goals, decisions, risks, commands, files, evidence, and concepts. |\n| Agents need operator visibility | HUD and cockpit expose run state, TODOs, ETA, usage, workers, and changed files. |\n| Extra models create chaos | Write\u002Fmerge authority stays bounded; provider lanes stay advisory, review, QA, or research scoped. |\n| Hooks, MCP, and skills drift | `omk doctor`, `omk skill`, `omk mcp`, and generated project assets make the runtime inspectable. |\n| Repeated agent workflows stay ad hoc | Packaged OMK skills now cover memory, surgical coding, alignment\u002FTDD, React diagnostics, managed-agent teamwork, legal workflows, quality gates, and release review. |\n\n**Mental model:** Your agents write. OMK coordinates, verifies, remembers, and guards.\n\n---\n\n## CLI screenshots\n\n### Live HUD\n\n\u003Cimg src=\".\u002Freadmeasset\u002Fomk-hud-screenshot.png\" alt=\"OMK terminal HUD showing run status, workers, usage, and TODOs\" width=\"720\" \u002F>\n\n### Sidecar cockpit\n\n\u003Cimg src=\".\u002Freadmeasset\u002Freadmeomkcockpit.png\" alt=\"OMK cockpit showing a vertical operator view of run state and tasks\" width=\"720\" \u002F>\n\n### Graph memory viewer\n\n\u003Cimg src=\".\u002Freadmeasset\u002Fomk_ontology.png\" alt=\"OMK ontology graph viewer for files, goals, decisions, risks, and evidence\" width=\"720\" \u002F>\n\n### Open Design bridge\n\n\u003Cimg src=\".\u002Freadmeasset\u002Fopen-design-localhost.png\" alt=\"Open Design localhost launched from OMK\" width=\"720\" \u002F>\n\n### Parallel execution\n\n\u003Cimg src=\".\u002Freadmeasset\u002Fparallelmod.png\" alt=\"OMK parallel execution showing worker lanes and progress\" width=\"720\" \u002F>\n\n---\n\n## Current CLI shape\n\n```text\nStart Here\n  omk menu       Interactive OMK main menu\n  omk init       Project scaffold: AGENTS.md, DESIGN.md, .omk\u002F\n  omk doctor     Environment check: CLI, Git, hooks, MCP, skills, providers\n  omk chat       Agent interactive execution\n  omk plan       Plan-only execution\n  omk hud        Execution status and system usage HUD\n  omk mode       Switch execution presets (agent, plan, chat, debug, review)\n\nStable \u002F daily-use\n  omk cockpit    Sidecar cockpit for run state, TODOs, and ETA\n  omk design     DESIGN.md and Open Design integration\n  omk lsp        Built-in TypeScript LSP run\u002Fconfig output\n  omk runs       List past OMK runs with status and dates\n  omk history    Alias for runs with filters and export\n\nAdvanced \u002F inspectable\n  omk graph      Inspect OMK ontology graph\n  omk mcp        Inspect MCP configuration and server health\n  omk replay     Timeline-based run replay from artifacts\n  omk inspect    Forensic run inspection with deep-dive flags\n  omk diff-runs  Structural diff between two runs for reproducibility\n  omk agent      Agent role listing\u002Fshow\u002Fcreate\u002Fdoctor\n  omk snip       Snippet save\u002Fget\u002Flist\u002Fsearch\u002Fdelete\n  omk servarr    Optional Radarr\u002FSonarr\u002FLidarr read-only adapter\n\nOrchestration\n  omk parallel   Parallel coordinator + workers + reviewer\n  omk run        DAG-based long-running task execution\n  omk verify     Evidence-gate verification for a run\n  omk goal       Goal lifecycle management\n  omk team       tmux-based multi-agent team execution\n  omk research   Web research wrapper\n  omk spec       GitHub Spec Kit bridge\n```\n\nStable and daily-use commands are the normal operator path. Advanced and orchestration commands expose stronger orchestration primitives without pretending every surface has the same maturity level.\n\n---\n\n## How the engine works\n\n```mermaid\nflowchart LR\n  U[User prompt] --> I[OMK intake]\n  I --> P[Prompt shaping + project rules]\n  P --> G[Goal \u002F DAG compiler]\n  G --> S[Scheduler]\n  S --> A[Agents, skills, hooks, MCP]\n  A --> K[Kimi writer]\n  A --> D[Advisory lanes]\n  K --> E[Evidence gates]\n  D --> E\n  E --> M[Graph memory + run state]\n  M --> H[HUD \u002F cockpit]\n  H --> U\n```\n\n### 1. Provider-native control plane\n\nOMK is built around your agent provider instead of treating it as a generic backend. Project rules, generated agents, hooks, slash skills, MCP configuration, and run state are shaped so the primary writer remains bounded by OMK state, safety hooks, graph memory, and evidence gates.\n\n### 2. DAG execution\n\nA request can become a task graph instead of a single linear prompt. Nodes can carry roles, dependencies, retries, fallback routing, timeout presets, heartbeat monitoring, and evidence requirements. This makes long-running work explicit enough to inspect, resume, verify, or block.\n\n### 3. Evidence gates\n\nOMK does not accept completion by narration alone. A node can require evidence such as:\n\n- file exists\n- command passes\n- git diff is non-empty\n- summary or evidence marker is present\n\nIf evidence fails, the runtime can retry, skip, block dependents, or route to fallback handling.\n\n### 4. Decision trace coverage\n\nEvery policy decision — routing, context brokering, repair, scheduling, provider selection, ensemble decisions, and skill assignment — is recorded in `.omk\u002Fruns\u002F\u003CrunId>\u002Fdecisions.jsonl`. This makes runs inspectable and reproducible rather than opaque.\n\n### 5. Context brokering and budget optimization\n\nOMK manages context as bounded capsules rather than unbounded conversation history. The context broker shapes what each agent receives based on role and task, while the budget optimizer estimates tokens before expensive calls to prevent runaway context accumulation.\n\n### 6. Local graph memory\n\nOMK stores durable project memory as a graph: goals, decisions, risks, tasks, commands, files, evidence, and concepts. The graph gives the primary writer a smaller, safer context target before editing a large repository.\n\n### 7. Worktree isolation\n\nParallel lanes can run in isolated Git worktrees. That keeps experiments reversible and makes review\u002Fmerge a deliberate step instead of a side effect of several agents editing the same files at once.\n\n### 8. Skills, hooks, MCP, and agents as runtime inputs\n\n**Every OMK generated agent carries MCP, skills, and hooks capability flags, but availability is scoped by runtime and harness policy.** Every generated subagent — `explorer`, `planner`, `router`, `coder`, `reviewer`, `qa`, `tester`, `researcher`, `security`, `integrator`, `aggregator`, `interviewer`, `ontology`, `vision-debugger`, `architect` — inherits scoped MCP, skills, and hooks access when enabled by runtime scope.\n\n**Parallel subagent orchestration:** the root coordinator can summon parallel subagents with independent context lanes, each with their own MCP\u002Fskills\u002Fhooks scope. Workers do not share mutable context; they operate in isolated lanes until evidence is reviewed and merged.\n\nOMK treats project instructions, agent skills, generated hooks, and MCP servers as part of the control plane:\n\n- `AGENTS.md` and `DESIGN.md` define project behavior and UI taste.\n- `.omk\u002F` stores run state, memory, plans, reports, and generated runtime assets.\n- Default preset `omk-core-verified` is the current conservative core loop: repo\u002Fcontext\u002Fcontrol-loop\u002Fplan\u002Fquality\u002Freview\u002Ftest\u002FPython-typing skills, shell\u002Fsecret\u002Fstop\u002Fsubagent\u002Fformat hooks, and project-local `omk-project` MCP as the baseline hint. Broader MCP surfaces stay opt-in through product\u002Fteam\u002Frelease\u002Fhigh-trust presets or explicit local-user scope.\n- Product preset `omk-ts-product` adds strict TypeScript, React\u002FNext\u002FNest, API DTO\u002Fdomain\u002Fpersistence, UI review\u002Fdesign-system skills, typecheck\u002Feslint hooks, and `playwright` MCP for UI verification.\n- Team preset `omk-worktree-team` routes parallel worker lanes into isolated Git worktrees with branch snapshots, subagent audit, merge-quality gates, GitHub\u002Fmemory, and read-only filesystem MCP hints.\n- Release preset `omk-release-guard` narrows release\u002Fsecurity work to secret and security review skills, guarded shell\u002Fpublish hooks, audit\u002Fchecklist evidence, and GitHub\u002FOMK\u002Ffetch\u002FContext7 MCP hints; it treats reference MCP servers as advisory examples rather than production-ready trust boundaries and does not auto-publish.\n- Top-priority skill pack `omk-priority` installs the 12 repeatable SKILL.md workflows for context capsules, targeted repo discovery, control-loop planning, plan-first execution, quality gates, test debugging, code\u002Fsecurity\u002Fsecret review, TypeScript\u002FPython typing, and isolated worktree teams. These are advertised as skills, not always-loaded prompt body.\n- Agentic operations skill pack `omk-agentic-ops` installs the custom AdaptOrch\u002FOMK orchestration review, task evidence contract, and control-loop debugger skills for DAG runtime, evidence-gate, and repair-policy analysis.\n- `omk skill` manages Kimi-facing skills and slash workflows.\n- **Skill Assigner** automatically matches skills, MCP servers, tools, and hooks to DAG nodes based on intent and role (17 rules covering core\u002Fproduct\u002Fteam presets, web-design, diagram-design, code-review, security-audit, debugging, and more).\n- `omk mcp` inspects project and user MCP configuration.\n- `omk doctor` checks providers, Git, hooks, MCP, skills, and runtime health.\n\n### 9. Ensemble decisions and repair policy\n\nWhen multiple agents can work on the same node, the ensemble runner evaluates progress, risk, resource utilization, and quality across weighted analytical perspectives. If evidence fails, the repair policy decides whether to retry with context, skip, block dependents, or route to fallback handling — all recorded in decision traces.\n\n### 10. Live operator visibility\n\n`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.\n\n### 11. Advisory provider lanes\n\nOMK can route research, review, QA, or risk analysis through provider lanes such as DeepSeek, but the run stays bounded. Kimi keeps write\u002Fmerge authority, and external model output is advisory evidence rather than uncontrolled patch authority.\n\n### 12. Open Design bridge\n\n`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.\n\nUse `omk design open-design --doctor --json` for a side-effect-free readiness check. The bridge supports `--ref \u003Cbranch|tag|sha>` \u002F `OMK_OPEN_DESIGN_REF` for reproducible upstream checkouts; current tested Open Design main is `3f7a05e7462f097bf38b7cbac0d4a4593deecd80`. Image\u002Fscreenshot inputs are forwarded as local `--image` paths, and timeout success is limited to `.omk\u002Fopen-design-artifacts\u002F\u003Crun-id>\u002F` or an explicit `--artifact-dir`.\n\n### 13. Run replay and inspection\n\n`omk replay`, `omk inspect`, and `omk diff-runs` turn run artifacts into an inspectable timeline. Replay reconstructs chronology; inspect deep-dives into context, evidence, decisions, and repair chains; diff-runs compares two manifests for reproducibility debugging.\n\n### 14. Native safety path\n\nOMK 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.\n\n---\n\n## Five operating rituals\n\n| Ritual | Use when | Commands |\n| --- | --- | --- |\n| **Ship** | You want an agent to implement with verification | `omk chat`, `omk parallel \"...\"`, `omk verify` |\n| **Inspect** | You need run history or current state | `omk runs`, `omk replay`, `omk inspect`, `omk diff-runs`, `omk summary-show`, `omk hud` |\n| **Design** | You need visual\u002Fproduct direction | `omk design`, `omk design open-design --open` |\n| **Remember** | You need durable project context | `omk graph view --open`, `omk index` |\n| **Guard** | You need safety and release confidence | `omk doctor`, `npm run release:check`, `omk review` |\n\n---\n\n## Example: one prompt to a verified run\n\n```bash\nomk init\nomk doctor\nomk plan \"Add a settings page with tests\"\nomk parallel \"Implement the settings page from the plan\"\nomk verify --json\nomk summary-show\n```\n\nExpected operator loop:\n\n1. OMK loads project rules, skills, hooks, MCP status, and current Git state.\n2. The active agent receives a shaped prompt with explicit constraints.\n3. The scheduler creates bounded lanes for implementation, review, or QA.\n4. Evidence gates check required files, diffs, summaries, or commands.\n5. Graph memory records decisions, risks, files, and evidence for the next run.\n6. HUD\u002Fcockpit shows progress and remaining blockers.\n\n---\n\n## Reproducible examples\n\n| Example | Prompt -> output | Artifact |\n| --- | --- | --- |\n| [One-prompt landing page](https:\u002F\u002Fgithub.com\u002Fdmae97\u002Foh-my-kimi\u002Ftree\u002Fmain\u002Fexamples\u002Fone-prompt-landing-page) | Next.js + Tailwind landing page from a single sentence | `RUN_REPORT.md`, video, known limitations |\n| [Neon Courier 2D](https:\u002F\u002Fgithub.com\u002Fdmae97\u002Foh-my-kimi\u002Ftree\u002Fmain\u002Fexamples\u002Fneon-courier-2d) | Browser 2D runner game in TypeScript | `RUN_REPORT.md`, source, known limitations |\n| [Neon Courier FPS](https:\u002F\u002Fgithub.com\u002Fdmae97\u002Foh-my-kimi\u002Ftree\u002Fmain\u002Fexamples\u002Fneon-courier-fps) | Three.js first-person prototype | `RUN_REPORT.md`, source, known limitations |\n\n\u003Cimg src=\".\u002Freadmeasset\u002Foneprompt.gif\" alt=\"One-prompt landing page generated through OMK\" width=\"720\" \u002F>\n\nOMK examples are intentionally honest: prompts, generated outputs, run reports, and known limitations stay visible.\n\n---\n\n## How OMK differs from other oh-my harnesses\n\n| Harness | Best when | Core idea |\n| --- | --- | --- |\n| OMC | You live inside Claude Code | Team-first Claude Code orchestration |\n| OMX | You want a stronger Codex CLI workflow | Codex workflow layer with reusable modes |\n| OMO | You want open multi-model routing | Open multi-model agent team with aggressive routing |\n| OMK | You want verified agent execution | Provider-neutral DAG runtime with evidence gates and graph memory |\n\nOMK is provider-neutral. Any supported model can advise, review, or QA, and the run remains bounded by OMK state, safety hooks, graph memory, and evidence gates.\n\n---\n\n## Installation\n\n```bash\nnpm install -g @oh-my-kimi\u002Fcli\nomk --version\nomk doctor\n```\n\nRequirements:\n\n- Node.js 20+\n- Git\n- At least one supported agent provider (Kimi, Codex, Gemini, Claude Code, OpenRouter, etc.) installed and authenticated\n- tmux for team\u002FHUD workflows on Unix-like systems\n- Node.js 24 when launching upstream Open Design locally\n\nProject bootstrap:\n\n```bash\nmkdir my-project\ncd my-project\nomk init\nomk doctor\n```\n\nOptional DeepSeek advisory setup:\n\n```bash\nprintf '%s' \"$DEEPSEEK_API_KEY\" | omk deepseek api\nomk deepseek doctor --soft\n```\n\nDo not commit provider keys. Keep secrets in environment variables, local keychains, or ignored local config.\n\nOpenAI image generation uses a Platform project API key, not Codex\u002FChatGPT OAuth. For `omk image generate\u002Fedit`, inject an ephemeral `OPENAI_API_KEY` for one command, then unset it; see [OpenAI Platform keys for image generation](.\u002Fdocs\u002Fopenai-platform-image-keys.md).\n\nThe Open Design bridge does not pass inherited `OPENAI_API_KEY`, OAuth tokens, `*_TOKEN`, `*_SECRET`, or `*_KEY` env vars to its Kimi child process by default. Only set `OMK_OPEN_DESIGN_TRUST_SECRET_ENV=1` for a trusted local run that intentionally needs secret env inheritance.\n\n---\n\n## Command map\n\n| Area | Commands |\n| --- | --- |\n| Bootstrap | `omk init`, `omk doctor`, `omk menu`, `omk update`, `omk star` |\n| Agent execution | `omk chat`, `omk plan`, `omk parallel`, `omk run` |\n| Verification | `omk verify`, `omk review`, `npm run verify`, `npm run release:check` |\n| Operator UI | `omk hud`, `omk cockpit`, `omk runs`, `omk summary`, `omk summary-show` |\n| Replay & diff | `omk replay`, `omk inspect`, `omk diff-runs` |\n| Context | `omk index`, `omk graph`, `omk sync`, `omk skill` |\n| Providers | `omk provider`, `omk deepseek`, `omk research` |\n| Design | `omk design`, `omk design open-design --open`, `omk open-design-agent` |\n| Advanced | `omk goal`, `omk dag`, `omk team`, `omk merge`, `omk screenshot`, `omk cron`, `omk specify` |\n| Tools & presets | `omk mode`, `omk snip`, `omk agent` |\n| Workflow presets | `omk feature`, `omk bugfix`, `omk refactor` |\n\n---\n\n## Safety and maturity\n\nOMK has a stable daily-use core, with advanced surfaces explicitly labelled by maturity:\n\n- **Stable \u002F daily-use core:** init, doctor, chat, plan, mode, runs, history, index-show, cockpit, HUD, design, LSP, index, star, update, google, and project inspection surfaces.\n- **Advanced inspection:** graph, MCP, replay, inspect, diff-runs, snip, screenshots, provider diagnostics, and design bridges are inspectable but may depend on local project assets.\n- **Orchestration:** parallel, run, verify, review, goal, sync, summary, and long-running evidence-gated flows.\n- **Advanced surfaces:** tmux team mode, merge automation, agent registry, skill manager, research, feature\u002Fbugfix\u002Frefactor workflows, spec\u002FDAG\u002Fcron, open-design-agent, and provider-routing integrations.\n\nRelease asset policy: `public\u002Fassets\u002F**` is source-only reference material and is intentionally ignored and forbidden from npm package audit until license\u002Fprovenance is recorded. Existing `readmeasset\u002F` and `docs\u002Fassets\u002F` files remain the package-safe documentation asset locations.\n\nRelease confidence is built from local and CI gates:\n\n```bash\nnpm run verify\nnpm run native:build\nnpm run pack:dry\nnpm run audit:package\nnpm run smoke:pack\nnpm run release:check\n```\n\nThe v1.1.18 source target is release-gated and evidence-gated: it strengthens parallel subagent orchestration, typed `omk doctor --fix` repair plans with dry-run and post-fix verification, shared startup update prompts, memory\u002Fcapability harness summaries, and native safety package readiness while preserving package audit, smoke-pack checks, native safety normalization, replay\u002Finspect\u002Fdiff-runs, skill assigner, decision trace coverage, and CI release gates. Do not claim v1.1.18 as published until native safety packaging, package audit, smoke-pack, tarball install smoke, and `npm run release:check` evidence pass; latest published release remains v1.1.17 until then.\n\n**MCP fetch startup note:** if your personal Kimi config still starts fetch with `uvx mcp-server-fetch`, each disposable or isolated Kimi HOME may re-resolve Python dependencies before MCP tools appear. Prefer a persistent entrypoint:\n\n```bash\nuv tool install mcp-server-fetch\n```\n\nThen set `~\u002F.kimi\u002Fmcp.json` to an absolute command such as `\u002Fhome\u002Fyou\u002F.local\u002Fbin\u002Fmcp-server-fetch`. Keep project `.kimi\u002Fmcp.json` files from redefining the same `fetch` server unless the project intentionally overrides the user-level server.\n\n**MCP PDF startup note:** `@modelcontextprotocol\u002Fserver-pdf` defaults to Streamable HTTP and may print `MCP server listening on http:\u002F\u002Flocalhost:3001\u002Fmcp` to stdout, which breaks stdio JSON-RPC clients. OMK installs it with `--stdio`; existing configs should add that arg or configure PDF as a remote URL.\n\n---\n\n## Documentation\n\n- [Getting started](.\u002Fdocs\u002Fgetting-started.md)\n- [Verified-run demo evidence skeleton](.\u002Fdocs\u002Fdemo\u002Fverified-run\u002FREADME.md)\n- [Current workflow skills](.\u002Ftemplates\u002Fskills\u002Fkimi\u002Fagentmemory\u002FSKILL.md)\n- [Local graph memory](.\u002Fdocs\u002Flocal-graph-memory.md)\n- [HUD and parallel UX](.\u002Fdocs\u002Fhud-and-parallel-ux.md)\n- [Design and Open Design workflow](.\u002Fdocs\u002Fdesign-md.md)\n- [Kimi OAuth and usage status](.\u002Fdocs\u002Fkimi-oauth-usage-status.md)\n- [Roadmap](.\u002FROADMAP.md)\n- [Maturity](.\u002FMATURITY.md)\n- [Security](.\u002FSECURITY.md)\n\n---\n\n## Repository topics\n\n`agent-runtime` · `provider-neutral` · `coding-agents` · `dag-runtime` · `evidence-gates` · `multi-agent-orchestration` · `agent-supervisor` · `kimi-code` · `verified-agent-runtime` · `dag-execution` · `graph-memory` · `worktree-isolation` · `mcp` · `agent-skills` · `safety-hooks` · `open-design` · `deepseek-advisory`\n\n---\n\n## Acknowledgements\n\nOMK is part of the broader oh-my agent harness family. It is built for developers who want stronger execution state, verification, memory, and operator visibility from any supported coding agent, without giving up the primary writer as the bounded coding authority.\n\n---\n\n## Star history\n\n[![Star History Chart](https:\u002F\u002Fapi.star-history.com\u002Fsvg?repos=dmae97\u002Foh-my-kimi&type=Date)](https:\u002F\u002Fwww.star-history.com\u002F#dmae97\u002Foh-my-kimi&Date)\n","oh-my-kimi 是一个为 Kimi Code 设计的验证过的代理运行时环境，提供了稳定的日常使用核心以及处于 alpha 阶段的编排界面。该项目采用 TypeScript 开发，支持多代理协同工作、代码生成和并行执行等功能，并遵循模型上下文协议（MCP），确保了代码的可追溯性和安全性。它特别适合需要高效管理和协调多个 AI 代理进行复杂编码任务的开发场景，如自动化代码生成、持续集成\u002F持续部署流程等。",2,"2026-06-01 03:50:32","CREATED_QUERY"]