Auditoría del repo Everything Claude Code: 286 skills y un índice de 21K tokens

Ya de noche aparece un vídeo corto: un ganador de hackathon habría regalado su configuración completa de Claude Code. Después llega un hilo con lo mismo, luego otro y luego varios más. Todos se parecen: unas cuantas cifras grandes, una captura del contador de estrellas y un enlace. Uno habla de 163K estrellas, otro de 214K, otro de 228K.

Las cifras ni siquiera coinciden entre sí, y esa es la primera pista de que nadie que las publicaba abrió el repo.

Así que esto es lo que pasa cuando alguien sí lo abre. No el README, sino el repo en sí. Clonarlo, pasarle wc y un script corto de Python y leer las partes que le importan a un ingeniero iOS da una idea clara de lo que hay dentro, de lo que merece la pena conservar y de una medición que cambia cómo debería instalarse.

Qué es ECC

ECC son las siglas de Everything Claude Code, un proyecto de Affaan Mustafa con licencia MIT. En el momento de la revisión, el repo tenía unas 247.000 estrellas, 37.200 forks, 2.631 commits y estaba en la versión 2.2.1.

La propuesta: Claude Code de serie es un único asistente, y ECC lo convierte en un flujo de trabajo de planificar, probar, implementar, revisar, verificar, recordar y mejorar. Alrededor hay un almacén de memoria, «instintos» (patrones que se conservan entre sesiones) y un escáner de seguridad llamado AgentShield.

La instalación es un solo comando:

npx ecc-universal setup

Necesita Node 18+, Git y Claude Code 2.1+. Hay adaptadores para Codex, Cursor, OpenCode, Gemini, Zed y una docena más.

Eso es el marketing. Ahora, el contenido.

Contando lo que hay de verdad

Si te saltas las cifras de los hilos y cuentas directamente, sale esto:

ls -1 skills | wc -l     # 286
ls -1 agents | wc -l     # 68
du -sh --exclude=.git .  # 94M

• 286 skills, un SKILL.md por carpeta
• 68 agentes, archivos markdown cuyo frontmatter indica el modelo y las herramientas que pueden usar
• 94 shims de comandos heredados, dentro de 426 archivos de comandos en total
• 23 entradas de hooks repartidas en siete eventos del ciclo de vida. Ocho están en PreToolUse y siete en Stop. PostToolUse, PostToolUseFailure y SessionStart tienen dos cada uno, y PreCompact y SessionEnd, uno cada uno
• 94 MB en disco, de los que 23 MB son assets y 18 MB documentación

Hay un detalle inesperado. El CLAUDE.md en la raíz de este monumento de 94 MB a la configuración tiene 82 líneas, 531 palabras. Quien publicó 286 skills mantuvo su propio archivo de instrucciones más corto que muchos repos privados. No es casualidad, y vuelve a importar al final.

La cifra que los hilos se saltan

Antes de que una skill pueda ejecutarse, Claude Code tiene que saber que existe. Al arrancar carga el nombre y la descripción corta de cada skill como catálogo, y el cuerpo completo de una skill solo se carga cuando se activa. Esa carga perezosa se llama progressive disclosure, y el diseño es bueno.

Aun así, los anuncios cuestan algo, así que conviene medirlos:

# name + description from every SKILL.md frontmatter
skills: 286  name+desc chars: 86,311  ~tokens: 21,577

Son unos 21.500 tokens de índice de skills, gastados antes de escribir una sola palabra del problema real.

Para comparar, esto es lo que hay detrás del índice:

• los 286 cuerpos de skills: unos 641.000 tokens
• las 68 definiciones de agentes: unos 110.000 tokens

Nadie va a cargar nunca 641K tokens, que es justo para lo que sirve el progressive disclosure, y funciona. Pero el índice de ~21,5K es el precio de entrada de una instalación completa, y se paga en cada sesión. En una ventana de 200K, más del 10 % se va en un menú.

Nada de esto es una crítica a ECC. Es un argumento a favor del perfil minimal que ofrece el propio repo:

./install.sh --profile minimal --target claude

El README incluso lo dice claramente: empieza con rules/common y un paquete de lenguaje que de verdad uses. Quienes más ruido hicieron con este repo se saltaron esa línea.

Seis piezas que conservaría un ingeniero iOS

Buscar cualquier cosa con pinta de Swift devuelve primero cisco-ios-patterns. Es una skill de redes y un buen recordatorio de que «ios» es un mal término de búsqueda. Después aparecen seis entradas de verdad.

Tipo	Nombre
Agente	swift-reviewer.md
Agente	swift-build-resolver.md
Skill	swiftui-patterns
Skill	swift-concurrency-6-2
Skill	swift-actor-persistence
Skill	swift-protocol-di-testing

Para quien vive en una base de código MVVM mixta de UIKit y SwiftUI, merece la pena leer este último grupo aunque nunca llegue a ejecutar el instalador.

Dentro de swift-reviewer

Uno espera un prompt genérico del tipo «eres un revisor de Swift servicial». No tiene nada que ver. El frontmatter fija el agente a sonnet y limita sus herramientas a Read, Grep, Glob, Bash. Nada de eso puede modificar archivos, lo que le va perfecto a un revisor.

Luego viene el procedimiento:

1. Primero compilar y probar con swift build, swiftlint lint --quiet (si está instalado) y swift test. Si cualquiera falla, el agente se detiene e informa en lugar de seguir.
2. Reunir los cambios con git diff HEAD~1 -- '*.swift', o con git diff main...HEAD al revisar un PR.
3. Mirar solo los archivos .swift modificados y nada más.
4. Empezar la revisión propiamente dicha.

La regla «si algo falla, detente e informa» es lo que vale la pena copiar. La mayoría de los prompts de revisión critican alegremente código que ni compila. Este se niega a quemar tokens en un árbol roto.

El nivel CRITICAL se lee como una lista de cosas que desarrolladores con experiencia ya han llevado a producción y lamentado:

• force unwrapping en rutas de producción
• try! sin justificación y as! sin comprobar antes el tipo
• secretos escritos en el código, incluidos los guardados en UserDefaults en vez de en el Keychain
• excepciones de ATS sin justificación
• bloques catch {} vacíos y try? que se traga errores relevantes
• fatalError() para situaciones de las que quien llama podría recuperarse
• assert protegiendo un invariante que tiene que cumplirse en las builds de release. Las builds de release lo eliminan, así que la herramienta correcta es precondition

Esa última nota sobre assert frente a precondition es una observación de verdadero senior. Se pasa por alto en pull requests reales, y en una empresa de valores «se elimina en release» no es una preocupación académica.

La skill swiftui-patterns sigue el mismo patrón. Tiene una tabla para elegir property wrappers (@State, @Binding, @Observable, @Bindable, @Environment) y un argumento claro a favor de @Observable frente a ObservableObject: como los cambios se siguen propiedad por propiedad, SwiftUI redibuja solo las vistas que realmente leen lo que cambió. Ese mismo conocimiento está en sesiones de la WWDC. Tenerlo en un archivo que se le puede pasar a un agente es otra cosa.

Dónde deja de ser útil

El mismo ls que encontró las skills de Swift encontró también entradas como estas:

customs-trade-compliance
energy-procurement
production-scheduling
quality-nonconformance
healthcare-cdss-patterns
healthcare-emr-patterns
healthcare-phi-compliance

Salvo que estés montando un pipeline de compra de energía, nada de eso aplica. Esas skills son trabajo real de alguien y el autor hace bien en publicarlas, pero cada una es una línea del índice que se paga y nunca se usa.

Hay otros tres problemas que merecen una mención honesta.

El plugin no incluye las reglas. Instalar ECC como plugin de Claude Code trae agentes, skills, hooks y comandos automáticamente, pero las reglas hay que copiarlas a mano en .claude/rules/. La promesa de un solo comando esconde una tarea pendiente.

Los instaladores no se combinan. El README repite una y otra vez: un método por harness. Los reportes de hooks duplicados suelen venir de quienes combinaron el plugin con ./install.sh --profile full.

Veintitrés hooks amplían la superficie de ataque. Ocho se disparan en PreToolUse, así que cada uno es código que se ejecuta en local antes de que Claude edite cualquier archivo. ECC no lo esconde: el instalador pide consentimiento explícito antes de activar los hooks, y AgentShield viene incluido para escanear prompts, hooks y configuraciones MCP. Es la actitud correcta. Aun así, quedan 23 cosas por leer antes de aceptar.

Veredicto

El número de estrellas no es la historia. Nadie le da estrella a un repo de 247.000 estrellas después de evaluar 286 skills. Se la dan porque un vídeo corto lo dijo.

Lo que importa de verdad es que el repo es un material de estudio excelente sobre cómo organizar el trabajo de agentes y un paquete regular para instalar entero. Un plan sensato es este.

Clónalo, pero no lo instales todavía.

git clone --depth 1 https://github.com/affaan-m/ECC.git

Después merece la pena abrir cuatro archivos: el agente revisor en agents/swift-reviewer.md, la skill en skills/swiftui-patterns/SKILL.md, la configuración de hooks en hooks/hooks.json y ese CLAUDE.md corto de 82 líneas. Veinte minutos de lectura ahí enseñan más que cualquier hilo sobre el repo sobre cómo deberían escribirse las definiciones de agentes.

Ve a minimal, no a full. Quédate con los dos agentes de Swift, las cuatro skills de Swift y rules/common. El índice se reduce a un puñado de entradas que caben en la cabeza, y el coste de contexto es casi nulo.

Añade una pieza cada vez, y solo cuando un problema real lo pida.

La pista estaba en el repo desde el principio. El autor que publicó 286 skills mantuvo su propio archivo de instrucciones en 82 líneas, y él tampoco lo carga todo. Nadie lo necesita todo. Lo que hace falta es el puñado que encaja con el código que de verdad se está escribiendo.