Overview

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.

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.mjs prints where every artifact lives. A global install can use meta-kim status from any directory; an npx install can repeat npx --yes github:KimYx0207/Meta_Kim meta-kim status. Repository maintainers may also use npm run meta:status.

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

Install scope

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

Usage Paths

After 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

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
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 before it becomes a formal projection. Dependency-project install matrices are not repeated here as Meta_Kim support claims.

Contact

Contact QR

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 lessons]

    style C fill:#fbbf24,color:#000
    style F fill:#34d399,color:#000
    style T fill:#60a5fa,color:#000
    style E fill:#f87171,color:#fff
    style R fill:#a78bfa,color:#fff
    style MR fill:#a78bfa,color:#fff
    style V fill:#34d399,color:#000
    style EV fill:#fbbf24,color:#000

Critical - pin down the real problem first

When the request is vague, ask clarifying questions instead of guessing. This stage produces intentPacket, which locks down the real user intent, success criteria, and exclusions. If the request is already clear, the system records an explicit skip reason instead of quietly skipping.

Fetch - search existing capabilities before inventing new ones

Search whether existing agents, skills, tools, or MCP integrations already cover the need. The core idea here is capability-first: define the capability first, then search for the owner that declares it, then dispatch to the best match. Capability-index lookup goes config/capability-index/ -> runtime mirror -> local inventory -> fallback. Do not start by hardcoding a specific agent name.

Governance Decision Engine

Meta_Kim is not only the 8-stage spine. It first identifies the governance trigger, checks runtime and OS capability, checks dependency capability, separates owner from weapon, filters by Win/Mac/runtime support, asks the user only for branch-changing choices, executes deterministic parts, verifies whether the user goal actually landed, and writes reusable learning back. Reference-only projects are absorbed into Meta_Kim data, not silently promoted into dependencies; see config/governance/decision-pattern-catalog.json.

Automation is assistive, not authoritative. It may gather evidence, draft options, run deterministic checks, surface blockers, and prepare readable status, but branch-changing judgment in Critical, Fetch, Thinking, and Review remains a human decision point. A selected capability, hook match, report, or validator pass must not be relabeled as human acceptance or native runtime evidence.

Thinking - define boundaries, owners, sequence, deliverables, risks, and stop conditions

Break the task into subtasks, assign owners, and make dependencies and parallel groups explicit. This stage produces a dispatchBoard: who does what, what can run in parallel, and who is responsible for merging the result. At least two solution paths should be explored; do not lock into a single route too early.

Execution - produce the actual work while still under governance

Dispatch the subtasks to specialist agents. Each subtask is wrapped in a workerTaskPacket, including file context, constraints, review owner, and verification owner. Independent subtasks should run in parallel when possible. Execution is not completion - the output still has to pass review and verification.

Review - check quality and boundary compliance

Inspect code quality, security, architecture compliance, and boundary violations. Produce a structured reviewPacket with findings. Each finding has a severity from CRITICAL to LOW. This is not a formality - unresolved findings cannot move forward.

Meta-Review - inspect whether the review standard itself is biased or too loose

Review the review. If the review standard is too weak, the system is not really reviewing. If it is biased, it is reviewing the wrong thing. This stage protects the quality of the review system itself.

Verification - confirm that reality matches the claim

Verify whether the fixes really closed the review findings. This stage produces verificationResult and closeFindings. If the fix did not actually close the finding, go back and repair it before verifying again. This is the most honest gate in the system.

Evolution - write capability gaps and reusable patterns back into the system

Convert experience into structural upgrades: reusable patterns go into memory, failures become learning artifacts, capability gaps are handed to Scout, and agent boundaries are written back into canonical sources. Every run must end with a writebackDecision: either write back something concrete or explicitly explain why there is nothing to persist. A run that does not preserve learning is wasted work.

The 8 stages together form the execution spine.

Why are they only "relatively" fixed? Because some stages can be skipped in simple cases - but the system must explicitly record why they were skipped. Nothing is skipped silently.

11 phases = a business workflow built on the skeleton

If the 8-stage workflow is the skeleton, then the 11-phase business workflow is the run-packaging progression that grows on top of it:

direction -> planning -> execution -> review -> meta_review -> revision -> verify -> summary -> feedback -> evolve -> mirror

It is not a second system. It is derived from the 8-stage skeleton. The difference is:

The 8 stages focus on execution logic - "what order should work happen in"
The 11 phases focus on business governance - "what each phase must deliver, how completion is defined, and when mirrors must be refreshed"

flowchart TB
    subgraph spine["8-stage workflow (hidden skeleton)"]
        direction LR
        C1[Critical] --> F1[Fetch] --> T1[Thinking] --> E1[Execution] --> R1[Review] --> MR1[Meta-Review] --> V1[Verification] --> EV1[Evolution]
    end

    subgraph workflow["11-phase business workflow"]
        direction LR
        D2[direction] --> P2[planning] --> EX2[execution] --> RE2[review] --> MET2[meta_review] --> REV2[revision] --> VER2[verify] --> SUM2[summary] --> FB2[feedback] --> EVO2[evolve] --> MIR2[mirror]
    end

    C1 -.-> D2
    F1 -.-> P2
    T1 -.-> P2
    E1 -.-> EX2
    R1 -.-> RE2
    MR1 -.-> MET2
    V1 -.-> VER2
    EV1 -.-> EVO2

    style spine fill:#1e1b4b,stroke:#7c3aed,color:#e0e7ff
    style workflow fill:#14532d,stroke:#22c55e,color:#dcfce7

The 11-phase business workflow adds revision, summary, feedback, and mirror, so the process is not only about "getting it done" but also about getting it done well, closing the loop correctly, and keeping runtime projections aligned.

Contracts = what each node must deliver

Workflow alone is not enough. Each stage also needs to define what it must output. That is what the contracts do.

Meta_Kim contracts are not verbal agreements. They are structured packets:

Contract artifact	Stage	Purpose
`coreLoop`	All stages	Compact evidence that the default governed path followed the eight-stage contract
`intentPacket`	Critical	Lock the real intent and prevent drift
`dispatchBoard`	Thinking	Define owners, dependencies, and parallel groups
`workerTaskPacket`	Execution	Carry the full context for each subtask
`reviewPacket`	Review	Record structured findings
`revisionResponse`	Revision	Respond to each review finding
`verificationResult`	Verification	Confirm whether the issue was actually closed
`summaryPacket`	Summary	Final summary before public release
`evolutionWriteback`	Evolution	Define what should be written back

flowchart LR
    subgraph packets["Contract artifact flow"]
        direction LR
        IP[intentPacket<br/>Intent lock] --> DP[dispatchBoard<br/>Dispatch board]
        DP --> WTP[workerTaskPacket<br/>Task packet]
        WTP --> RP[reviewPacket<br/>Review findings]
        RP --> RR[revisionResponse<br/>Revision response]
        RR --> VR[verificationResult<br/>Verification result]
        VR --> SP[summaryPacket<br/>Final summary]
        SP --> EW[evolutionWriteback<br/>Learning writeback]
    end

    IP ~~~ C2["Critical"]
    DP ~~~ T2["Thinking"]
    WTP ~~~ E2["Execution"]
    RP ~~~ R2["Review"]
    RR ~~~ REV2["Revision"]
    VR ~~~ V2["Verification"]
    SP ~~~ S2["Summary"]
    EW ~~~ EV2["Evolution"]

    style packets fill:#1a1a2e,stroke:#e94560,color:#fff

These artifacts are not optional documents. They are the system’s source of truth. Without contracts, the next node is not "handing off" - it is guessing what the previous node meant. That is why so much AI collaboration falls apart on complex work.

The current implementation carries these artifacts explicitly: taskClassification before execution, cardPlanPacket before dealing, dispatchEnvelopePacket before dispatch, reviewPacket.findings after review, revisionResponses + verificationResults + closeFindings between revision and verification, summaryPacket before external publication, and writebackDecision before evolution.

npm run meta:validate:run checks whether these artifact chains close completely.

Gates = stage reached does not mean stage passed

Contracts define what each node must deliver. Gates define whether that delivery is good enough to move forward.

In one sentence:

A stage tells you where you are; a gate tells you whether you are allowed to move on.

flowchart LR
    A["Reach a stage"] --> B{"Gate decision"}
    B -->|Pass| C["Release: move forward"]
    B -->|Fail| D["Revision: add evidence / fix output"]
    B -->|Hold| E["Pause: wait for conditions to mature"]
    B -->|Escalate| F["Higher-level intervention"]

    style A fill:#dbeafe,stroke:#2563eb,color:#000
    style B fill:#7c3aed,stroke:#4c1d95,color:#fff
    style C fill:#dcfce7,stroke:#16a34a,color:#000
    style D fill:#fee2e2,stroke:#dc2626,color:#000
    style E fill:#e0f2fe,stroke:#0284c7,color:#000
    style F fill:#fef3c7,stroke:#f59e0b,color:#000

Key gates in the system:

Gate	What it blocks	Pass condition
planning gate	Moving from planning into execution	Boundaries, owners, deliverables, and risks are defined
metaReview gate	Whether meta-review is strong enough	The review standard itself is not biased, missing, or too loose
verify gate	Whether the fix really closed the issue	`finding -> revision -> verification` closes cleanly
summary gate	Whether the result can be published	Verification passed + summary completed
publicDisplay gate	Whether the system can claim "done"	`verifyPassed + summaryClosed + singleDeliverableMaintained + deliverableChainClosed`

The most important one is the publicDisplay gate. If verification has not passed, the summary is not closed, or the deliverable chain is broken, the system cannot pretend that the work is finished.

The relationship between gates and contracts:

Contracts answer "what must this node deliver" - they are about delivery obligations
Gates answer "is this good enough to move forward" - they are about release decisions
Without contracts, gates have nothing to judge
Without gates, contracts are just a ceremony

Dynamic dealing = flexibility layered on top of the skeleton

The 8-stage skeleton is relatively fixed, but real tasks vary too much to be handled by one rigid path. That is why Meta_Kim introduces dynamic dealing.

Dealing corresponds to the 8 stages, but not as a simple 1:1 map. The 10 cards are:

Card	Trigger condition	Attention cost
Clarify	The request is vague	Low
Shrink scope	The repository is too large or has too many files	Low
Options	The request is clear but there are many possible paths	Medium
Execute	The plan is decided	High
Verify	Execution is complete	Medium
Fix	Verification failed	Medium
Rollback	Risk is spreading	High
Risk	Security, global, or multi-party impact is involved	High
Nudge	The user is stuck and needs a light push	Low
Pause	Three high-cost cards have been used in a row	Zero

The important part is that some cards are dynamic:

When three high-attention cards are dealt consecutively, the system forcibly inserts Pause - it does not wait for the user to notice
When security risk appears, Risk preempts the current flow
When the user already knows something, the corresponding card is skipped
When task iteration exceeds the upper bound, the system escalates to Warden adjudication

Dynamic dealing gives the fixed skeleton some breathing room: strict where it must be strict, flexible where flexibility helps.

flowchart TD
    START[Current card completed] --> SKIP{Check next card<br/>skip_condition}
    SKIP -->|Satisfied, skip| NEXT[Continue to the next card]
    SKIP -->|Not satisfied| INTR{Check interrupt queue}
    INTR -->|Security risk preempts| RISK[Risk card<br/>highest priority]
    INTR -->|No preemption| PAUSE{Three or more<br/>high-cost cards?}
    PAUSE -->|Yes, force a break| P[Pause card<br/>zero attention]
    PAUSE -->|No| DEAL[Deal by priority]
    RISK --> DEAL
    P --> DEAL
    DEAL --> COUNT{Iterations over<br/>max_iterations?}
    COUNT -->|Yes| WARDEN[Escalate to Warden adjudication]
    COUNT -->|No| START

    style RISK fill:#dc2626,color:#fff
    style P fill:#1e3a5f,color:#93c5fd
    style WARDEN fill:#7c3aed,color:#fff
    style DEAL fill:#16a34a,color:#fff

Closed loop = iterate, generate, improve

Once the skeleton, progression workflow, contracts, and dynamic dealing are in place, the system forms a closed loop:

Request arrives -> skeleton starts -> dealing decision -> dispatch execution -> review and verify -> preserve lessons -> upgrade agents -> next run starts stronger

The loop is not one-and-done. Each round can:

Generate the missing agent - if a capability gap appears, the system can create a new agent through the Type B pipeline
Improve agent capability - Evolution writes back changes to SOUL.md, skill loadouts, and toolchains
Clarify every agent’s boundary - each agent owns one class of work; boundary violations are intercepted by Sentinel

flowchart TD
    INPUT[Request arrives] --> SPINE[Hidden skeleton starts]
    SPINE --> CARD[Dynamic dealing decision]
    CARD --> DISPATCH[Dispatch to specialist agent]
    DISPATCH --> REVIEW[Review + verification]
    REVIEW --> |Pass| EVOLVE[Preserve lessons]
    REVIEW --> |Fail| FIX[Fix + review again]
    FIX --> REVIEW
    EVOLVE --> UPGRADE[Upgrade agent capability]
    UPGRADE --> |Capability gap found| CREATE[Type B pipeline<br/>auto-create new agent]
    UPGRADE --> |Boundary needs adjustment| BOUNDARY[Adjust agent boundary]
    CREATE --> INPUT2[Next run starts stronger]
    BOUNDARY --> INPUT2

    style INPUT fill:#fbbf24,color:#000
    style EVOLVE fill:#34d399,color:#000
    style CREATE fill:#f87171,color:#fff
    style INPUT2 fill:#fbbf24,color:#000

Agent boundaries + skill integration

The 9 meta roles each own a different domain:

Role	Responsibility	What it does not own
meta-warden	Coordination, arbitration, final synthesis	Does not directly write code
meta-conductor	Workflow and rhythm control	Does not do security review
meta-genesis	Agent design and SOUL.md	Does not choose tools
meta-artisan	Skill, MCP, and tool matching	Does not define persona
meta-sentinel	Security, permissions, rollback	Does not choreograph rhythm
meta-librarian	Memory and continuity	Does not execute code
meta-prism	Quality review and anti-slop	Does not search for capabilities
meta-scout	External capability discovery	Does not coordinate internally
meta-chrysalis	Evolution writeback, scar capture, recursive-safety gatekeeping	Does not evolve itself or bypass Warden gates

Each agent can load powerful skills and commands as needed. Meta_Kim ships with 9 community skills and supports custom extension.

flowchart TD
    WARDEN[meta-warden<br/>Coordination / arbitration / synthesis] --> CONDUCTOR[meta-conductor<br/>Workflow / rhythm]
    WARDEN --> GENESIS[meta-genesis<br/>Agent design]
    WARDEN --> ARTISAN[meta-artisan<br/>Skill / tool matching]
    WARDEN --> SENTINEL[meta-sentinel<br/>Security / permissions / rollback]
    WARDEN --> LIBRARIAN[meta-librarian<br/>Memory / continuity]
    WARDEN --> PRISM[meta-prism<br/>Quality review]
    WARDEN --> SCOUT[meta-scout<br/>External capability discovery]
    WARDEN --> CHRYSALIS[meta-chrysalis<br/>Evolution writeback]

    GENESIS -.-> |SOUL.md| ARTISAN
    ARTISAN -.-> |Skill loadout| GENESIS
    CONDUCTOR -.-> |Task board| WARDEN
    SENTINEL -.-> |Security interception| WARDEN
    PRISM -.-> |Review report| WARDEN
    SCOUT -.-> |Capability candidates| ARTISAN
    LIBRARIAN -.-> |Context memory| WARDEN
    CHRYSALIS -.-> |Scar / writeback proposal| WARDEN

    SKILLS[9 community skills<br/>+ custom extensions] --> ARTISAN
    HOOKS[Hook automation<br/>intercept / format / check] --> SENTINEL

    style WARDEN fill:#7c3aed,color:#fff
    style CONDUCTOR fill:#60a5fa,color:#000
    style GENESIS fill:#fbbf24,color:#000
    style ARTISAN fill:#34d399,color:#000
    style SENTINEL fill:#f87171,color:#fff
    style LIBRARIAN fill:#a78bfa,color:#fff
    style PRISM fill:#fb923c,color:#000
    style SCOUT fill:#2dd4bf,color:#000
    style CHRYSALIS fill:#84cc16,color:#000

Hook automation

In Claude Code, Meta_Kim uses hooks for automation:

Dangerous command blocking: operations like rm -rf and DROP TABLE are blocked automatically
Git push reminder: remind you to check before pushing
Formatting: automatically format JS/TS files after edits
Type checking: run TypeScript checks after edits
console.log warning: remind you to remove console.log
Session-end audit: check for leftover issues before the session ends
Session-end memory save: write session summaries to MCP Memory Service on session end
Subagent context injection: automatically inject project context into subagents

These hooks are not optional polish. They are the execution-layer guardrails of the governance system.

Cross-platform mapping

A new platform can be evaluated when it exposes Meta_Kim-compatible primitives, but it is not a formal projection until profile, layout, sync, tests, and evidence exist.

Meta_Kim currently owns two default formal projection targets and two non-default compatibility projection targets:

Platform	Status	Mapping style
Claude Code	Default formal projection	`.claude/agents/*.md` + `SKILL.md` + hooks + MCP; primary prompt-first path verified by sync/check and maintained as a default target
Codex	Default formal projection	generated local `.codex/agents/*.toml` for the nine governance agents + `.agents/skills/` + commands + hooks; primary prompt-first path verified by sync/check and maintained as a default target
OpenClaw	Non-default compatibility projection; maintainer handshake required	`openclaw/` workspaces + skills + internal hooks; stricter tool-denial changes need contributor-owned OpenClaw self-test evidence, and can merge only after that evidence passes review
Cursor	Non-default compatibility projection; maintainer handshake required	`.cursor/agents/.md` + `.cursor/rules/.mdc` + skills + hooks + MCP; Cursor changes need contributor-owned Cursor self-test evidence, and can merge only after that evidence passes review

Meta_Kim also tracks candidate compatibility probes for Qoder CLI, Trae, Kiro, Windsurf / Devin Desktop Cascade, Cline, Roo Code, and Continue. These products expose compatible primitives in their official docs, but setup does not generate project projections for them until a runtime profile, projection layout, generated paths, sync tests, install policy, and live or official probe evidence are added.

The canonical source layer is canonical/agents/, canonical/skills/meta-theory/, config/contracts/, and config/capability-index/. The repository mirrors that layer into platform-specific projections through npm run meta:sync.

Open-source boundary: Generated runtime projection directories are local outputs, gitignored, and not GitHub source. That includes .claude/, .codex/, .agents/, .cursor/, openclaw/, .mcp.json, and codex/. The nine governance agents live in canonical/agents/; Meta_Kim sync does not generate execution-layer Codex agents such as worker, explorer, frontend, backend, test, review, analysis, verify, or docs.

flowchart TB
    CANONICAL["canonical/ + config/<br/>(single source layer)"]

    CANONICAL --> |npm run meta:sync| CLAUDE[".claude/<br/>Claude Code<br/>agents + skills + hooks"]
    CANONICAL --> |npm run meta:sync| CODEX[".codex/ + .agents/<br/>Codex<br/>governance agents.toml + skills + hooks"]
    CANONICAL --> |npm run meta:sync| OPENCLAW["openclaw/<br/>OpenClaw<br/>workspaces + skills + internal hooks"]
    CANONICAL --> |npm run meta:sync| CURSOR[".cursor/<br/>Cursor<br/>agents + rules + skills + hooks + MCP"]

    CANDIDATE["candidate probes<br/>Qoder / Trae / Kiro / Cascade / Cline / Roo / Continue"] -.-> |promotion requires profile + layout + tests + evidence| CANONICAL

    style CANONICAL fill:#7c3aed,color:#fff
    style CLAUDE fill:#fbbf24,color:#000
    style CODEX fill:#34d399,color:#000
    style OPENCLAW fill:#60a5fa,color:#000
    style CURSOR fill:#f87171,color:#fff
    style CANDIDATE fill:#555,color:#aaa

You can keep adding platform mappings over time, but the upgrade path is gated: a candidate becomes a formal projection only after Meta_Kim owns the adapter shape and can verify it.

The four tool targets are first-class Meta_Kim projection families, but their native surfaces and evidence levels differ. Claude Code and Codex are the default selected primary path. OpenClaw and Cursor are available non-default compatibility projections: use them with maintainer handshake, and treat runtime changes as incomplete until strict contributor-owned self-test evidence from that tool passes review. Projection smoke, fixture validation, and generated reports are useful evidence, but they are not the same thing as native-live runtime proof.

Capability surface	Claude Code	Codex	OpenClaw	Cursor
Agents	Native agents/subagents, mature at both project and user scope	Strong custom agents/subagents	Workspace-style agents, supports agent-to-agent	Official subagents under `.cursor/agents` with project-rule compatible governance context
Skills / references	Native skills, references, and a mature global ecosystem	`.agents/skills/` is the project skill root	Workspace skills and installable skills	Project skill/reference mirrors
Hooks / automation	Project hooks + settings.json + plugin ecosystem	Trusted `.codex/hooks.json` project/user hooks	Internal lifecycle hooks; typed plugin hooks needed for blocking/canceling policy	`.cursor/hooks.json` lowerCamel lifecycle hooks with `preToolUse` / `failClosed`
MCP / configuration	Full native MCP and config surface	Can connect via runtime adapters and MCP	Clear workspace config	Project MCP and configuration mirrors
Governance loop support	Default formal projection through Claude-native surfaces	Default formal projection through Codex-native surfaces	Non-default formal projection through OpenClaw-native surfaces; typed plugin tool-denial changes need strict tests	Non-default formal projection through Cursor-native surfaces; project decision cards and official hook gates preserve native semantics

The point is format discipline, not a ranking: each formal tool target keeps its own agent, skill, hook, MCP, choice, and config surface instead of pretending one host's format is universal.

Choice surfaces are tool-specific. Claude Code should use AskUserQuestion; Codex should use request_user_input when ~/.codex/config.toml has [features].default_mode_request_user_input = true; Cursor uses an alwaysApply project rule to trigger a chat decision card plus official preToolUse / failClosed hooks for tool gating; OpenClaw uses workspace/chat cards unless a typed plugin approval hook is explicitly installed and strictly tested.

Four-layer repository structure

Layer	Location	Purpose
Canonical source	`canonical/agents/`, `canonical/skills/meta-theory/`, `config/contracts/`, `config/capability-index/`	Preferred place for long-term edits
Tool projections	`.claude/`, `.codex/`, `openclaw/`, `.cursor/`	Mirrors of the same capabilities for different tool targets
Local state	`.meta-kim/state/{profile}/`, `.meta-kim/local.overrides.json`	Profile-level state, run index, continuity
Scripts and checks	`scripts/`, `npm run *`	Sync, validate, discover, and accept

Three state layers (project / global / local)

These three layers are easy to mix up, so they must stay separate:

Layer	Storage location	What it decides
Project-level	Current repository `canonical/`, `config/contracts/`, `config/capability-index/`, runtime projections, docs, scripts	What this project itself defines
Global-level	`~/.claude/`, `~/.codex/`, `~/.openclaw/`, `~/.cursor/`, `~/.meta-kim/global/`	What can still be discovered on this machine
Local-level	`.meta-kim/state/{profile}/run-index.sqlite`, `compaction/`, `profile.json`	What a run left behind for this profile

What lives inside `.meta-kim/`?

.meta-kim/ is Meta_Kim's local save file. It does three things:

1. Remembers your choices — local.overrides.json

When you run node setup.mjs for the first time and pick "I want Claude Code and Codex", that choice is saved here. Next time you run setup, you don't have to choose again.

Example: You have Claude Code, Codex, and OpenClaw installed, but only want the first two. This file stores that preference — all scripts read it to know which runtimes to install skills for.

2. Records work history — state/{profile}/run-index.sqlite

When you run a governed workflow (e.g. "use the 8-stage spine to review some code"), the result can be indexed into a SQLite database. Later you can query "what did I review last time, what was found, what's still unresolved?"

Example: Last week you asked meta-prism to review the auth module. This week you changed the auth module again. The system checks .meta-kim/state/ and finds "last review found 3 issues, 2 were fixed, 1 is still open" — you don't have to repeat yourself.

3. Cross-session recovery — state/{profile}/compaction/

When you're halfway through a conversation and your token budget runs out, the compaction packet saves your current progress (which step you're on, what's still pending) s

Meta Kim

README

Overview

One-line summary

Before / After

3-minute proof

Quick Start

Install scope

Usage Paths

Platform Support Tiers

Contact

Buy me a coffee

Method basis

Architecture: Hidden Skeleton + Dynamic Dealing

First, split the core terms so they do not get mixed up later

8 stages = the hidden skeleton

11 phases = a business workflow built on the skeleton

Contracts = what each node must deliver

Gates = stage reached does not mean stage passed

Dynamic dealing = flexibility layered on top of the skeleton

Closed loop = iterate, generate, improve

Agent boundaries + skill integration

Hook automation

Cross-platform mapping

Four-layer repository structure

Three state layers (project / global / local)

What lives inside `.meta-kim/`?

Comments (0)

Meta Kim

README

Overview

One-line summary

Before / After

3-minute proof

Quick Start

Install scope

Usage Paths

Platform Support Tiers

Contact

Buy me a coffee

Method basis

Architecture: Hidden Skeleton + Dynamic Dealing

First, split the core terms so they do not get mixed up later

8 stages = the hidden skeleton

11 phases = a business workflow built on the skeleton

Contracts = what each node must deliver

Gates = stage reached does not mean stage passed

Dynamic dealing = flexibility layered on top of the skeleton

Closed loop = iterate, generate, improve

Agent boundaries + skill integration

Hook automation

Cross-platform mapping

Four-layer repository structure

Three state layers (project / global / local)

What lives inside .meta-kim/?

Comments (0)

What lives inside `.meta-kim/`?