ECC is an open source engineering system for code agents: it installs a fixed workflow of plan → test → implement → review → verify into Claude Code, Codex, Cursor, and a dozen more harnesses. Instead of rebuilding that process in every prompt, you install it once and it becomes part of how your agent works.
Note from September 18, 2026. This article replaces our May 2026 version. Three things in it were wrong or had become outdated: the repository changed names from
everything-claude-codetoECC, the version and component counts advanced two releases, and we attributed ECC’s origin to a hackathon. That last point was our error, corrected below.
I covered this project twice this year and both times I underestimated what it was becoming. In May it looked like a well-built plugin with an interesting security scanner bolted on. Today it has 262K stars, 39.2K forks, and—more importantly for anyone making an adoption decision—it stopped being a Claude Code plugin.
The name change is the signal.
What is ECC and why did it change its name?
The project was called Everything Claude Code. Today it’s simply ECC and the repository lives at affaan-m/ECC. That’s not cosmetic. A tool carrying the name of a single vendor’s product can’t credibly position itself as the portability layer between seven of them.
Now there are three public identifiers, and the README is explicit that they are not interchangeable:
| What | Identifier |
|---|---|
| GitHub Repository | affaan-m/ECC |
| Claude Code Plugin | ecc@ecc |
| npm Package | ecc-universal |
The plugin identifier is short on purpose: long marketplace names exceed length validators on some Desktop and API clients. The README calls the old long identifier “just a legacy alias”, meaning any installation instructions you saved from early this year—including ours from May—point to the wrong name.
The current release is 2.2.1, published to npm on September 8, 2026. MIT license, and the README commits to maintaining it permanently.
What does ECC include when you install it?
| Component | Count | What it does |
|---|---|---|
| Agents | 68 | Planning, review, build repair, security, architecture, language-specific review |
| Skills | 292 | TDD, research, security, docs, frontend, data, ML, operations |
| Commands | 94 | Slash command shims, maintained for compatibility during the migration to skills |
| Hooks and Memory | Runtime | Enforcement, session summaries, continuous learning, context control |
| Rules | Selective | Always-loaded standards that you choose by language |
| AgentShield | Included | Scans prompts, hooks, MCP config, permissions, secrets, and agent files |
Our May article said 28 agents. The direction of movement is obvious, and it’s also the first thing I’d question: 292 skills is a lot of surface to audit. The README itself concedes this. The Claude Code plugin “announces the installed catalog to the model”, so the documentation recommends a selective profile when context footprint matters. That’s unusually honest for a project to write about its own primary installation path.
What are the 68 Claude Code sub-agents for?
The architectural decision that seems most defensible to me is that skills, not commands, are now the primary surface. Commands remain as shims; retired ones moved to a legacy-command-shims/ directory you have to explicitly opt into. That’s deprecation with a migration path, not a rename that breaks everything.
The 68 agents are specialized by function and by language: planning, architecture, TDD guidance, code review, security review, build error resolution, and dedicated reviewers for TypeScript, Python, Go, Rust, Java, Kotlin, C++, F#, and ArkTS, among others.
The real value of a sub-agent isn’t that it knows more. It’s that it runs with its own context and its own tool permissions. The code reviewer doesn’t see the reasoning behind how that code was written, and that’s why it finds things the original context can’t see. Isolating planning, implementation, and review into separate contexts is the mechanism, and the agent count is just the consequence.
Which harnesses does it actually support?
This is where the project earns credibility, because it publishes a capability matrix that admits where it doesn’t work:
| Harness | Status |
|---|---|
| Claude Code | Stable, primary |
| Codex | Native plugin supported |
| Cursor | Project adapter in beta |
| OpenCode | Compiled plugin in beta |
| GitHub Copilot | Instructions only: no hooks, no agents, no delegation |
| Gemini, Zed, Antigravity, Qwen, Hermes, OpenClaw, Kimi, CodeBuddy, JoyCode | Experimental or minimal adapters |
The README’s own framing: treat those labels “as capability statements, not marketing tiers”. Support for Copilot means a versioned instructions file and five prompt files, and the documentation says it plainly: Copilot has no hooks system or sub-agent API, so the automation layer simply isn’t there.
Compare that to how most multiplatform tooling gets marketed and you understand why more than 113 contributors keep showing up.
Why does memory across harnesses matter more than the number of agents?
Because it’s the real problem teams have in 2026, and almost nobody is solving it.
If your team uses Claude Code and Codex and Cursor—as most do today—the accumulated context of your agent gets trapped by tool. Each change starts from zero. ECC’s answer is the Memory Vault: portable markdown documents under .ecc/memory/ for project and team scope, and ~/.ecc/memory/ for user scope, readable by Claude, Codex, Hermes, OpenClaw, and Kimi through a single format.
Two caveats that matter, both from the project documentation. The runtime doesn’t land on the PATH with plugin installations, minimal or manual: the npm package installs separately. And the trust boundary is declared without ambiguity: memory is “unreviewed context, not executable policy”. Retrieved entries should never be treated as instructions.
For anyone who’s thought about prompt injection through a shared context store, that’s the right default. And it’s the opposite of what a vendor trying to sell you a memory feature would say.## How Much Context Does It Consume and What Should You Disable?
The ECC project’s own guide is the most useful resource in the repository for a technical leader, and it contradicts the maximalist instinct that the star count invites.
Recommended configuration for ~/.claude/settings.json, according to the project’s token optimization guide:
{
"model": "sonnet",
"env": {
"MAX_THINKING_TOKENS": "10000",
"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50",
"CLAUDE_CODE_SUBAGENT_MODEL": "haiku"
}
}
And the constraint I would put in front of every engineer on a team adopting this: don’t enable all MCP servers at once. Tool descriptions from each server consume your context window before you write anything. The ceilings the project declares are fewer than 10 MCP servers per project and fewer than 80 active tools.
ECC practices this on itself. It ships with exactly one MCP connector by default, chrome-devtools. A June 2026 audit removed the six before it. A project that strips its own defaults to protect your context budget is making a design argument, not a marketing one.
What Risks Are There Before Adopting It Team-Wide?
Four, stated honestly.
Single maintainer. ECC publishes weekly across seven harnesses on the work of one person, funded by sponsors and a paid GitHub App (ECC Pro, private repos from $19 per seat per month; the OSS repo remains MIT). It’s notable throughput and concentrated dependency.
Stacking installations breaks things. Installing the plugin and then running the manual installer duplicates skills, commands, and hooks, and causes hooks to execute twice. The repository has a documented history of exactly this problem. Choose one path per harness.
Windows is not on par. The main CLI runs on Windows, macOS, and Linux, but the continuous-learning v2 watcher daemon and memory vault writes have open defects on native Windows, and several shell-dependent features need Git Bash or WSL.
Part of the roadmap is undelivered. The Itô compute client is explicitly unpublished—you compile it locally—and managed inference through it is not live. At the time of this writing, you need to read the capability statements, not the features list.
It’s also worth flagging: the 1,282 tests, 98% coverage, and 102 static analysis rules in AgentShield are figures reported by the project itself, not independently audited. They’re plausible and strikingly specific. They remain self-reported.
Our Correction on Origins
Our May article was titled “From Hackathon to 197K Stars.” That framing was wrong, and it’s worth correcting precisely rather than silently.
AgentShield—the security scanner component—was built at the Claude Code Hackathon of Cerebral Valley × Anthropic in February 2026. Separately, the maintainer won an Anthropic × Forum Ventures hackathon in September 2025 and built zenith.chat with agentic flows. That’s their trajectory, not ECC’s origin story. The README doesn’t attribute ECC to a hackathon, and neither should we have.
If you came looking for the security piece, we covered it in detail here: Everything Claude Code (ECC): The Scanner That Audits Your AI Setup Before an Attacker Does. Note that the installation commands in that article predate the name change.
My Take: This Is Already Infrastructure, Not a Tool
In May I argued that ECC was becoming the .editorconfig of agent behavior: a file no one thinks about and that every project assumes is there. I still believe the shape of that argument was right, and I want to be specific about what part I got wrong.
I framed it as a standard for agent behavior. What the last four months show is that the durable layer isn’t behavior, it’s portability. TDD rules and enforcement are valuable, but they’re also the part any team could write on their own in a week. What a team can’t easily build is a single definition of their engineering process that survives a move from Claude Code to Codex, plus a context store that travels with it.
That’s the bet the name change makes, and that’s why I’d evaluate ECC differently today than I did in May. The question isn’t “should we adopt ECC.” It’s narrower and more useful: how much of our agent configuration do we want to be portable across providers, and what are we willing to pay in context budget for that?
The answer probably isn’t the full catalog of 292 skills. Selective installation exists precisely because the maintainer knows this.
Has your team reached the point where agent context trapped in a single tool became a real cost? That’s the problem ECC is pointing at now, and I’m curious whether it lands.