ECC es un sistema de ingeniería open source para agentes de código: instala un flujo fijo de planificar → testear → implementar → revisar → verificar en Claude Code, Codex, Cursor y una decena más de harnesses. En lugar de reconstruir ese proceso en cada prompt, lo instalas una vez y pasa a ser parte de cómo trabaja tu agente.
Nota del 18 de septiembre de 2026. Este artículo reemplaza nuestra versión de mayo de 2026. Tres cosas en ella estaban mal o habían caducado: el repositorio cambió de nombre de
everything-claude-codeaECC, la versión y los conteos de componentes avanzaron dos releases, y atribuimos el origen de ECC a un hackathon. Ese último punto fue un error nuestro, corregido más abajo.
Cubrí este proyecto dos veces este año y las dos veces subestimé en qué se estaba convirtiendo. En mayo parecía un plugin bien construido con un scanner de seguridad interesante adosado. Hoy tiene 262K estrellas, 39.2K forks y —más importante para cualquiera que esté tomando una decisión de adopción— dejó de ser un plugin de Claude Code.
El cambio de nombre es la señal.
¿Qué es ECC y por qué cambió de nombre?
El proyecto se llamaba Everything Claude Code. Hoy es simplemente ECC y el repositorio vive en affaan-m/ECC. Eso no es cosmético. Una herramienta que lleva el nombre del producto de un solo proveedor no puede posicionarse con credibilidad como la capa de portabilidad entre siete de ellos.
Ahora hay tres identificadores públicos, y el README es explícito en que no son intercambiables:
| Qué | Identificador |
|---|---|
| Repositorio en GitHub | affaan-m/ECC |
| Plugin de Claude Code | ecc@ecc |
| Paquete npm | ecc-universal |
El identificador del plugin es corto a propósito: los nombres largos de marketplace superan los validadores de longitud de algunos clientes Desktop y de API. El README llama al antiguo identificador largo “solo un alias heredado”, lo que significa que cualquier instrucción de instalación que hayas guardado a principios de este año —incluida la nuestra de mayo— apunta al nombre equivocado.
El release actual es el 2.2.1, publicado en npm el 8 de septiembre de 2026. Licencia MIT, y el README se compromete a mantenerla de forma permanente.
¿Qué incluye ECC cuando lo instalas?
| Componente | Cantidad | Qué hace |
|---|---|---|
| Agentes | 68 | Planificación, revisión, reparación de builds, seguridad, arquitectura, revisión por lenguaje |
| Skills | 292 | TDD, investigación, seguridad, docs, frontend, datos, ML, operaciones |
| Comandos | 94 | Shims de slash commands, mantenidos como compatibilidad en la migración hacia skills |
| Hooks y memoria | Runtime | Enforcement, resúmenes de sesión, aprendizaje continuo, control de contexto |
| Reglas | Selectivas | Estándares always-loaded que eliges por lenguaje |
| AgentShield | Incluido | Escanea prompts, hooks, config de MCP, permisos, secrets y archivos de agentes |
Nuestro artículo de mayo decía 28 agentes. La dirección del movimiento es obvia, y también es lo primero que yo cuestionaría: 292 skills es mucha superficie para auditar. El propio README lo concede. El plugin de Claude Code “le anuncia al modelo el catálogo instalado”, así que la documentación recomienda un perfil selectivo cuando el footprint de contexto importa. Es algo inusualmente honesto para que un proyecto lo escriba sobre su propia vía de instalación principal.
¿Para qué sirven los 68 subagentes de Claude Code?
La decisión arquitectónica que me parece más defendible es que las skills, no los comandos, son ahora la superficie principal. Los comandos quedan como shims; los retirados se movieron a un directorio legacy-command-shims/ al que tienes que optar de forma explícita. Es deprecación con ruta de migración, no un rename que rompe todo.
Los 68 agentes están especializados por función y por lenguaje: planificación, arquitectura, guía de TDD, revisión de código, revisión de seguridad, resolución de errores de build, y revisores dedicados para TypeScript, Python, Go, Rust, Java, Kotlin, C++, F# y ArkTS, entre otros.
El valor real de un subagente no es que sepa más. Es que corre con su propio contexto y sus propios permisos de herramientas. El revisor de código no ve el razonamiento con el que se escribió ese código, y por eso encuentra cosas que el contexto original no puede ver. Aislar planificación, implementación y revisión en contextos separados es el mecanismo, y el conteo de agentes es solo la consecuencia.
¿Qué harnesses soporta de verdad?
Aquí el proyecto se gana la credibilidad, porque publica una matriz de capacidades que admite dónde no funciona:
| Harness | Estado |
|---|---|
| Claude Code | Estable, primario |
| Codex | Plugin nativo soportado |
| Cursor | Adaptador de proyecto en beta |
| OpenCode | Plugin compilado en beta |
| GitHub Copilot | Solo instrucciones: sin hooks, sin agentes, sin delegación |
| Gemini, Zed, Antigravity, Qwen, Hermes, OpenClaw, Kimi, CodeBuddy, JoyCode | Adaptadores experimentales o mínimos |
El encuadre del propio README: hay que tratar esas etiquetas “como declaraciones de capacidad, no como niveles de marketing”. El soporte para Copilot significa un archivo de instrucciones versionado y cinco archivos de prompt, y la documentación lo dice sin rodeos: Copilot no tiene sistema de hooks ni API de subagentes, así que la capa de automatización simplemente no está.
Compara eso con cómo se comercializa la mayoría del tooling multiplataforma y entiendes por qué más de 113 contributors siguen apareciendo.
¿Por qué la memoria entre harnesses importa más que el número de agentes?
Porque es el problema real que tienen los equipos en 2026, y casi nadie lo está resolviendo.
Si tu equipo usa Claude Code y Codex y Cursor —como hace hoy la mayoría—, el contexto acumulado de tu agente queda atrapado por herramienta. Cada cambio empieza de cero. La respuesta de ECC es el Memory Vault: documentos markdown portables bajo .ecc/memory/ para scope de proyecto y equipo, y ~/.ecc/memory/ para scope de usuario, legibles por Claude, Codex, Hermes, OpenClaw y Kimi a través de un solo formato.
Dos advertencias que importan, ambas de la documentación del proyecto. El runtime no queda en el PATH con las instalaciones de plugin, mínima o manual: el paquete npm se instala aparte. Y el límite de confianza está declarado sin ambigüedad: la memoria es “contexto no revisado, no política ejecutable”. Las entradas recuperadas nunca deben tratarse como instrucciones.
Para cualquiera que haya pensado en prompt injection a través de un almacén de contexto compartido, ese es el default correcto. Y es lo contrario de lo que diría un proveedor que intenta venderte una función de memoria.
¿Cuánto contexto consume y qué deberías desactivar?
La guía del propio ECC es lo más útil del repositorio para un líder técnico, y contradice el instinto maximalista que invita el número de estrellas.
Configuración recomendada para ~/.claude/settings.json, según la guía de optimización de tokens del proyecto:
{
"model": "sonnet",
"env": {
"MAX_THINKING_TOKENS": "10000",
"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50",
"CLAUDE_CODE_SUBAGENT_MODEL": "haiku"
}
}
Y la restricción que yo pondría delante de cada ingeniero de un equipo que adopte esto: no habilites todos los servidores MCP a la vez. Las descripciones de herramientas de cada servidor consumen tu ventana de contexto antes de que escribas nada. Los techos que declara el proyecto son menos de 10 servidores MCP por proyecto y menos de 80 herramientas activas.
ECC lo practica consigo mismo. Envía exactamente un conector MCP por defecto, chrome-devtools. Una auditoría de junio de 2026 retiró los seis anteriores. Un proyecto que elimina sus propios defaults para proteger tu presupuesto de contexto está haciendo un argumento de diseño, no de marketing.
¿Qué riesgos hay antes de adoptarlo en equipo?
Cuatro, planteados con honestidad.
Un solo mantenedor. ECC publica cada semana para siete harnesses sobre el trabajo de una persona, financiado por sponsors y una GitHub App de pago (ECC Pro, repos privados desde 19 dólares por asiento al mes; el repo OSS sigue siendo MIT). Es un throughput notable y una dependencia concentrada.
Apilar instalaciones rompe cosas. Instalar el plugin y después correr el instalador manual duplica skills, comandos y hooks, y hace que los hooks se ejecuten dos veces. El repositorio tiene un historial documentado de exactamente este problema. Elige una sola vía por harness.
Windows no está a la par. El CLI principal corre en Windows, macOS y Linux, pero el daemon observador de continuous-learning v2 y las escrituras del memory vault tienen defectos abiertos en Windows nativo, y varias funciones apoyadas en shell necesitan Git Bash o WSL.
Parte del roadmap no está entregado. El cliente de cómputo de Itô está explícitamente sin publicar —lo compilas localmente— y la inferencia gestionada a través de él no está activa. Al momento de publicar esta nota, hay que leer las declaraciones de capacidad, no la lista de features.
También vale etiquetarlo: los 1.282 tests, el 98% de coverage y las 102 reglas de análisis estático de AgentShield son cifras reportadas por el propio proyecto, no auditadas de forma independiente. Son plausibles y llamativamente específicas. Siguen siendo autoinformadas.
Nuestra corrección sobre el origen
Nuestro artículo de mayo se titulaba “De Hackathon a 197K Estrellas”. Ese encuadre estaba equivocado, y vale corregirlo con precisión en lugar de en silencio.
AgentShield —el componente de scanner de seguridad— se construyó en el Claude Code Hackathon de Cerebral Valley × Anthropic, en febrero de 2026. Por separado, el mantenedor ganó un hackathon de Anthropic × Forum Ventures en septiembre de 2025 y construyó zenith.chat con flujos agénticos. Eso es su trayectoria, no la historia de origen de ECC. El README no atribuye ECC a un hackathon, y nosotros tampoco deberíamos haberlo hecho.
Si llegaste buscando la parte de seguridad, la cubrimos en detalle aquí: Everything Claude Code (ECC): El Scanner que Audita tu Setup de IA Antes de que lo Haga un Atacante. Ten en cuenta que los comandos de instalación de ese artículo son anteriores al cambio de nombre.
Mi lectura: esto ya es infraestructura, no herramienta
En mayo argumenté que ECC se estaba convirtiendo en el .editorconfig del comportamiento de agentes: un archivo en el que nadie piensa y que todo proyecto asume presente. Sigo creyendo que la forma de ese argumento era correcta, y quiero ser específico sobre qué parte entendí mal.
Lo planteé como un estándar para el comportamiento de los agentes. Lo que muestran los últimos cuatro meses es que la capa durable no es el comportamiento, es la portabilidad. Las reglas y el enforcement de TDD son valiosos, pero también son la parte que cualquier equipo podría escribir por su cuenta en una semana. Lo que un equipo no puede construir con facilidad es una definición única de su proceso de ingeniería que sobreviva a una mudanza de Claude Code a Codex, más un almacén de contexto que viaje con ella.
Esa es la apuesta que hace el cambio de nombre, y por eso hoy evaluaría ECC distinto de como lo hice en mayo. La pregunta no es “deberíamos adoptar ECC”. Es más acotada y más útil: ¿cuánto de nuestra configuración de agentes queremos que sea portable entre proveedores, y qué estamos dispuestos a pagar en presupuesto de contexto por eso?
La respuesta probablemente no sea el catálogo completo de 292 skills. La instalación selectiva existe precisamente porque el mantenedor lo sabe.
¿Tu equipo ya llegó al punto en que el contexto del agente atrapado en una sola herramienta se volvió un costo real? Ese es el problema al que apunta ECC ahora, y tengo curiosidad por saber si aterriza.