Can I use Kodelyth ECC in Cursor?

Yes. Run `kodelythecc --target cursor-project` inside a Cursor project. It writes all 71 agents, 196 skills, and 104 commands to the project's `.cursor/` directory, auto-registers the MCP server in `.cursor/mcp.json`, and installs RTK + Terse for token savings. Your existing `.cursorrules` file is untouched.

Does ECC replace .cursorrules?

No. `.cursorrules` is still the right place for always-on project conventions (your preferred libraries, your style guide, your ban-list). ECC adds the per-task specialists, token savings, and MCP layer around it. Use both.

What does ECC give me that Cursor doesn't already have?

The things Cursor doesn't ship: 71 specialist agents routable by plain-language intent (no names to memorise), a universal MCP server exposing them to any client, RTK shell-output compression (60-90% input token reduction), Terse mode output compression (40-70%), a codebase AST graph across 158 languages, and local Memory Core recall that survives a repo move.

Does ECC send any data to a cloud when used in Cursor?

No. ECC is fully local. Memory, RTK, Terse, routing, codebase graph — all run on your machine. Zero telemetry.

What about Cursor's own built-in agents and composer?

They stay. ECC does not patch or override them. The specialists ECC adds are invoked by plain-language routing or `use `, so they only engage when your intent matches — Cursor's defaults still handle the baseline.

By Kodelyth · updated November 11, 2026 · v2.30.0

Kodelyth ECC vs Cursor Rules

Short version. Cursor Rules is a single flat text file that gets injected into every message as persistent instructions. Kodelyth ECC is a toolkit that installs 71 specialist AI agents, a universal MCP server, local memory recall, and two independent token-compression layers into your project. They solve different problems at different layers — and ECC runs inside Cursor, next to your .cursorrules.

Different problems, different layers

Need	Cursor Rules	Kodelyth ECC
"Always use pnpm, never npm"	✓ Best fit	—
"Never add a new dependency"	✓ Best fit	—
"Our style guide for React components"	✓ Best fit	—
"I'm stuck on this NullPointerException"	—	✓ Routes to `debug-detective`
"Review this PR for security + perf + a11y"	—	✓ `/team-review` fires 4 agents in parallel
"Who calls this function?"	—	✓ Codebase graph, one MCP call
"Reduce my Claude Code token bill"	—	✓ RTK + Terse + graph queries
"Remember how I fixed this last time"	—	✓ Memory Core (local, git-remote-identified)
"Bridge all my tools to Claude Desktop"	—	✓ MCP server auto-wires 6 IDEs

Rules excel when the instruction is persistent and project-scoped. ECC excels when the work is task-specific and routable.

What `.cursorrules` is good at

The .cursorrules file is a flat, always-prepended text file. It is Cursor's answer to "every session should know X about my codebase." A good rules file captures:

Libraries you use and ban
Your naming conventions
Your test framework and coverage expectations
The one or two patterns you re-litigate in code review

It's the right place for things that never change per-task. You should keep it tight — every line is paid for on every message.

What ECC adds on top

ECC installs under .cursor/ in your project and auto-wires its MCP server into Cursor's config. What you get:

71 specialist agents auto-selected by plain-language intent routing — no names to remember. See intent routing.
Universal MCP server that bridges those agents, 196 skills, 104 commands, and your local memory to any MCP-aware client.
RTK compresses shell-command output before it reaches the model — 60-90% input token reduction on git, cargo test, docker ps, and 100+ more. See RTK.
Terse mode compresses the AI's replies — 40-70% output token reduction, code preserved byte-exact. See Terse mode.
Codebase graph across 158 languages — "who calls this" in ~3.4k tokens instead of ~412k. See codebase graph.
Memory Core — local BM25 memory keyed by git remote, redacts secrets on capture, fuses relevance × recency × outcome. See Memory Core.
Super Agent — the autonomous orchestrator for objectives too big for one pass. See Super Agent.

How to install ECC into Cursor

npm i -g kodelyth-ecc
# From the root of your Cursor project:
kodelythecc --target cursor-project --codebase-graph

That drops all of ECC into .cursor/ alongside your existing Cursor config, registers the MCP server in .cursor/mcp.json, and installs RTK + Terse. .cursorrules is not touched.

Then restart Cursor so it picks up the new MCP server.

The honest tradeoffs

Cursor Rules is better when:

The rule is truly always-on. Specialists in ECC only engage when your intent matches; a rule file is always-present whether it fires or not.
The rule is one-liner-shaped. ECC's layered system is overkill for "use tabs not spaces."
You need something a non-technical teammate can edit. A single text file is easier than a package.

ECC is better when:

You keep forgetting which agent name to use for which task. Intent routing removes that step.
You've measured a token bill high enough to notice. RTK + Terse + graph queries compound to 55-65% total reduction on typical sessions.
You work across more than one AI tool. ECC installs into Cursor, Claude Code, Windsurf, Codex, Antigravity, Kiro, and 6 more — the same agents everywhere.
You want your sessions to compound. Memory Core recalls past solutions on every new prompt so you don't re-solve the same bug.

Bottom line

Keep .cursorrules for your project's always-on conventions. Add ECC for the specialists, token savings, memory, and MCP layer around it. They stack without stepping on each other, and ECC's install is non-destructive.

npm i -g kodelyth-ecc && kodelythecc --target cursor-project --codebase-graph

Last updated: 2026-11-11T00:00:00.000Z · v2.30.0