Overview
Meta_Kim is not another AI coding tool. It is the governance layer for 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 AI above AI: a unified governance layer that keeps complex work from turning into a mess.
One-line summary
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.
Before / After
| 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 |
3-minute proof
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:
- a fuzzy request is turned into an explicit intent and success standard
- capability search happens before execution ownership is chosen
- work is split into bounded worker tasks instead of one giant chat response
- review and verification produce artifacts, not just reassuring prose
- compatibility evidence stays tiered, so smoke evidence is never promoted to native live proof
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.
Quick Start
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.
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:
- This file,
README.md AGENTS.mdCLAUDE.mdwhen working on Claude Code behaviorcanonical/runtime-assets/cursor/rules/meta-enforcement.mdcwhen working on Cursor rules
Usage Paths
After global install (node setup.mjs or npx), 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 | Hooks (safety, format, memory save) + meta-theory skill | Say the task naturally; explicit /meta-theory remains a maintainer shortcut |
| Codex | AGENTS.md rules + 9 custom agents + meta-theory command | Say the task naturally; Codex classifies durable work, subjective ambiguity, and pure queries differently |
| OpenClaw | Compatible workspace agents, skills, config, and internal lifecycle hooks | Requires OpenClaw config/auth; contributors must complete strict OpenClaw self-testing and provide evidence; changes can merge only after that evidence passes review |
| Cursor | Compatible official subagents, .cursor/rules, hooks, skills, and MCP mirrors |
Contributors must complete strict Cursor self-testing and provide evidence; changes can merge only after that evidence passes review |
Platform Support Tiers
Meta_Kim now tracks platform support in tiers instead of treating every compatible surface as a full runtime projection.
| Tier | Products | What it means |
|---|---|---|
| Formal tool projections | Claude Code, Codex, OpenClaw, Cursor | Canonical governance is projected into tool-specific files and checked by npm run meta:sync / npm run meta:check. |
| Native dependency install targets | opencode, Qwen, Zed, Gemini, CodeBuddy, Antigravity, JoyCode | ECC supports these through its upstream installer, but Meta_Kim does not claim a full runtime projection until profile, layout, sync, and tests exist. |
| Candidate 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 before it becomes a formal projection.
Contact
GitHub KimYx0207 | X @KimYx0207 | Website aiking.dev | WeChat Official Account: 老金带你玩AI
Feishu knowledge base: long-term updates
Buy me a coffee
If Meta_Kim has been useful, support the project with a coffee.
Method basis
Meta_Kim’s methodological foundation comes from research on meta-based intent amplification, authored by this project’s maintainer (KimYx0207):
- Paper: https://zenodo.org/records/18957649
- DOI:
10.5281/zenodo.18957649
Architecture: Hidden Skeleton + Dynamic Dealing
This is the core design idea of Meta_Kim. If you only read one section, read this one.
First, split the core terms so they do not get mixed up later
| Concept | What it is | What it is not |
|---|---|---|
| Hidden skeleton | The backend framework that always exists under the visible workflow | A fixed list of responsibilities written in advance |
| 8-stage workflow | The human-readable execution spine exposed by the hidden skeleton | The whole governance logic |
| 11-phase business workflow | A run-packaging progression layered on top of the 8 stages after classification | A replacement for the 8 stages |
| Dealing | Dynamic control built around the 8-stage workflow and agent units | Simple task assignment |
| Gate | A pass/fail condition | The stage itself |
| Contract | The structured output a node must produce | Slogans or abstract values |
| Agent-unit governance | A practical way to manage boundaries, capabilities, upgrades, and rollback | A role menu |
| Three-layer memory | Long-term memory split across memory / graphify / SQL | One mixed notebook |
If you only want one sentence to remember:
The 8-stage workflow moves execution forward, gates decide whether a stage can pass, contracts define the required outputs, and dealing adds dynamic intervention.
8 stages = the hidden skeleton
Meta_Kim has 8 fixed execution stages. This is the hidden skeleton:
flowchart LR
C[Critical<br/>Clarify the request] --> F[Fetch<br/>Search capabilities]
F --> T[Thinking<br/>Plan the approach]
T --> E[Execution<br/>Dispatch the work]
E --> R[Review<br/>Inspect the result]
R --> MR[Meta-Review<br/>Review the review]
MR --> V[Verification<br/>Verify reality]
V --> EV[Evolution<br/>Write back le