by KimYx0207
Governed execution layer for AI coding assistants: clarify intent, route capabilities, review evidence, verify results, and write back lessons across Claude Code, Codex, OpenClaw, and Cursor.
# Add to your Claude Code skills
git clone https://github.com/KimYx0207/Meta_KimLast scanned: 6/10/2026
{
"issues": [],
"status": "PASSED",
"scannedAt": "2026-06-10T08:08:34.375Z",
"npmAuditRan": true,
"pipAuditRan": true
}Meta_Kim is an open-source ai agents skill for AI coding assistants such as Claude Code, Codex CLI, and ChatGPT, built by KimYx0207. Governed execution layer for AI coding assistants: clarify intent, route capabilities, review evidence, verify results, and write back lessons across Claude Code, Codex, OpenClaw, and Cursor. It has 252 GitHub stars.
Yes. Meta_Kim passed SkillsLLM's automated security scan — a dependency vulnerability audit plus prompt-injection heuristics — with no high-severity issues. You can read the full report in the Security Report section on this page.
Clone the repository with "git clone https://github.com/KimYx0207/Meta_Kim" and add it to your Claude Code skills directory (see the Installation section above).
Meta_Kim is primarily written in JavaScript. It is open-source under KimYx0207 on GitHub, so you can review or fork the full source.
Yes. SkillsLLM lists many other AI Agents skills you can browse and compare side by side. Open the AI Agents category from the badge at the top of this page, or use the Related Skills and comparison links further down to weigh Meta_Kim against similar tools.
No comments yet. Be the first to share your thoughts!
Meta_Kim is not another AI coding tool. It is a governance layer for durable AI coding work.
The hard part of AI coding is no longer getting a model to change files. The hard part is deciding what should happen first, which capability should own it, what evidence proves it worked, and how the lesson survives the next run.
Claude Code, Codex, OpenClaw, and Cursor are all hands: they can write code and change files. But who decides which file to change first? Who reviews the result? Who fixes the problems that show up? And how do we make sure the same mistake does not repeat next time?
Meta_Kim is built for that. It is the governance layer above the coding hands: a runnable set of agents, skills, contracts, hooks, scripts, and evidence gates that keeps complex work from turning into a mess.
First clarify what needs to happen -> then decide who should do it -> review after execution -> preserve what was learned -> feed that back into the next run.
This is not a new concept. Mature engineering teams already do this. Meta_Kim turns it into a runnable system instead of relying on human discipline alone.
| Without Meta_Kim | With Meta_Kim |
|---|---|
| One giant chat response tries to do everything | Work is routed through intent, capability, owner, review, verification, and writeback |
| A tool is chosen because it is available | A capability is selected because it fits the task, runtime, OS, dependency, and risk |
| Passing commands get mistaken for success | Evidence is checked against the user's real goal |
| Good fixes disappear into chat history | Reusable lessons become governed skills, agents, scripts, contracts, or run-scoped tasks |
Meta_Kim is easiest to understand by watching one governed run, not by reading every rule.
npm run meta:theory:demo
npm run meta:run-status:latest
npm run meta:theory:report -- --run-id latest
npm run meta:delivery:bundle
The proof path shows five things:
The executable core-loop contract is config/contracts/core-loop-contract.json; it binds the default path to npm run meta:theory:run -- "<task>" and keeps Critical -> Fetch -> Thinking -> Execution -> Review -> Meta-Review -> Verification -> Evolution testable. npm run meta:theory:demo is the zero-argument replay entry for the 3-minute proof.
For a guided walk-through, start with examples/first-run/README.md.
If you just want to try it quickly, run:
npx --yes github:KimYx0207/Meta_Kim meta-kim
Or install it the traditional way:
git clone https://github.com/KimYx0207/Meta_Kim.git
cd Meta_Kim
npm install
node setup.mjs
💡 After install:
setup.mjsprints where every artifact lives. To revisit that summary anytime (or diff vs. the previous install), runnpm run meta:statusin the directory where you installed.
At a fresh clone, Meta_Kim intentionally separates source files, generated projections, and local state:
| Layer | Examples | When you should see it |
|---|---|---|
| GitHub source | README.md, AGENTS.md, CLAUDE.md, canonical/, config/, scripts/ |
Immediately after git clone; also included by the package files whitelist when applicable |
| Generated runtime projections | .claude/, .codex/, .agents/, .cursor/, openclaw/, .mcp.json, codex/ |
Created locally by node setup.mjs or npm run meta:sync; gitignored and not GitHub source |
| Local run state and graph output | .meta-kim/, graphify-out/, tests/output/, task_plan.md, findings.md, progress.md |
Created only by setup, graphify, tests, or governed runs; local-only and safe to regenerate |
The default Enter path is global reusable capabilities. Agents, commands, MCP, and skills are installed into each selected runtime's official global/home locations when that runtime supports them. Global hook wiring is opt-in: pass --with-global-hooks when you intentionally want Meta_Kim to update Claude/Codex/Cursor hook settings. Projects reuse global capabilities directly; project-local agents, commands, MCP, hooks, or skills are created only when Fetch/Thinking proves project-specific customization, iteration, or a dedicated override is needed.
If you explicitly choose Project directory updates, setup asks which project directories to update and writes the target-selected project runtime projection there, including project hooks/config where that runtime supports them. This path does not install global reusable capabilities and does not run project cleanup.
Project files are still allowed, but they are not the default reusable capability store. Confirmed project bootstrap writes only project context/config/state plus proven project-specific overrides, preserving existing user config through managed blocks, add-only writes, protected JSON merge, backups, and manifests. Every applied project bootstrap records .meta-kim/ state and backup files.
If you plan to maintain the repository, edit the canonical sources first: canonical/agents/, canonical/skills/meta-theory/, config/contracts/, and config/capability-index/. Then run (requires Node.js >= 22.13.0):
npm run meta:sync
npm run meta:validate
Recommended reading order:
README.mdAGENTS.mdCLAUDE.md when working on Claude Code behaviorcanonical/runtime-assets/cursor/rules/meta-enforcement.mdc when working on Cursor rulesAfter the default install (node setup.mjs or npx) or a confirmed project bootstrap, humans should be able to use plain task language. Slash commands remain maintainer shortcuts, not the normal user path.
| Where you are | What works automatically | Human entry path |
|---|---|---|
| Meta_Kim repo with Claude Code | Full governance via CLAUDE.md (8-stage spine, gates, dispatch rules) | Say the task naturally; durable work is classified into the governed route |
| Any other project with Claude Code | Global skills can be discovered; global hooks require explicit --with-global-hooks; project-local files are written only after confirmed customization/bootstrap |
Say the task naturally; explicit /meta-theory remains a maintainer shortcut |
| Codex | Global skills plus project AGENTS.md context when present; global hooks require explicit --with-global-hooks; local .codex/agents, .codex/commands, or .agents/skills are project-specific overrides, not default execution-layer projection |
Say the task naturally; Codex classifies durable work, subjective ambiguity, and pure queries differently |
| OpenClaw | Global/shared skills plus OpenClaw config/auth; project openclaw/ material is for project-specific workspace/context overrides |
Requires OpenClaw config/auth; contributors must complete strict OpenClaw self-testing and provide evidence; changes can merge only after that evidence passes review |
| Cursor | Global skills plus project rules/context when present; local .cursor/agents, .cursor/rules, .cursor/skills, hooks, and MCP are project-specific overrides |
Contributors must complete strict Cursor self-testing and provide evidence; changes can merge only after that evidence passes review |
Meta_Kim now tracks platform support in tiers instead of treating every compatible surface as a full runtime projection.
| Tier | Products | What it means |
|---|---|---|
| Default formal projections | Claude Code, Codex | Canonical governance is projected by default, checked by npm run meta:sync / npm run meta:check, and used for the primary prompt-first flow. |
| Non-default compatibility projections | OpenClaw, Cursor | Tool-specific project files are generated only when these targets are selected; runtime changes need maintainer handshake plus tool-side self-test evidence before they are treated as complete. |
| Candidate compatibility probes | Qoder CLI, Trae, Kiro, Windsurf / Devin Desktop Cascade, Cline, Roo Code, Continue | Official docs expose compatible primitives such as rules, skills, agents/modes, hooks, MCP, commands, memory, or permission controls. Meta_Kim records them as candidate probes, not formal supported runtimes yet. |
Source of truth: config/runtime-compatibility-catalog.json.
Surface compatibility is intentionally weaker than runtime support. A tool can share Meta_Kim-compatible primitives and still need adapter design, profile/layout generation, sync tests, and live validation b