⚡ En 30 segundos
ECC (Everything Claude Code) es un "operating system" de configuración para agentes de IA-coding. En vez de tener tus prompts, skills y reglas atados a un solo asistente, ECC los empaqueta como una capa reutilizable única (skills + agentes + hooks + rules + configs MCP) que se adapta a cada harness en el borde: el mismo SKILL.md corre en Claude Code, Codex, Cursor, OpenCode, Gemini, Zed y GitHub Copilot.
Por qué importa: es el patrón maduro de "dotfiles para agentes". Resuelve el problema de fragmentación (cada herramienta con su propio formato) con una idea clara: el workflow durable vive una vez en skills/; cada harness solo adapta cómo se carga. Más de 10 meses de uso diario destilados en agentes especializados, instintos auto-aprendidos, optimización de memoria y escaneo de seguridad (AgentShield).
Para quién: cualquiera que use 2+ asistentes de IA y esté harto de reescribir la misma config. Y para quien quiere ver, sin leer código, cómo se diseña un harness de agentes profesional de referencia.
🧠 El problema que resuelve
Cada asistente de IA-coding tiene su propio formato de configuración: Claude Code usa plugins y hooks nativos, Codex lee AGENTS.md y TOML, Cursor tiene su propio layout de .cursor/rules/ y .cursor/hooks/, OpenCode tiene un sistema de eventos... Si trabajas con varios, acabas reescribiendo el mismo workflow tres o cuatro veces y manteniéndolos sincronizados a mano.
ECC parte de una tesis explícita (de docs/architecture/cross-harness.md): "ECC es la capa reutilizable de workflow. Los harnesses son superficies de ejecución." Lo durable —skills, reglas, hooks, configs MCP, manifiestos de instalación— vive en un solo sitio. El harness solo adapta cómo se carga, no qué hace. La regla de oro del repo: "si un cambio requiere editar tres copias del mismo workflow, la fuente compartida está en el sitio equivocado".
Además resuelve problemas operativos reales del trabajo agéntico: optimización de tokens, persistencia de memoria entre sesiones (vía hooks), aprendizaje continuo (auto-extraer patrones de sesiones a skills reutilizables), loops de verificación y seguridad (sandboxing, sanitización, el escáner AgentShield).
🏗 Arquitectura
El corazón es un modelo de "fuente compartida + adaptadores finos". Una capa central de assets se proyecta sobre cada harness mediante carpetas-puente (.claude/, .codex/, .cursor/, .agents/, etc.):
Cómo leer el diagrama: arriba, la fuente única. En el medio, cada harness recibe los mismos assets a través de un adaptador fino — la diferencia clave es la paridad de hooks: nativa en Claude Code/OpenCode/Cursor, basada en instrucción en Codex (no hay motor de hooks, así que las reglas se inyectan como texto). Abajo, la capa 2.0 que convierte ECC de "pack de configs" a sistema operativo: un control-plane en Rust (ecc2/, todavía alpha), almacén de estado SQLite, orquestadores y el escáner de seguridad. El árbol de ficheros confirma esta estructura: verás .claude/, .codex/, .cursor/hooks/ (con ~17 hooks JS por evento) y .agents/skills/ conviviendo en la raíz.
🔑 Conceptos / técnicas clave
name, description, origin (ECC vs community), sección "When to Use" y ejemplos repo-relativos. Sin secretos ni rutas absolutas. El mismo archivo se instala en todos los harnesses.planner; código recién escrito → code-reviewer; bug → tdd-guide; código sensible → security-reviewer; build roto → *-build-resolver. 64 agentes en total, muchos por lenguaje (go/rust/kotlin/java/python/cpp reviewer + build-resolver)./learn y /learn-eval extraen patrones de la sesión actual; /evolve los convierte en estructuras de skill; /instinct-status muestra los instintos aprendidos con confidence scores; /promote sube instintos de proyecto a global. Es un loop de auto-mejora del propio harness.SessionStart/Stop/pre-compact que guardan y recargan contexto entre sesiones automáticamente. /save-session + /resume-session + /sessions sobre un store canónico. Controles de runtime: ECC_HOOK_PROFILE=minimal|standard|strict y ECC_DISABLED_HOOKS./verify (build→lint→test→type-check), /quality-gate, /eval (harness de evaluación con grader types y pass@k). TDD obligatorio: RED→GREEN→REFACTOR con 80%+ cobertura, declarado en AGENTS.md como principio no negociable.skills/ es la superficie canónica. commands/ (84 slash commands) son shims de compatibilidad legacy que solo se tocan para parity cross-harness. Nuevo trabajo aterriza en skills primero.Agentes/comandos más representativos:
| Rol | Qué hace |
|---|---|
planner / architect | Planificación de implementación y diseño de sistema antes de tocar código |
tdd-guide | Fuerza el ciclo test-first en cualquier lenguaje |
code-reviewer / security-reviewer | Calidad, mantenibilidad y detección de vulnerabilidades |
*-build-resolver | Arregla errores de build por lenguaje (go, rust, kotlin, java, cpp, pytorch...) |
loop-operator | Ejecuta loops autónomos, monitoriza stalls e interviene |
harness-optimizer | Tunea la config del harness por fiabilidad, coste y throughput |
mle-reviewer | Revisa pipelines ML de producción (evals, serving, monitoring, rollback) |
🗂 Mapa de ficheros importantes
| Fichero / carpeta | Para qué sirve |
|---|---|
AGENTS.md | Instrucciones maestras: principios, los 64 agentes, reglas de orquestación, seguridad, estilo. Léelo primero. |
docs/architecture/cross-harness.md | El "por qué" del proyecto: modelo de portabilidad, qué viaja sin cambios y qué se adapta, la regla de oro del repo. |
COMMANDS-QUICK-REF.md | Referencia rápida de los slash commands agrupados por workflow + guía de decisión rápida. |
RULES.md | "Must Always / Must Never" + formato exacto de agentes, skills, hooks y commits. |
SOUL.md | Identidad y filosofía núcleo (versión condensada de los principios). |
skills/<name>/SKILL.md | Superficie canónica de workflow. 262 skills (deep-research, eval-harness, tdd-workflow, frontend-slides, mcp-server-patterns...). |
.agents/skills/*/ | Skills empaquetadas para harnesses genéricos, con agents/openai.yaml por skill. |
.claude/ | Superficie Claude Code: commands, rules, identity, homunculus/instincts, team config. |
.codex/ | Superficie Codex: AGENTS.md, config.toml y agentes TOML (explorer, reviewer, docs-researcher). |
.cursor/hooks/ | ~17 hooks JS por evento (before-shell, after-file-edit, session-start/end, pre-compact, subagent-*) — paridad de hooks en Cursor. |
ecc2/ | Prototipo Rust del control-plane (dashboard, start, sessions, status, daemon). Alpha. |
.claude-plugin/ · .codex-plugin/ | Manifiestos de plugin + marketplace para instalación en cada ecosistema. |
🎯 Qué puedes aplicar tú
- Adopta el patrón "fuente única + adaptadores finos" en tu propia Factory: tus skills/reglas de evaluación de startups viven una vez, y cada herramienta (Claude Code, Codex...) solo las carga. Tu
CLAUDE.mdya hace esto a pequeña escala — ECC lo lleva a multi-harness. - Copia la regla de oro: "si un cambio requiere editar el mismo workflow en 3 sitios, está en el sitio equivocado". Aplícalo a tus skills duplicadas entre proyectos.
- Estructura de SKILL.md: frontmatter con
name/description/origin+ sección "When to Use" + ejemplos repo-relativos + cero secretos. Es exactamente el formato que ya usan tus skills conTRIGGER when:/SKIP when:— valida que el tuyo es consistente. - Hooks de memoria entre sesiones: mira el patrón
SessionStart/Stop/pre-compactpara auto-guardar/recargar contexto. Útil para tu pipeline de ideas donde el estado vive en D1. - Loop de aprendizaje continuo (
/learn-eval→/evolve→/promote): destila patrones de tus sesiones de evaluación a skills reutilizables, en vez de re-prompt cada vez. Encaja con tu LEARNINGS.md. - Quality gate como comando único: agrupa build→lint→test→type-check en un
/verifypropio para tus MVPs antes de validar tracción. - Separa "durable" de "operativo": ECC distingue capa de skills (estable) de capa de control-plane (alpha). Útil para no acoplar tu metodología de scoring a la herramienta concreta del día.
⚠️ Limitaciones / cuándo NO usarlo
- Superficie enorme. 64 agentes + 262 skills + 84 comandos + 12 ecosistemas de lenguaje. Para un solo-founder con Claude Code, instalar todo es overkill: usa el selective install (manifest-driven,
install-plan.js) y coge solo lo que necesitas. - Paridad de hooks NO uniforme. Codex y Gemini son "compatibilidad por instrucción", no hooks nativos. Si dependes de enforcement automático (bloqueos pre-commit, sanitización), solo está garantizado en Claude Code/OpenCode/Cursor.
- La capa potente (ecc2/, sessions, control-plane) es ALPHA. "Usable como alpha, no release general." No la pongas en un flujo crítico todavía.
- Sesgo a equipos/multi-modelo. Muchos comandos (
/multi-plan,/devfleet,/orchestratecon tmux+worktrees) brillan en orquestación paralela pesada — más allá de lo que un portfolio micro-SaaS necesita. - Modelo freemium. El OSS es MIT y gratis para siempre, pero hay ECC Pro ($19/seat/mo), AgentShield y Itô gateados. Verifica qué es realmente libre antes de depender de algo.
- Cifras de marketing a verificar. Las 211.9K estrellas y los conteos exactos (64/262/84) salen del README/AGENTS.md del propio repo; el catálogo ha cambiado entre versiones (SOUL.md aún dice 30 agentes/135 skills). Trátalas como orden de magnitud, no como dato auditado.