kilo-kit-mcp: a five gate lifecycle enforced in JSON-RPC instead of your rules file

The gate lives in the protocol, not in your rules file

The stated starting point is that prompt rules do not hold. Traditional instruction files, `.cursorrules` and `CLAUDE.md`, are said to suffer from prompt drift, so the safety rules are enforced instead through JSON-RPC interceptor middleware sitting between the host agent and the tools. The difference is one of layer. An instruction can be ignored, restated or summarized away by the model; a middleware check either passes or returns an error. The documented sequence is that a user prompt reaches the host agent, an unauthorized edit attempt hits the Kilo-Sentinel pre-flight lock, and an uninitialized or unread file produces a 403 hard-gate block that forces planning first. Only after C4 planning, a commit of the chain of thought to SQLite and an explicit user approval does the gate report a state of READY and let execution proceed.

Five gates, and low confidence reroutes the work

Every task runs through a five-gate state machine. Gate 1 is a grounded probe doing memory recall and a codebase probe. Gate 2 is cognitive reasoning with a three-option Tree of Thoughts DAG, an adversarial grill and a low-confidence escalator. Gate 3 is approval, where the plan locks and skills are injected. Gate 4 is execution under defense-in-depth with Sentinel guarding. Gate 5 is 4D quality assurance, running Playwright end-to-end checks and a SQLite reflection. The routing between them is numeric: confidence of 0.70 or above advances from Gate 2 to Gate 3, and anything below 0.70 diverts into a research subagent instead of proceeding to approval. Unauthorized file mutations attempted before Gate 3 are blocked at the server level rather than warned about.

Sentinel watches for repetition, not only for failure

The supervisor covers two failure modes that do not look like errors. Loop tripwires detect identical repeated calls and edit thrashing, the case where an agent rewrites the same file repeatedly without converging. Separately, a step budget bounds how much a single task may consume. Every trajectory is written to SQLite in a table called `katl_trajectories`. Two tools expose this layer to the outside: `kilo_sentinel_status` reports circuit breaker state, the remaining step budget and the list of grounded files, and `kilo_reset_circuit_breaker` is a supervised reset that requires root-cause justification before a tripped breaker is cleared. So a reset is an event with a reason attached rather than a button, which is the difference between a circuit breaker and a mute.

SQLite holds decisions, facts and reflections

Three tools manage the persistent store. `kilo_memory_report` inspects decisions, facts and sessions already recorded. `kilo_remember_fact` pins immutable operational rules and architectural decisions into a SQLite table called `memory_facts`, and the word pinned is literal, since facts are described as immutable rather than editable. `kilo_record_reflection` persists reflections, the correct and wrong paths, and lessons, and is labelled the self-improvement mechanism. The version history shows this store maturing quickly: v1.8.8 added the Remember Fact tool together with SQLite WAL mode and an enhanced decision engine, and v1.9.0 added a reasoning store alongside grounded cognitive triangulation and the low-confidence escalation. A schema you can query is a different proposition from a prompt telling the agent to remember things.

The catalog is 180 skills, reachable by alias

Skill loading is the other half of the runtime. `kilo_get_skill` loads curated `SKILL.md` workflows with token-safe truncation and session tracking, so a long skill is trimmed rather than dumped into the context whole. `kilo_search_skills` does semantic and keyword search across the 180-skill catalog. A fuzzy resolver accepts aliases, with `brainstorming`, `diagnose`, `playwright`, `clean-code`, `tdd` and `grounded-research-benchmark` named as examples, which means an agent can ask for a mode rather than remembering a slug. `kilo_synthesize_skill` closes the loop by distilling solved patterns into reusable skills, so the catalog is meant to grow from use. `kilo_validate_skills` then runs the whole catalog against the quality gate, and it is not optional: the publish script ends by running `node src/tools/validate-skill.js --all skills`.

Compaction and red-teaming are tools, not prompts

Four reasoning tools carry the cognitive load. `kilo_think_step` builds a Tree of Thoughts DAG with step-by-step reasoning, a three-option trade-off matrix and hypothesis branching. `kilo_grill_plan` attacks the plan adversarially through inversion, simplification, mobile touch and concurrency stress testing. `kilo_trace_root_cause` runs a 5-Whys diagnostic with recursive causal back-propagation and scaffolds regression tests as it goes. `kilo_compact_context` is a cognitive compactor claiming 40 to 70 percent token savings while locking invariants, so the reduction is meant to preserve the constraints rather than summarise them away. The verification side is the 4D gate: Given-When-Then acceptance criteria, clean code interfaces, UI and UX aesthetics, and automated Playwright browser and DOM checks, all before work is marked complete.

A Node package labelled Python, and 23 tools called 24

Two counts in this repository do not line up with each other. The repository is labelled with Python as its primary language, while the build is a Node ES module project: `type` is `module`, `main` is `mcp/dist/server.js`, and the container is built from `node:22-alpine` with `npm --prefix mcp install`. The only two runtime dependencies are `@modelcontextprotocol/sdk` and `zod`. Separately, a heading calls the suite the 24 all-in-one MCP tools suite, while the v1.8.9 release note is titled a universal trajectory ledger for all 23 tools, and the visible tool table accounts for seventeen names before it is truncated. Four binaries ship, `kilo-kit-mcp`, `kilo-kit-init`, `kilo-kit-setup` and `kilo-kit-doctor`, with the last two pointing at the same `mcp/dist/init.js`.

Client config examples ship inside the npm tarball

The published file list is narrower than the repository and is worth reading as the supported surface. It carries `LICENSE`, `README.md`, `QUICKSTART.md`, two configuration examples named `.mcp/kilo-kit.example.json` and `.mcp/kilo-kit.codex-windows.toml`, the `mcp/` build output, the `skills/` catalog, `src/core/KILO_MASTER.md` and `src/tools/validate-skill.js`. Configuration templates travel with the package because the server is consumed by editors rather than run standalone, and the named host clients are Claude Code, Antigravity, Cursor and Gemini CLI. The repository root additionally carries host-specific directories for Claude, Codex, Cursor, OpenCode and VS Code, an `AGENTS.md`, a `GEMINI.md`, a `CLAUDE.md`, a `glama.json` manifest, and examples split into `basic`, `intermediate` and `advanced` directories.

Editorial conclusion

Use it if you want gates that survive prompt drift, because the enforcement lives in the protocol layer rather than in instructions the model can talk past. Do not adopt it expecting a settled tool surface, since the tool count is stated as 24 in one place and 23 in a release note, and the quality claims such as 40 to 70 percent token saving are vendor numbers with no published measurement attached. Before you wire it into a client, read the tool table rather than the marketing headings, check that your host is one of the named clients, and run kilo-kit-doctor, since four binaries ship for exactly that kind of environment check.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes