Auditoría de ECC: 68 agentes, 293 skills y las 43 copias de Kiro congeladas hace cinco versiones

affaan-m/ECC es el proyecto de harness de agentes más grande que ha salido en 2026. Se presenta como «the agent harness performance optimization system» y promete skills, instintos, memoria, seguridad y desarrollo guiado por investigación sobre Claude Code, Codex, OpenCode, Cursor, Gemini, Zed y una docena de herramientas más.

Las cifras no son pequeñas: 272.248 estrellas, 40.652 forks, 371 colaboradores, 3.043 commits y 19 releases desde que el repositorio se creó el 18 de enero de 2026. Eso equivale a 1.051 estrellas diarias de media y 20 commits al día en la última semana, con 93 de los 100 commits más recientes firmados por el mantenedor. Su paquete npm acumula 42.491 descargas en los últimos 30 días y su auditor de seguridad independiente, ecc-agentshield, 46.012 — el escáner se descarga más que el propio kit.

He clonado main, he instalado las dependencias con los scripts desactivados, he descargado y verificado el tarball publicado, he ejecutado su propia batería de pruebas y sus scripts de auditoría, he comparado byte a byte cada árbol de skills duplicado y he recuperado las métricas de adquisición desde sus propios endpoints públicos, el registro npm y capturas de Wayback de la página del repositorio.

Esto es lo que ha sobrevivido al contacto.

Lo que prometen los titulares y lo que dice el árbol de ficheros

Casi todos los repositorios de este tamaño fallan la primera comprobación que se puede hacer sin conocer el proyecto: contar ficheros. ECC la pasa al detalle.

Esa alineación es más rara de lo que parece. Hace dos días audité un proyecto con 109.000 estrellas cuya documentación, su propia evaluación y un benchmark de terceros no se ponían de acuerdo sobre su cifra central de rendimiento.

El repositorio ocupa 4.212 ficheros y 57.707.707 bytes, y su composición es llamativa para una herramienta que distribuye sobre todo instrucciones: 2.790 ficheros Markdown son el 31,0% de los bytes, pero 34 ficheros PNG son el 40,2% — 23,2 MB de imágenes de marketing y documentación versionadas en el mismo árbol que leen los agentes.

Dentro de los documentos que pasan ese recuento hay tres incoherencias pequeñas:

• El mismo README.md dice «68 specialized subagents» en el árbol del proyecto y «67 specialized subagents» en el catálogo anotado, 24 líneas más abajo.
• AGENTS.md describe mcp-configs/ como un directorio con «14 MCP server configurations». El único fichero que contiene declara 34 servidores, y las copias traducidas de AGENTS.md repiten el 14.
• El registro de skills que el proyecto usa para distribuir públicamente, skills.sh, lista 309 skills para affaan-m/ecc: 16 más de las que publica el repositorio.

Lo que realmente se instala: el artefacto npm de 19,5 MB

ecc-universal@2.2.3 descomprime 19.494.887 bytes en 2.805 ficheros. Descargué el tarball y reproduje localmente ambos digests publicados (sha1 11f410d5…, sha512 2xDcL0lCJ9O7…), así que la tabla siguiente describe los bytes que recibe un usuario, no los del repositorio.

Hay dos detalles en esa tabla que valen más que los totales.

El paquete creció 12,6 veces en bytes y 9,1 veces en número de ficheros en 233 días: pasó de 1.549.108 bytes en 308 ficheros el 11 de febrero a los 19,5 MB en 2.805 ficheros de hoy. Una quinta parte de los ficheros del repositorio aterriza ahora en cada node_modules que lo instala.

Alrededor de 1,17 MB de eso es arte publicitario de patrocinadores. El directorio assets/images/sponsors/ suma 1.225.612 bytes en 11 ficheros, y los dos PNG de Itô son de 689.077 y 476.033 bytes: el 5,98% de la instalación completa son dos imágenes de una empresa cuyo servicio el kit no usa por defecto. Si construyes contenedores con npm ci, los descargas y los cacheas en cada build.

La carga de traducciones es la otra mitad de la historia, y no es un defecto simple. El japonés (3,46 MB) y el chino simplificado (2,54 MB) están ahí porque ECC es deliberadamente offline-first: un agente en Tokio o Shanghái puede leer sus propias instrucciones sin una vuelta a la red. Pero el conjunto es muy desigual — el README en ucraniano tiene 160.175 bytes, 1,5 veces la longitud del inglés, mientras que el polaco son 10.835 bytes y el vietnamita 6.866. Y dos de los quince enlaces de idioma del README, español y tailandés, apuntan a ficheros excluidos por la lista files de package.json, así que son rutas relativas muertas para quien lea el README desde node_modules. Un decimosexto README, en urdu, existe en el repositorio y ni siquiera aparece en el selector.

Hay una asimetría más: .kiro/, .trae/ y .codebuddy/ no están en la lista permitida de npm. Los usuarios de GitHub y los de npm no reciben el mismo producto.

La afirmación que se rompe: «los adaptadores mapean los mismos flujos en lugar de mantener copias separadas»

El README hace una promesa arquitectónica concreta:

The root is the source of truth. Platform adapters package or map these same workflows instead of maintaining separate copies.

He calculado el hash de cada SKILL.md copiado y lo he comparado con el canónico. Once árboles contienen copias de skills. Tres están generados y limpios; cuatro no lo están.

El subárbol de Kiro es el caso más claro. .kiro/ es un paquete autocontenido: su propio README.md, su propio install.sh, 33 ficheros JSON de agentes, 33 Markdown de agentes, 43 skills, 22 ficheros de steering y 13 hooks de IDE, añadidos en marzo de 2026 por los PR #548 y #809. Su README se describe a sí mismo como un repositorio: «This repository provides custom agents, skills, hooks, steering files and scripts». Todas sus skills difieren del canónico, y los agentes están peor: .kiro/agents/go-reviewer.md se modificó por última vez el 22 de marzo, mientras que el agents/go-reviewer.md canónico lo hizo el 26 de julio: 126 días de diferencia en el fichero que le explica a un agente cómo revisar código Go.

La defensa legítima existe y la empresa la declara: la matriz de plataformas del README etiqueta Cursor como beta project adapter, OpenCode como beta built plugin, y Gemini, Zed, Antigravity, Qwen, Hermes, OpenClaw, Kimi y CodeBuddy como «experimental/minimal adapters», con la frase «full Claude feature parity is not claimed». Kiro no aparece en esa lista.

Pero de ahí se derivan dos consecuencias, y son lo que debería llevarse un usuario:

1. Una instantánea congelada no es una declaración de capacidades, es una decisión de contenido tomada por un paso de copia. La copia de article-writing en Cursor no es «beta»: son 104 días de ediciones por detrás de un fichero que cambió cuatro veces.
2. El registro de conformidad que debería hacer auditable esa clasificación está él mismo caducado. scripts/harness-adapter-compliance.js incluye ADAPTER_RECORDS para 12 harnesses, cada uno con un campo last_verified_at. Diez de los doce dicen 2026-05-12, uno dice 2026-05-17 y otro 2026-08-10. En los 145 días transcurridos desde la revisión de mayo, el proyecto publicó v2.0.0, v2.1.0, v2.2.0, v2.2.1 y v2.2.2. Kiro, que distribuye 1,4 MB y 153 ficheros, no tiene ficha.

Por qué la CI nunca lo detecta

Existe una única prueba que toca una superficie copiada: tests/ci/codex-skill-surface.test.js. La he leído. Comprueba que cada .agents/skills/*/SKILL.md tenga un frontmatter limitado a cinco claves permitidas, que name coincida con su carpeta, que exista descripción y que el agents/openai.yaml que lo acompaña traiga display_name, un short_description de entre 25 y 64 caracteres y un default_prompt.

Nunca lee skills/. Valida la forma de la copia, no su contenido. Por eso las 38 copias divergentes de Codex pasan la CI en verde.

El mismo patrón se repite un nivel más arriba. El repositorio incluye cinco scripts de auditoría — harness-audit.js, platform-audit.js, operator-readiness-dashboard.js, observability-readiness.js, release-approval-gate.js — además del verificador de conformidad de adaptadores. He buscado en todos los flujos de .github/workflows: ninguno invoca a ninguno de esos seis. Son scripts de npm que una persona tiene que acordarse de lanzar. Los 14 flujos que sí existen son genuinamente buenos (lo cuento más abajo), pero auditan el repositorio, no la afirmación.

Hooks y servidores MCP: un catálogo que dice 34 y un documento que dice 14

hooks/hooks.json ocupa 33.225 bytes y declara 24 entradas de hook repartidas en siete eventos del ciclo de vida: nueve emparejadores PreToolUse, siete Stop, dos en SessionStart, PostToolUse y PostToolUseFailure respectivamente, uno en PreCompact y uno en SessionEnd. Despachan a 24 scripts, entre ellos cost-tracker.js, observe-runner.js, governance-capture.js, skill-run-tracker.js, config-protection.js y stop-format-typecheck.js.

Los 24 comandos tienen la misma construcción: un programa node -e en línea de unos 1.800 caracteres cuya única función es localizar la raíz de ECC y hacer require del despachador real. Es defensivo y portable, y también significa que el JSON que revisas no es el código que se ejecuta: el código está en scripts/hooks/.

El lado MCP es donde la documentación y el artefacto se separan. mcp-configs/mcp-servers.json declara 34 servidores: 22 lanzados como comandos y 12 por HTTP. AGENTS.md dice 14. Los propios comentarios del fichero dicen «Keep under 10 MCPs enabled to preserve context window».

Si estás decidiendo si confiar en el catálogo, hay tres cosas que importan:

• La mayoría no se activa sola. ECC distribuye exactamente un conector por defecto, chrome-devtools; docs/MCP-CONNECTOR-POLICY.md documenta una auditoría de junio de 2026 que retiró seis valores por defecto anteriores (github, context7, exa y otros) en favor de skills apoyadas en CLI, con este principio declarado: «tool schemas load into every session; each default connector taxes every user’s context window whether they use it or not». Es una postura más firme que la de la mayoría de proyectos de harness.
• El pinning es inconsistente. jira está fijado (uvx mcp-atlassian==0.21.0). Supabase, Context7 y Magic no: usan @latest y se vuelven a descargar del registro cada vez que arranca el servidor. Una docena más son nombres de paquete npx/uvx sin fijar. Si activas uno, estás ejecutando lo que se publicara más recientemente.
• Algunas entradas son marcadores de posición o dependen del host. Una entrada de Memxus lleva Bearer YOUR_MEMXUS_API_KEY_HERE; nexus, ito-compute, devfleet (localhost:18801) y evalview apuntan a rutas locales de la máquina.

Lo que está excepcionalmente bien

Una auditoría que solo enumera defectos no es una auditoría. Este repositorio hace varias cosas que la mayoría de proyectos de herramientas para agentes no hacen, y merecen copiarse:

• Ningún script de ciclo de vida en el paquete publicado. Ni preinstall, ni install, ni postinstall, ni prepare. install.sh es un envoltorio POSIX de 42 líneas que se reejecuta bajo bash, resuelve enlaces simbólicos, lanza npm install --ignore-scripts --no-audit --no-fund cuando falta node_modules y delega en el instalador en Node. No hay ningún paso curl | bash.
• Cuatro dependencias de ejecución: ajv, sql.js, js-yaml y @iarna/toml. Ese es todo el árbol de dependencias de un paquete de 2.805 ficheros.
• Todas las GitHub Actions fijadas a un SHA completo con un comentario de versión, más un flujo SLSA genérico, una vigilancia programada de indicadores de cadena de suministro, un flujo mensual de métricas y flujos de release que empaquetan el tarball, exigen exactamente un .tgz y publican su sha256.
• Cero telemetría. He buscado en scripts/ y hooks/ referencias a analytics, PostHog, Segment, Mixpanel y Sentry. Nada. Los únicos hosts de salida son GitHub, npm, Discord, X, el sitio del proyecto, el patrocinador de cómputo y una CDN de jsDelivr.
• Alineación de versión en seis manifiestos, algo que varias herramientas populares de agentes incumplen.
• Una batería de pruebas grande y real. npm test encadena diez validadores (seguridad unicode, agentes, comandos, reglas, skills, hooks, claves de esquema de hooks, manifiestos de instalación, perfiles de contexto, rutas personales), las comprobaciones de catálogo y registro de comandos, y un ejecutor cuyo recuadro final marca 6.194 pruebas.

Con una advertencia sobre ese último punto, porque lo ejecuté en lugar de fiarme: en este contenedor Linux (git 2.47.3, ext4) la batería termina con 4 fallos de 6.194, en dos ficheros. Uno es la prueba de plegado de mayúsculas en tests/scripts/codex-hooks.test.js, cuya guarda de omisión — fs.existsSync(__filename.toUpperCase()) || fs.existsSync(__filename.toLowerCase()) — es una tautología en sistemas de ficheros sensibles a mayúsculas, porque la segunda condición comprueba un nombre en minúsculas que ya es el nombre real del fichero. Los otros tres son jq: command not found dentro de skills/skill-stocktake/scripts/scan.sh y quick-diff.sh: una skill distribuida depende de jq, y jq no aparece en ningún sitio de los requisitos del README. La CI del proyecto en el mismo commit está en verde (su matriz cubre ubuntu, macos y windows sobre Node 18/20/22 y cuatro gestores de paquetes), así que ambas divergencias son de entorno; pero una prueba que su autor quería exclusiva de macOS se ejecuta en todas partes, y un binario externo ausente tumba la suite en lugar de omitir un caso.

Crecimiento y las métricas que publica la empresa

ECC mantiene su propia página de medición, y lo interesante es que cuadra, con un número que exige lectura atenta.

He reconstruido la curva de estrellas desde capturas de Wayback de la página del repositorio en lugar de fiarme de una insignia:

La curva decae de 1.101 a 335 estrellas diarias durante el verano y luego se reacelera hasta 826 al día en el último mes, el ritmo más alto desde la primavera, en un proyecto de nueve meses. La proporción de forks sobre estrellas se mantiene estable entre el 14,9% y el 15,5%, unas tres veces el 5,4% de otro repositorio en tendencia que usé como comparación (ponytail, 153.411 estrellas, 8.227 forks).

Frente a eso, la tabla de adquisición de la empresa es refrescantemente honesta sobre lo que no puede demostrar. Afirma que «these channels overlap, so their counts are not added together», que los recuentos de npm «include repeat downloads and automation», que un contador de plugin ausente significa desconocido y no cero, y publica una cifra de tráfico de GitHub (673.617 eventos de clonado, 90.216 clonadores únicos entre el 29 de agosto y el 11 de septiembre) que ningún observador externo puede verificar. Dos de sus números públicos los he comprobado byte a byte:

• La insignia de instalaciones de la GitHub App es un endpoint en vivo (api.ecc.tools/badge/installs, cacheSeconds: 300) que devuelve 7.058 instalaciones. Eso es el 2,59% del número de estrellas: el tamaño de la brecha entre un proyecto al que se le dan estrellas y uno que se despliega.
• Las descargas npm de 30 días (42.491 y 46.012) se reproducen exactamente desde la API del registro.

El número que merece una frase propia es el de 982.400 instalaciones de skills en skills.sh. He analizado el listado del registro para este repositorio: 309 skills, 982,4K instalaciones totales. La skill más instalada, 4.700; la mediana, 3.400; una skill con cero. La distribución es plana — la más instalada solo multiplica por 1,4 a la mediana —, y esa no es la forma que produce 982.400 desarrolladores eligiendo skills a mano. Es la forma que produce que unos 3.200 usuarios o trabajos de CI instalen las 309 de golpe. La propia nota metodológica de la empresa dice exactamente eso: «Individual skill installs, not full-toolkit installs or unique developers». Leído al pie de la letra es correcto; leído como marketing está desviado en dos órdenes de magnitud, y la misma página luce «The #1 agentic engineering toolkit» y los logotipos de seis grandes empleadores.

La última cifra es una pequeña lección sobre no pasarse de listo como auditor. El sitio lista 2.617 descargas de paquetes de release. Mi primera medición dio 82.356 descargas totales de artefactos de release y estuve a punto de escribir que la empresa se quedaba corta por un factor de 30. No es así: 79.024 de esas 82.358 descargas (el 95,9%) son capturas PNG adjuntas a dos releases, y los artefactos .tgz suman exactamente 2.617. La metodología de la empresa excluye los ficheros que no son paquetes y su número es preciso. El hallazgo real es el inverso y más afilado: el 96% del tráfico de descargas de esta página de releases es gente bajando imágenes promocionales, y las tres últimas versiones no publican ningún artefacto, porque el canal de distribución es npm.

Qué hacer si lo instalas

ECC no es un paquete que se añade a un proyecto: es una capa que se le da a un agente. Eso cambia el modelo de riesgo, y estas son las decisiones que importan:

• Empieza por Claude Code. Es la única superficie que el proyecto llama «stable primary»; Codex es un plugin nativo soportado; Cursor y OpenCode están etiquetados como beta y sus copias internas son precisamente las que han derivado.
• Usa el perfil selectivo o de bajo contexto, no la instalación completa, si el presupuesto de contexto aprieta. El propio README avisa de que el plugin anuncia el catálogo entero al modelo.
• Activa pocos servidores MCP y fija los que actives. El comentario del propio catálogo dice menos de diez. Sustituye @latest por una versión elegida por ti, y ten presente que activar un servidor implica ejecutar su paquete al arrancar.
• Ignora las traducciones que no puedas leer: si no construyes en un host sin red, npm i te está bajando 8,2 MB de documentación que nunca abrirás, incluido un par de imágenes de patrocinador de 1,17 MB.
• Si usas un harness que no sea Claude, compáralo con el canónico. Para Cursor y Kiro es un comando: diff skills/article-writing/SKILL.md .cursor/skills/article-writing/SKILL.md tarda un segundo y muestra una variante de hace 104 días.
• Verifica el artefacto si lo despliegas en flota. Los digests están publicados y son reproducibles, y el flujo de release firma un sha256 del archivo empaquetado.

Preguntas frecuentes

¿Son reales las estrellas de ECC? El contador es real y se mueve: medí 271.486 estrellas el 3 de octubre y 272.248 vía API el 4 de octubre, coherente con 826 estrellas al día. Lo que las estrellas no miden es la adopción: las 7.058 instalaciones de la GitHub App (2,59% de las estrellas) y las 42.491 descargas npm mensuales son los indicadores más cercanos.

¿Por qué las skills de Kiro difieren de las principales si el repositorio dice que hay una sola fuente de verdad? Porque .kiro/ llegó como un paquete autocontenido con su propio instalador en marzo de 2026 y se refresca a mano. La afirmación arquitectónica se cumple en la superficie generada de Pi (123 skills, cero deriva) y falla en las instantáneas versionadas (.agents, .cursor, .kiro).

¿Me afecta la discrepancia de 34 frente a 14 servidores MCP al instalar? No. Ninguno de los dos números se activa por ti: el único conector por defecto es chrome-devtools y el resto es un catálogo del que copias. El error documental importa porque 10 es el techo que fija la propia guía del proyecto, y el catálogo lo quintuplica.

¿Es seguro ejecutar los hooks? Son scripts locales de Node, no llaman a casa y el paquete no incluye scripts de ciclo de vida. El coste es de contexto: 24 entradas de hook en siete eventos, y cada inicio de sesión inyecta los «instintos» aprendidos salvo que los limites. Los mandos están documentados: ECC_HOOK_PROFILE=standard, ECC_DISABLED_HOOKS, ECC_SESSION_START_MAX_CHARS (por defecto 8000), ECC_MAX_INJECTED_INSTINCTS (por defecto 6), ECC_INSTINCT_CONFIDENCE_THRESHOLD (por defecto 0,7) y ECC_SESSION_RETENTION_DAYS (por defecto 30).

¿Por qué pesa 19,5 MB el paquete npm? El 42,1% es documentación traducida, el 23,7% es la biblioteca de skills, el 14,2% son scripts de instalación y ejecución y el 6,0% es arte de patrocinadores. No hay una compilación optimizada en tamaño; el crecimiento de 1,5 MB a 19,5 MB sigue la expansión documental, no el código.

¿Funciona en Windows y macOS? La matriz de CI cubre ubuntu, macos y windows sobre Node 18, 20 y 22 y cuatro gestores de paquetes, y la ruta de instalación gestiona explícitamente la conversión de rutas de MSYS2/Git Bash. Irónicamente, la única prueba que falla fuera de su matriz es un caso de plegado de mayúsculas específico de macOS.

Conclusión

ECC es el intento a gran escala más convincente de construir una «capa operativa para agentes» que he auditado este año. Demuestra sus cifras, mantiene seis manifiestos en la misma versión, distribuye cuatro dependencias de ejecución, firma sus artefactos de release, fija cada action a un commit SHA, evita la telemetría por completo y — lo más raro — publica una página de métricas que admite que sus canales se solapan y que algunos de sus números no son verificables de forma independiente.

La debilidad es la misma que aparece en todo proyecto que multiplica plataformas: la promesa de una fuente única de verdad se mantiene con pasos de copia, y los pasos de copia se pudren en silencio. Cuarenta y tres skills de Kiro, once de Cursor y treinta y ocho de Codex ejecutan versiones de instrucciones que el árbol canónico sustituyó hace meses, mientras la propia matriz de conformidad del repositorio sigue informando del 12 de mayo como última verificación a lo largo de cinco versiones posteriores. Nada en la CI puede detectarlo, porque la única prueba que mira una copia valida sus claves YAML y no su contenido.

Si instalas ECC, hazlo con deliberación: un solo harness, un perfil selectivo, servidores MCP fijados y el ojo puesto en qué copia de las instrucciones está leyendo realmente tu agente.