ECC - Agent Harness Operating System for Coding Agents

ECC installs an engineering process into a coding agent rather than a feature. Its own summary of that process is a single line:

plan -> test -> implement -> review -> verify -> remember -> improve

Install it once, and your agent “plans before it builds, verifies changes with tests, reviews its own work from a fresh context, remembers what matters, and turns repeated wins into reusable skills and workflows.” It is MIT licensed, at version 2.2.3, and it is big.

One note before anything else, because it saves a wasted comparison: ECC is published at two GitHub URLs — affaan-m/ecc and affaan-m/everything-claude-code. They are the same repository. At the commit we checked they shared an identical HEAD, the same tree hash and the same 4,609 tracked files. If you have seen both names and assumed they were related-but-different tools, they are one project.

The catalogue, counted

The README states its size precisely: 71 agents, 311 skills, 97 commands. We cloned the repository and counted — 71 files under agents/, 311 directories under skills/, 97 under commands/, at version 2.2.3.

The numbers are exact. That is worth noting, because inflated counts are common in this category and the first thing a large catalogue usually gets wrong is its own arithmetic.

The constraint the project names itself

The repository’s slogan is the most useful sentence in it:

“Optimize the context window. Persist everything else.”

That is the real problem a 311-skill catalogue creates, and the project is unusually direct about it. From the platform support matrix, on Claude Code — its primary target:

“The plugin advertises the installed catalog to the model; use a selective/manual profile when context footprint matters.”

Read that carefully. Installing everything does not sit inertly on disk. The catalogue is described to the model, which means the breadth you installed is paid for out of the same context window your actual code has to fit into. More capability installed means less room to work.

The documentation puts a figure on the related MCP case, framed as the project’s own estimate rather than a measurement we can reproduce: “Don’t enable all MCPs at once. Each MCP tool description consumes tokens from your 200k window, potentially reducing it to ~70k.” Treat the exact number as a claim; treat the mechanism as real, because it is simply how tool definitions work.

Which is why the install profile is the decision

ECC does not have one installation; it has several, and choosing between them is the main thing a new user gets wrong.

npx ecc-universal@2.2.3 install --profile core --yes
npx ecc-universal@2.2.3 install --profile minimal --target claude \
  --with capability:machine-learning

The profiles run from core and minimal up to full, with --with capability:<domain> to add one area deliberately. The documentation’s advice on rules follows the same logic: “Start with rules/common plus one language or framework pack you actually use.”

Two documented ways to break it, both from stacking installs rather than from bugs:

“If you install the plugin, do not run ./install.sh --profile full afterward.”
“Do not use npx ecc-install --profile minimal --target claude: ecc-install is a binary name inside ecc-universal, not a separately published npm package.”

Both warnings exist because people reach for breadth by default. The project is telling you that breadth is the expensive choice.

What the repository looks like on disk

Our file census explains where the weight is. Of 4,609 tracked files, 2,862 are Markdown — roughly 62% — with 1,540 of those under docs/. Then 974 JavaScript files, 243 JSON and 162 Python. The largest directories after docs/ are skills/ (612 files), tests/ (493) and scripts/ (369), plus checked-in adapter directories for several editors — .cursor/, .opencode/, .kiro/, .agents/ — which is how the multi-harness support is implemented: file placement, not a runtime.

So this is predominantly a prose artefact: instructions, skills and documentation that a model reads, with code around the edges to place and enforce them. That is the correct shape for what it does, and it is also why context budget is the binding constraint rather than CPU or disk. You are not installing a program; you are installing reading material, and the agent reads it with you. The 493 test files are a genuine surprise in the other direction — a real test suite for a configuration repository.

The practical upshot: measure your own baseline. Start a session with core, note how much context the harness consumes before you have typed anything, then add one capability and look again. The project ships /cost guidance and a token-optimization document precisely because this is a thing you tune rather than set.

One maintainer, two revenue lines

The README is unusually transparent about the economics, and this is the paragraph to read before adopting it:

“OSS stays free. This repo is MIT-licensed forever. ECC Pro is the hosted GitHub App for private repos. Sponsors and Pro subscribers fund the work. That’s why a single maintainer ships weekly across 7 harnesses.”

Three facts in one sentence. The repository is MIT and the author commits to keeping it so. There is a commercial tier — the hosted GitHub App, listed at private repos “from $19/seat/mo”. And the project is maintained by one person.

None of that is a criticism; a funded single maintainer is a more sustainable arrangement than an unfunded one, and stating it plainly is better than letting people assume a team. But it is the bus-factor conversation, and for something that installs itself into your development workflow across every project, it belongs in the decision rather than in the footnotes. The mitigation is the licence: MIT means a fork is always available to you.

The support matrix is the most valuable file in the repo

ECC lists adapters for a long tail of tools — Cursor, OpenCode, Gemini, Zed, GitHub Copilot, Antigravity, Qwen, Hermes, Kimi, Qoder and more. The README asks you to “See the support status matrix before assuming feature parity,” and that matrix is where the marketing and the reality are reconciled. A selection, quoted:

Claude Code — “Stable primary.”
Codex — “Supported native plugin.” Note: “Native hooks require an explicit trust decision and do not use Claude’s hook profiles.”
Cursor — “Beta project adapter.” “Agent discovery varies by Cursor build… full Claude feature parity is not claimed.”
OpenCode — “Beta built plugin.” “ECC ships a subset of the catalog.”
GitHub Copilot Chat — “Instruction-only.” “ECC hooks are not adapted.”
Gemini, Zed, Antigravity, Qwen, Hermes, OpenClaw, Kimi, CodeBuddy, JoyCode — “Experimental/minimal adapters.”

So the honest reading of “works across seven-plus harnesses” is: one stable target, two native plugins, a few betas, and a set of experimental file-placement adapters. The project says this itself, clearly, in a table — which is more than most cross-platform claims survive. Check your harness’s row before you form an expectation, because the difference between “stable primary” and “instruction-only” is most of the product.

What the installer actually does

A repository this large that ships install.sh deserves a look before you run it, so we read it.

It is 42 lines, and it is a wrapper. It re-execs itself under bash if invoked via sh, resolves symlinks to find the real package root, handles Windows path conversion under Git Bash via cygpath, and then delegates to a Node script. There is no curl | bash anywhere in it.

The part worth quoting is a comment:

# SECURITY: --ignore-scripts blocks preinstall/postinstall RCE from a
# compromised dependency. ECC deps are pure JS (no native build step).
if [ ! -d "$SCRIPT_DIR/node_modules" ]; then
    (cd "$SCRIPT_DIR" && npm install --ignore-scripts --no-audit --no-fund ...)

Installing dependencies with --ignore-scripts by default, and explaining why, is a standard most projects do not meet. It is a small thing that tells you something about the care taken elsewhere.

The README pairs that with a prominent warning that only the named channels — the GitHub repository, the ecc-universal and ecc-agentshield npm packages, the GitHub App, the ecc@ecc plugin slug and ecc.tools — are official, and that “Third-party re-uploads and unofficial mirrors are not maintained or reviewed by the project and may contain malware.” Given a catalogue of files that an agent reads and acts on, that is the right warning to put at the top.

Where it earns its keep

The parts most likely to pay for their context are the ones that catch mistakes you would otherwise ship: the review agent reading a change from a fresh context, the build-repair agent, and AgentShield’s scanning of prompts, hooks, MCP configuration, permissions, secrets and agent files. A review from an uncontaminated context is a genuinely different signal from asking the same session whether its own work is good.

The parts least likely to pay for themselves are the domain skills for work you do not do. Installed breadth you never invoke is pure overhead, and the selective profile exists to let you decline it.

The honest recommendation

Read your harness’s row in the support matrix. Install core, add capabilities one at a time, and keep the context measurement in front of you.

If what you actually want is one capability rather than a system, the narrower projects are often the better trade — claude-mem does session memory alone, and AGENTS.md is the shorter read on the convention all of these build on.

The findings, together: ECC’s counts hold up to a clone-and-count, and its own matrix tells you that installing the full catalogue advertises it to the model — so breadth is not free, and the repository being 62% Markdown is the clearest possible evidence of where that budget goes. Its documentation is also more honest than its scale suggests: it names the single maintainer, prices the commercial tier, grades every harness candidly, and hardens its own installer. The one thing it does not tell you is that it is published twice under two names.