Capítulo 1: Introducción y Filosofía

¿Qué es Everything Claude Code?

Everything Claude Code (ECC) es un sistema de optimización de rendimiento para agentes AI. No es una colección de prompts, no es un archivo de configuración glorificado, y no es un conjunto de buenas prácticas escritas en texto plano. Es una infraestructura de segunda capa que transforma cómo un agente de IA interactúa con tu codebase, tu flujo de trabajo y tu equipo.

La definición más precisa: ECC es un plugin de producción para Claude Code que orquesta agentes especializados, skills reutilizables, automatizaciones basadas en eventos, y reglas de convención aplicadas consistentemente, todo funcionando en conjunto para maximizar la productividad del desarrollador y minimizar el desperdicio de tokens.

El origen: 10+ meses de uso diario intensivo

ECC no nació de una tarde de experimentación ni de un tutorial de YouTube. Nació de la frustración acumulada de usar Claude Code todos los días para construir productos reales: APIs en producción, aplicaciones móviles, sistemas de infraestructura, herramientas internas. La curva de aprendizaje de usar agentes de IA de manera efectiva es mucho más empinada de lo que la mayoría de los tutoriales sugieren.

Los primeros meses revelaron patrones problemáticos que aparecían una y otra vez:

• El agente olvidaba convenciones que se le habían explicado en la sesión anterior
• Los costos de tokens se disparaban por exploración innecesaria de código que ya había sido analizado
• Las respuestas eran inconsistentes: el mismo tipo de tarea se resolvía de maneras diferentes en diferentes sesiones
• El contexto se degradaba dentro de una misma sesión conforme crecía el historial de conversación
• No había manera confiable de hacer que múltiples agentes trabajaran en el mismo proyecto sin colisiones

La solución evolutiva fue construir sistemas que atacaran cada uno de estos problemas de manera sistemática. Cada componente de ECC existe porque alguien lo necesitó en un proyecto real y sufrió sin él.

El hackathon de Anthropic x Forum Ventures

ECC ganó el hackathon organizado por Anthropic en colaboración con Forum Ventures. Esto no es un detalle menor: significa que el sistema fue evaluado contra otras propuestas por expertos que conocen profundamente tanto las capacidades como las limitaciones de Claude. La victoria no fue por el tamaño del sistema sino por su cohesión conceptual — la manera en que cada parte encaja con las demás para crear algo que es cualitativamente diferente a la suma de sus partes.

El hackathon fue un punto de inflexión porque obligó a articular de manera explícita por qué ECC funciona: no solo qué hace, sino el modelo mental detrás de las decisiones de diseño. Ese modelo mental es lo que este tutorial intenta transmitir.

Lo que ECC no es

Antes de profundizar en lo que ECC sí es, vale la pena ser explícito sobre lo que no es:

No es un prompt de sistema largo: Muchas personas intentan resolver los problemas de consistencia con agentes de IA simplemente escribiendo instrucciones más largas y detalladas en su CLAUDE.md. Esto funciona hasta cierto punto, pero tiene límites fundamentales. Un archivo de instrucciones no puede ejecutar lógica condicional, no puede activarse en respuesta a eventos, no puede delegar tareas a agentes especializados, y no puede aprender de sesiones anteriores.

No es un conjunto de templates: Los templates son estáticos. ECC es dinámico — los skills se activan en contextos específicos, los hooks responden a eventos del sistema, los agentes se especializan según el tipo de tarea.

No es una solución de configuración única: ECC está diseñado para ser adaptado. Los ejemplos de CLAUDE.md para diferentes tipos de proyectos no son para copiar y pegar; son puntos de partida que muestran cómo los principios se aplican en diferentes contextos.

No es solo para proyectos grandes: El valor de ECC escala con la frecuencia de uso, no con el tamaño del proyecto. Un desarrollador que usa Claude Code todos los días en proyectos pequeños se beneficia más de ECC que alguien que lo usa ocasionalmente en proyectos grandes.

---

El Problema que Resuelve ECC

Para entender el valor de ECC, primero hay que entender los problemas que ataca. Estos son problemas reales, con costos reales, que afectan a cualquier persona que use Claude Code de manera seria.

Problema 1: Context Rot

El context rot (deterioro del contexto) es quizás el problema más costoso y menos discutido del desarrollo con agentes de IA. Ocurre cuando la calidad de las respuestas del agente se degrada progresivamente dentro de una sesión conforme el historial de conversación crece.

El mecanismo es simple pero devastador: Claude tiene una ventana de contexto finita. Cuando esa ventana se llena, las partes más antiguas del contexto se pierden. Esto significa que las instrucciones que diste al inicio de la sesión, los archivos que mostraste, los patrones que explicaste — todo eso eventualmente desaparece del contexto efectivo del agente.

El resultado práctico: una sesión que empieza productiva se vuelve cada vez menos confiable. El agente empieza a “olvidar” convenciones, a repetir exploraciones de código que ya hizo, a generar soluciones que contradicen decisiones que se tomaron hace una hora.

ECC ataca el context rot en múltiples frentes:

• Rules que se reinyectan automáticamente: Las convenciones más importantes no dependen de que estén en el historial de conversación; están en archivos de reglas que el agente lee consistentemente.
• Hooks que mantienen el contexto técnico: Ciertos eventos del sistema (como terminar una tarea) activan hooks que reafirman el estado del proyecto.
• Skills con contexto encapsulado: Cada skill lleva consigo el contexto necesario para ejecutarse correctamente, sin depender de que ese contexto esté en el historial de conversación.
• Agentes especializados con contexto acotado: En lugar de un agente que necesita saber todo sobre el proyecto, agentes especializados trabajan con contextos más pequeños y enfocados.

Problema 2: Costos de Tokens Descontrolados

Claude Code puede volverse sorprendentemente caro si no se gestiona bien. Los patrones de uso ineficiente incluyen:

Exploración repetitiva: El agente lee los mismos archivos una y otra vez porque no tiene memoria persistente de lo que ya exploró. En un proyecto de tamaño mediano, esto puede representar miles de tokens por sesión.

Contexto innecesario: Sin guía, el agente incluye más contexto del necesario en cada operación. La respuesta a “¿qué hace esta función?” no necesita que el agente lea todo el proyecto.

Modelos incorrectos para la tarea: Usar el modelo más potente (Opus) para tareas simples que podría resolver Haiku cuesta 5-10 veces más sin ningún beneficio en calidad.

Conversaciones sin estructura: Las sesiones sin estructura tienden a generar más tokens que las sesiones con estructura. Un agente que “piensa en voz alta” innecesariamente puede gastar 2-3 veces más tokens que uno que trabaja de manera focused.

ECC incluye estrategias documentadas para reducir el consumo de tokens entre 60% y 90% sin sacrificar calidad de output. La clave está en la selección de modelos, la estructuración de contexto, y el uso de RTK (Rust Token Killer) como proxy que filtra output innecesario.

Problema 3: Falta de Estándares de Calidad

Sin un sistema de verificación, la calidad del output del agente es inconsistente. A veces genera código excelente; otras veces genera código que parece correcto pero tiene bugs sutiles, viola convenciones del proyecto, o introduce regresiones.

El problema fundamental es que el agente no tiene incentivos naturales para verificar su propio trabajo a menos que se le instruya explícitamente. Y si las instrucciones están solo en el historial de conversación, eventualmente desaparecen por context rot.

ECC incorpora loops de verificación en múltiples niveles:

• Post-edit hooks: Después de cada modificación de archivo, un hook verifica que el código compila, pasa lints, y no rompe tests existentes.
• Skills de revisión: El skill code-review ejecuta un análisis estructurado antes de considerar una tarea completada.
• Agente especializado de seguridad: Las modificaciones con implicaciones de seguridad activan análisis específico que un modelo de propósito general podría pasar por alto.
• Checkpoints de verificación: En tareas largas, hay puntos explícitos donde el agente debe verificar el estado del proyecto antes de continuar.

Problema 4: Inconsistencia Entre Sesiones

Sin persistencia de aprendizaje, cada sesión de Claude Code empieza desde cero. El agente no recuerda cómo preferís estructurar tu código, qué patrones se adoptaron en sesiones anteriores, qué decisiones arquitectónicas se tomaron, o qué errores ya se cometieron y se corrigieron.

Esta falta de persistencia tiene dos costos: el costo directo de tiempo que se pierde re-explicando cosas, y el costo indirecto de inconsistencias en el código porque el agente toma decisiones diferentes en diferentes sesiones.

ECC resuelve esto a través de:

• Memory hooks: El agente extrae y persiste “instincts” — patrones aprendidos de las sesiones — que se reinyectan en sesiones futuras.
• Project CLAUDE.md: El archivo de configuración del proyecto captura decisiones permanentes que no necesitan repetirse.
• Skills evolucionarios: Los skills no son estáticos; se actualizan cuando se descubren mejores patrones.

Problema 5: Dificultad de Paralelización

Escalar el trabajo de un agente a múltiples instancias paralelas es más difícil de lo que parece. Si dos agentes trabajan en el mismo codebase sin coordinación, inevitablemente generan conflictos: modifican el mismo archivo con cambios incompatibles, hacen suposiciones inconsistentes sobre el estado del código, o duplican trabajo.

ECC incluye estrategias explícitas para paralelización segura usando git worktrees — una característica de git que permite tener múltiples working directories apuntando al mismo repositorio. Cada agente paralelo trabaja en su propio worktree, y la coordinación se hace a través de planes bien definidos antes de empezar el trabajo paralelo.

---

Los 4 Principios Fundamentales

ECC está construido sobre cuatro principios que informan cada decisión de diseño. No son eslóganes — son restricciones de diseño que se aplican consistentemente.

Principio 1: Research Before Code

El principio más contraintuitivo de ECC es que la primera respuesta del agente a cualquier tarea de implementación no debería ser código. Debería ser investigación.

Antes de escribir una sola línea de código, el agente debe entender:

• ¿Qué ya existe en el codebase que sea relevante?
• ¿Qué convenciones se usan en el código existente?
• ¿Hay patrones establecidos para este tipo de problema?
• ¿Qué dependencias ya están disponibles?
• ¿Qué puede romper si se modifica esta área?

Este principio existe porque el error más costoso que comete un agente de IA no es escribir código incorrecto — es escribir código que ignora el contexto existente. Código que duplica funcionalidad, que viola las convenciones del proyecto, que introduce dependencias innecesarias, o que es incompatible con la arquitectura existente.

El skill search-first implementa este principio como una checklist explícita que el agente ejecuta antes de implementar cualquier cosa. La checklist incluye:

1. Buscar funcionalidad similar existente en el codebase
2. Leer la documentación del módulo o servicio que se va a modificar
3. Verificar las convenciones de estilo y arquitectura que aplican al área
4. Identificar los tests existentes que podrían verse afectados
5. Mapear las dependencias que usa el código relacionado

El beneficio no es solo calidad — también es eficiencia de tokens. Un agente que entiende el contexto antes de implementar escribe código más correcto en el primer intento, lo que significa menos ciclos de corrección y menos tokens gastados en iteraciones.

Anti-patrón: Saltar directamente a implementación al recibir una tarea. “Agregar autenticación a la API” se convierte en escribir código de autenticación desde cero cuando ya existe un sistema de autenticación en otra parte del codebase.

Ejemplo concreto: Antes de implementar un endpoint nuevo, el agente busca todos los endpoints existentes para entender el patrón de respuesta, el manejo de errores, los middleware que se usan, el sistema de validación, y la forma en que se estructuran los tests. Solo entonces implementa el endpoint nuevo, siguiendo exactamente los mismos patrones.

Cuándo aplica: Siempre que la tarea involucre modificar o extender código existente. La única excepción es cuando se está creando algo completamente nuevo en una área que no tiene código relacionado — y aun así, investigar las convenciones generales del proyecto sigue siendo valioso.

Principio 2: Verificación Continua, No Solo al Final

El modelo mental tradicional de desarrollo tiene verificación al final: implementas, luego corres los tests, luego revisas. ECC rompe con este modelo porque los problemas detectados al final son más costosos de corregir que los problemas detectados temprano.

En el contexto de agentes de IA, esto es especialmente importante porque el agente puede acumular errores a lo largo de una sesión. Un error cometido en el paso 2 de una tarea de 10 pasos puede invalidar todo el trabajo posterior si no se detecta hasta el paso 10.

ECC implementa verificación continua en múltiples niveles:

Nivel de línea (PostToolUse hooks): Después de cada modificación de archivo, hooks verifican que:

• El archivo sigue siendo sintácticamente válido
• No se introdujeron errores de TypeScript o errores de compilación obvios
• Los imports son válidos y los módulos referenciados existen

Nivel de cambio (después de cada set de modificaciones): El agente corre los tests relevantes al área que modificó, no toda la suite de tests. Esto da feedback rápido sin el costo de correr toda la suite.

Nivel de tarea (antes de declarar una tarea completada): El skill de revisión ejecuta un análisis completo que incluye build, tests, lint, y una revisión conceptual de si la implementación resuelve efectivamente el problema planteado.

Nivel de sesión (al finalizar una sesión larga): Un resumen estructurado que documenta qué se cambió, qué se verificó, y qué quedó pendiente.

Anti-patrón: Implementar todo y correr los tests al final. Cuando el test falla, no está claro cuál de las 15 modificaciones introdujo el error, lo que lleva a una sesión de debugging costosa.

Por qué funciona: La verificación continua reduce el espacio de búsqueda de errores. Si el test que falla pasaba hace dos modificaciones, el error está en esas dos modificaciones, no en todo el código.

El costo aparente: Parece que verificar después de cada modificación es más lento. En la práctica, el tiempo total es menor porque se eliminan los ciclos de debugging largos y el backtracking.

Principio 3: Economía de Tokens como Restricción de Diseño

La economía de tokens no es una optimización de bajo nivel — es una restricción de diseño de primer orden que impacta cómo se estructuran tasks, cómo se seleccionan modelos, y cómo se diseñan los workflows.

Este principio tiene dos componentes: eficiencia en la entrada (cuánto contexto se le da al agente) y eficiencia en la salida (cuánto output genera el agente).

Eficiencia en la entrada se logra a través de:

• Contexto acotado: el agente recibe el contexto mínimo necesario para la tarea, no el máximo disponible
• Compresión semántica: en lugar de mostrar archivos enteros, se muestran las partes relevantes con anotaciones
• Reutilización de contexto: los skills encapsulan contexto reutilizable que no necesita re-explicarse

Eficiencia en la salida se logra a través de:

• Instrucciones de formato: el agente produce output estructurado que va directo al punto, sin “pensamiento en voz alta” innecesario
• Segmentación de tareas: tareas largas se dividen en subtareas que cada una tiene un scope acotado
• Selección de modelos: tareas simples van a modelos más pequeños que generan outputs más concisos

La tabla de selección de modelos es una herramienta fundamental de este principio:

Tipo de Tarea	Modelo Recomendado	Justificación
Exploración / búsqueda de archivos	Haiku	Rápido, barato, suficiente para localizar código
Ediciones simples de un archivo	Haiku	Cambios claros y bien definidos
Implementación multi-archivo	Sonnet	Mejor balance para tareas de código
Arquitectura compleja	Opus	Razonamiento profundo necesario
Code review de PRs	Sonnet	Entiende contexto, captura matices
Análisis de seguridad	Opus	No se puede perder vulnerabilidades
Escritura de documentación	Haiku	Estructura simple, baja ambigüedad
Debugging de bugs complejos	Opus	Necesita mantener todo el sistema en mente
Refactoring de módulo grande	Sonnet	Contexto amplio, decisiones intermedias
Generación de tests unitarios	Haiku	Patrones repetitivos, alta estructura

El ahorro compuesto de seleccionar el modelo correcto es significativo. Si el 60% de tus tareas son exploraciones y ediciones simples, y las haces con Haiku en lugar de Opus, el ahorro es de 10-20x en esa porción del trabajo.

Anti-patrón: Usar siempre el modelo más potente disponible “por si acaso”. Esto es como usar un martillo neumático para colgar un cuadro — no solo es innecesariamente caro, también es más lento.

El balance correcto: El objetivo no es minimizar tokens a cualquier costo. Un agente que usa pocos tokens pero produce código incorrecto es más costoso en tiempo total que uno que usa más tokens pero produce código correcto en el primer intento. La economía de tokens es sobre eficiencia, no sobre frugalidad.

Principio 4: Aprendizaje Sistemático y Persistencia de Conocimiento

ECC parte de la premisa de que los agentes de IA mejoran con uso — pero solo si hay un sistema que capture y persista ese aprendizaje. Sin ese sistema, cada sesión empieza desde cero y el mismo conocimiento se re-descubre repetidamente.

El sistema de aprendizaje de ECC tiene tres componentes:

Instincts: Patrones aprendidos de sesiones que se capturan en formato estructurado. Un instinct es una observación del tipo “cuando modifiques el módulo de autenticación, siempre verifica los tests de integración, no solo los unitarios — los unitarios pasan pero los de integración pueden fallar por cambios en la serialización del token”. Los instincts son específicos al proyecto y van evolucionando conforme se descubren más patrones.

Skills evolucionarios: Los skills no son documentos estáticos escritos una vez. Tienen un mecanismo de evolución donde se capturan mejoras y refinamientos. Cuando un skill produce resultados sub-óptimos, hay un proceso para identificar qué falló y actualizar el skill. Con el tiempo, cada skill se vuelve más preciso y más eficiente.

Project memory: El CLAUDE.md del proyecto captura decisiones permanentes — decisiones arquitectónicas, convenciones adoptadas, trade-offs aceptados. Esto no es solo documentación; es contexto que el agente lee al inicio de cada sesión para calibrar su comportamiento al proyecto específico.

El efecto compuesto: Omar Sanseverino (@omarsar0) lo articuló bien: “Early on, I spent time building reusable workflows/patterns. Tedious to build, but this had a wild compounding effect as models and agent harnesses improved.” Este principio es la base del valor a largo plazo de ECC. Los primeros días de uso son más lentos porque se está construyendo la infraestructura. Después de algunas semanas, los workflows están ajustados al proyecto específico y la velocidad aumenta significativamente.

Anti-patrón: Empezar cada proyecto con ECC desde cero. Los learnings de proyectos anteriores son transferibles — las convenciones de verificación, los patrones de selección de modelos, los anti-patrones específicos al stack tecnológico.

---

Arquitectura Completa

La arquitectura de ECC es modular y jerárquica. Cada directorio tiene una responsabilidad específica, y las relaciones entre componentes son explícitas, no implícitas.

Diagrama de Arquitectura

graph TD
    subgraph "Capa de Entrada"
        CC[Claude Code / Cursor / OpenCode / Codex CLI]
        AGENT_MD[AGENTS.md]
        CLAUDE_MD[CLAUDE.md]
    end

    subgraph "Capa de Orquestación"
        COMMANDS[commands/\nSlash commands]
        HOOKS[hooks/\nEvent triggers]
        AGENTS[agents/\nSubagentes especializados]
    end

    subgraph "Capa de Conocimiento"
        SKILLS[skills/\nWorkflow definitions]
        RULES[rules/\nConvenciones]
        CONTEXTS[contexts/\nContextos dinámicos]
    end

    subgraph "Capa de Infraestructura"
        SCRIPTS[scripts/\nUtilidades cross-platform]
        MCP[mcp-configs/\nMCP server configs]
        EXAMPLES[examples/\nCLAUDE.md templates]
    end

    subgraph "Almacenamiento"
        MEMORY[.claude/memory/\nInstincts persistidos]
        SPECS[openspec/\nArtefactos SDD]
    end

    CC --> AGENT_MD
    CC --> CLAUDE_MD
    CLAUDE_MD --> COMMANDS
    CLAUDE_MD --> HOOKS
    HOOKS --> AGENTS
    COMMANDS --> SKILLS
    COMMANDS --> AGENTS
    AGENTS --> SKILLS
    SKILLS --> RULES
    SKILLS --> CONTEXTS
    SCRIPTS --> HOOKS
    MCP --> AGENTS
    HOOKS --> MEMORY
    AGENTS --> MEMORY

Flujo de una Tarea Típica

sequenceDiagram
    participant Dev as Desarrollador
    participant CC as Claude Code
    participant Hook as Hooks
    participant Agent as Agente especializado
    participant Skill as Skill
    participant Rules as Rules

    Dev->>CC: /implementar nuevo endpoint
    CC->>Hook: PreTask hook activa
    Hook->>CC: Inyecta contexto del proyecto
    CC->>Skill: Ejecuta search-first skill
    Skill->>CC: Mapeo del codebase relevante
    CC->>Agent: Delega a implementation-agent
    Agent->>Rules: Lee convenciones aplicables
    Rules->>Agent: Retorna convenciones de arquitectura
    Agent->>CC: Implementa con convenciones
    CC->>Hook: PostToolUse hook activa
    Hook->>CC: Verifica compilación y lint
    CC->>Agent: Reporta resultado
    Agent->>Skill: Ejecuta verification skill
    Skill->>CC: Corre tests relevantes
    CC->>Dev: Tarea completada + resumen
    CC->>Hook: PostTask hook activa
    Hook->>CC: Persiste instincts aprendidos

Relaciones Entre Componentes

Las relaciones no son solo de uso — tienen direcciones y tipos específicos:

Agents usan Skills: Un agente no implementa su propia lógica desde cero. Cuando necesita hacer algo, invoca el skill correspondiente. El skill define el “cómo”, el agente define el “cuándo” y el “con qué contexto”.

Hooks activan Agents: Los hooks no implementan lógica compleja directamente. Si un hook necesita hacer algo no trivial (como analizar el código modificado), activa un agente especializado.

Skills referencian Rules: Los skills saben qué hacer, pero las rules definen los estándares que el output debe cumplir. Un skill de implementación referencia las rules de arquitectura y estilo del proyecto.

Contexts son inyectados por Hooks: Los contextos dinámicos (modo desarrollo, modo review, modo debug) son activados automáticamente por hooks basados en el estado del proyecto, no seleccionados manualmente por el desarrollador.

Scripts son invocados por Hooks y Commands: Los scripts son utilidades puras — no tienen inteligencia, solo ejecutan operaciones determinísticas. Los hooks y commands los usan como building blocks.

---

Componentes en Detalle

agents/ — Subagentes Especializados

Los agentes son la unidad de especialización de ECC. Cada agente es un “experto” en un dominio específico: implementación, revisión de código, seguridad, documentación, debugging. El formato de un agente es Markdown con frontmatter YAML.

Un agente típico define:

• name: Identificador único
• description: Cuándo este agente es apropiado (esto es lo que Claude lee para decidir si delegarle una tarea)
• tools: Lista de herramientas a las que tiene acceso (controla el scope del agente)
• model: Modelo de Claude a usar (implementa el principio de economía de tokens)

La especialización de agentes tiene un beneficio no obvio: reduce el scope de contexto necesario. Un agente de seguridad no necesita entender el modelo de datos del negocio ni las convenciones de UI. Solo necesita entender los patrones de seguridad relevantes para el tipo de código que está analizando.

ECC incluye 25 agentes especializados. Los más importantes:

implementation-agent: El caballo de batalla. Maneja la mayoría de las tareas de implementación de código. Tiene acceso a todas las herramientas necesarias para modificar archivos, ejecutar comandos, y verificar cambios.

security-agent: Especializado en análisis de seguridad. Siempre usa Opus porque los errores en seguridad son inaceptables. Sabe buscar vulnerabilidades específicas según el lenguaje y framework.

review-agent: Code review estructurado. Evalúa no solo si el código funciona sino si es mantenible, si sigue las convenciones, y si introduce complejidad innecesaria.

debug-agent: Especializado en debugging. Tiene workflows específicos para diferentes tipos de bugs (race conditions, memory leaks, inconsistencias de datos).

docs-agent: Genera y mantiene documentación. Entiende los estándares de documentación del proyecto y puede generar tanto documentación inline como documentación de API.

refactor-agent: Especializado en refactoring seguro. Incluye verificaciones específicas para asegurar que el refactoring no cambia el comportamiento observable.

test-agent: Genera y mantiene tests. Entiende los patrones de testing del proyecto y puede generar tests significativos, no solo tests de cobertura vacíos.

skills/ — Workflow Definitions

Los skills son el corazón intelectual de ECC. Son documentos estructurados que definen workflows completos: no solo qué hacer, sino en qué orden, qué verificar, qué errores anticipar, y cómo recuperarse de failures.

ECC incluye 108 skills. La extensión no es accidental — cada skill existe porque hay un workflow recurrente que se beneficia de ser codificado explícitamente.

Un skill bien diseñado tiene estas secciones:

When to use: Criterios explícitos para cuándo este skill es el correcto. Esto es crítico porque el agente necesita saber cuándo invocar cada skill.

How it works: El workflow paso a paso. Cada paso es una instrucción accionable, no una descripción vaga.

Examples: Casos de uso concretos que ilustran el skill en contextos específicos.

Edge cases: Los casos especiales que este skill maneja de manera diferente al flujo principal.

Related skills: Skills que se usan en conjunto con este, o que son alternativas dependiendo del contexto.

Los skills más fundamentales de ECC:

search-first: El skill que implementa el principio research-before-code. Define la secuencia completa de investigación que debe ocurrir antes de cualquier implementación.

code-review: Análisis estructurado de código. Cubre legibilidad, mantenibilidad, correctness, seguridad, y performance. Tiene diferentes “profundidades” dependiendo del tipo de change.

spec-driven-development (SDD): El proceso completo de desarrollo dirigido por especificaciones. Desde la propuesta inicial hasta el archive del change completado.

debugging-workflow: Proceso sistemático de debugging que incluye hipótesis, verificación, y documentación de la causa raíz.

git-workflow: Convenciones de git incluyendo formato de commits, cuándo hacer branches, y cómo estructurar PRs.

token-optimization: Estrategias específicas para reducir consumo de tokens en diferentes tipos de tareas.

parallelization: Cómo distribuir trabajo entre múltiples agentes usando git worktrees.

commands/ — Slash Commands

Los slash commands son la interfaz explícita entre el desarrollador y ECC. Son comandos que el desarrollador puede invocar directamente (/review-pr 123, /implement-feature, /debug-issue).

ECC incluye 57 comandos. La diferencia entre un skill y un command es de iniciador: los skills son invocados por el agente cuando lo considera apropiado; los commands son invocados explícitamente por el desarrollador.

Los comandos más útiles:

/sdd-new [descripción]: Inicia el proceso SDD para un nuevo change. Crea el conjunto completo de artefactos (propuesta, specs, diseño, tasks) antes de escribir una línea de código.

/review-pr [número]: Code review estructurado de un Pull Request. Produce un análisis organizado por categorías (bugs, estilo, arquitectura, seguridad).

/debug [descripción del problema]: Activa el workflow de debugging, comenzando con la recopilación de información y terminando con la documentación de la solución.

/refactor [scope]: Inicia un refactoring seguro con checkpoints de verificación en cada paso.

/document [módulo]: Genera o actualiza la documentación para un módulo o API.

/security-audit: Análisis de seguridad completo usando el security-agent con Opus.

/learn: Activa el proceso de extracción de instincts de la sesión actual.

/status: Muestra el estado actual del proyecto incluyendo tasks pendientes, changes en progreso, y metrics de la sesión.

hooks/ — Event-Based Automation

Los hooks son automatizaciones que se activan en respuesta a eventos del sistema. Son la manera en que ECC implementa comportamientos automáticos sin requerir que el desarrollador los active manualmente.

ECC incluye 20+ hooks. Los hooks se definen en formato JSON con dos componentes: el matcher (qué evento activa el hook) y el comando (qué se ejecuta cuando el evento ocurre).

Los tipos de eventos incluyen:

• PreToolUse: Antes de que el agente use una herramienta
• PostToolUse: Después de que el agente usa una herramienta
• PreTask: Antes de empezar una tarea
• PostTask: Después de completar una tarea
• Notification: Cuando el agente genera una notificación

Los hooks más importantes de ECC:

auto-lint-on-edit: Después de cada modificación de archivo de código, corre el linter relevante. Si hay errores, los reporta inmediatamente en lugar de acumularlos.

verify-on-save: Similar al anterior pero también corre los tests relevantes al archivo modificado.

inject-context: Al inicio de cada sesión, inyecta el contexto del proyecto (estado actual, changes en progreso, instincts recientes).

persist-instincts: Al finalizar una tarea, extrae y persiste los patrones aprendidos.

model-selector: Basado en el tipo de tarea y el archivo siendo modificado, sugiere el modelo apropiado.

git-checkpoint: Antes de operaciones destructivas (rebase, force push), hace un checkpoint del estado del repositorio.

Un ejemplo de hook en formato JSON:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "node scripts/verify-syntax.js $CLAUDE_FILE_PATHS"
          }
        ]
      }
    ]
  }
}

rules/ — Convenciones Persistentes

Las rules son el mecanismo de convenciones persistentes. Son instrucciones que el agente debe seguir siempre, independientemente del contexto de la conversación.

ECC incluye 34 rules, organizadas en dos categorías:

common/: Rules que aplican a todos los proyectos y lenguajes. Incluyen convenciones de git, estándares de documentación, patrones de manejo de errores genéricos, y principios de arquitectura.

por lenguaje/framework: Rules específicas para TypeScript, Python, Rust, React, etc. Definen convenciones específicas de cada ecosistema.

Las rules se diferecian de las instrucciones en CLAUDE.md en que son más granulares y están organizadas por dominio. En lugar de un párrafo que dice “usa TypeScript estricto y maneja los errores apropiadamente”, hay una rule que dice exactamente qué significa “TypeScript estricto” en este proyecto y otra rule separada que define el patrón específico de manejo de errores.

Ejemplo de una rule de manejo de errores:

# Error Handling

## Never swallow errors silently
Every catch block must either:
1. Re-throw the error (after potentially enriching it with context)
2. Handle the error explicitly and document why it's safe to continue
3. Log the error with sufficient context for debugging

## Error enrichment pattern
When re-throwing, add context:
```typescript
try {
  await riskyOperation();
} catch (error) {
  throw new Error(`Failed to execute riskyOperation for user ${userId}: ${error.message}`, { cause: error });
}

Never use any for error types

Use unknown and narrow the type explicitly.

### scripts/ — Utilidades Cross-Platform

Los scripts son utilidades Node.js que realizan operaciones determinísticas que los hooks y commands necesitan. Son cross-platform por diseño — funcionan en macOS, Linux, y Windows sin modificaciones.

El uso de Node.js (en lugar de bash scripts) es intencional: los bash scripts son frágiles en Windows y tienen inconsistencias entre macOS y Linux. Node.js es el mínimo común denominador que garantiza comportamiento consistente.

Scripts importantes:

**verify-syntax.js**: Verifica la sintaxis del archivo modificado usando el parser del lenguaje correspondiente. No es solo una validación de formato — detecta errores de sintaxis que un linter puede pasar por alto.

**token-counter.js**: Cuenta el uso de tokens de una sesión y lo compara con benchmarks históricos.

**worktree-manager.js**: Gestiona git worktrees para paralelización, incluyendo creación, cleanup, y detección de conflictos.

**instinct-extractor.js**: Analiza el historial de una sesión y extrae patrones candidatos a instincts.

**model-recommender.js**: Basado en el tipo de archivo y tarea, recomienda el modelo apropiado.

### contexts/ — Contextos Dinámicos

Los contexts son conjuntos de instrucciones adicionales que se activan dinámicamente según el estado del trabajo. Permiten que el agente tenga comportamientos diferentes en diferentes fases del desarrollo sin requerir instrucciones manuales.

Los tres contextos principales:

**dev context**: Activo durante desarrollo normal. Prioriza velocidad y feedback rápido. Los checks de verificación son rápidos (solo el test relevante, no toda la suite).

**review context**: Activo cuando se está preparando código para revisión o merge. Prioriza exhaustividad. Todos los tests, análisis de seguridad, revisión de documentación.

**research context**: Activo durante exploración o debugging. Prioriza comprensión sobre velocidad. El agente documenta sus hallazgos, no solo resuelve el problema inmediato.

La activación de contextos puede ser manual (`/context dev`) o automática via hooks (el review context se activa automáticamente cuando se detecta que se está preparando un PR).

### mcp-configs/ — MCP Server Configurations

Model Context Protocol (MCP) extiende las capacidades de Claude Code conectándolo con herramientas externas. ECC incluye configuraciones probadas para los MCPs más útiles en desarrollo de software.

Las configuraciones cubren:

**GitHub MCP**: Acceso a la API de GitHub para leer issues, PRs, y comentarios directamente desde la sesión de Claude Code.

**Database MCP**: Conexión a bases de datos para consultar esquemas y datos directamente (con control de acceso apropiado).

**Browser MCP**: Automatización de browser para testing de UI y verificación de aplicaciones web.

**Filesystem MCP**: Acceso extendido al filesystem para operaciones que el agente nativo no puede hacer directamente.

**Documentation MCP**: Acceso a documentación de librerías y frameworks directamente en el contexto.

---

## El Efecto Compuesto

La pregunta razonable en este punto es: ¿por qué no simplemente usar algunos de estos componentes de manera independiente en lugar de adoptar todo el sistema?

La respuesta está en el efecto compuesto. Los componentes de ECC están diseñados para trabajar juntos, y su valor colectivo es significativamente mayor que la suma de sus valores individuales.

### Ejemplo: El Ciclo Completo de una Feature

Considera el proceso de implementar una feature nueva usando ECC en su totalidad:

**Paso 1 — Inicio con context injection**: El hook de inicio de sesión inyecta el estado actual del proyecto, los instincts relevantes de sesiones anteriores, y el contexto del change en progreso. El agente empieza la sesión "caliente" en lugar de "frío".

**Paso 2 — SDD Proposal**: El comando `/sdd-new implementar autenticación OAuth` activa el agente de propuesta que crea un documento estructurado describiendo el change, sus implicaciones, y los criterios de aceptación. Esto asegura alineación antes de escribir código.

**Paso 3 — Research phase**: Antes de implementar, el skill `search-first` mapea el codebase — qué módulos de autenticación existen, qué dependencias están disponibles, qué patrones usan las otras integraciones OAuth si las hay.

**Paso 4 — Implementación con verificación continua**: El agente implementa con el implementation-agent, y los hooks PostToolUse verifican cada modificación. Los errores se detectan y corrigen inmediatamente.

**Paso 5 — Review estructurado**: Antes de completar, el review-agent hace un análisis estructurado. El security-agent analiza el código de autenticación específicamente.

**Paso 6 — Persistencia de instincts**: El hook PostTask extrae patrones aprendidos — "el servidor OAuth X requiere scopes en un formato específico", "siempre verificar que el refresh token tiene TTL configurado". Estos instincts estarán disponibles en sesiones futuras relacionadas con autenticación.

**Resultado compuesto**: La feature se implementa correctamente en el primer intento o con mínimas iteraciones. El conocimiento de cómo implementarla queda persistido. La próxima feature similar tardará menos porque los instincts ya están disponibles.

### Comparación: Con y Sin ECC

```mermaid
graph LR
    subgraph "Sin ECC"
        A1[Nueva sesión\nfrío] --> B1[Exploración\n400 tokens]
        B1 --> C1[Implementación\nsin contexto]
        C1 --> D1[Error detectado\nal final]
        D1 --> E1[Debugging\n300 tokens]
        E1 --> F1[Re-implementación]
        F1 --> G1[Fin de sesión\nsin persistencia]
    end

    subgraph "Con ECC"
        A2[Nueva sesión\ncaliente] --> B2[Research focused\n150 tokens]
        B2 --> C2[Implementación\ncon contexto]
        C2 --> D2[Error detectado\ninmediatamente]
        D2 --> E2[Corrección en el momento\n50 tokens]
        E2 --> F2[Verificación continua]
        F2 --> G2[Instincts persistidos\npara próxima sesión]
    end

El ahorro no es solo en tokens — es en tiempo de desarrollo total y en calidad del output.

---

Comparativa con Otras Herramientas

Entender ECC en contexto requiere compararlo con las alternativas disponibles.

Tabla Comparativa

Característica	CLAUDE.md simple	ECC	Cursor Rules	OpenCode	Codex CLI
Agentes especializados	No	25 agentes	No	Parcial	No
Skills reutilizables	No	108 skills	Limitado	No	No
Hooks automáticos	No	20+ hooks	No	11 eventos	No
Verificación continua	Manual	Automática	Manual	Parcial	Manual
Memoria persistente	No	Instincts system	No	No	No
Selección de modelos	Manual	Semi-automática	No aplica	Manual	No
Paralelización	No	Git worktrees	No	No	Limitado
Cross-platform	Claude Code	CC+Cursor+OC+Codex	Cursor	OpenCode	Codex
SDD workflow	No	Completo	No	No	No
Token optimization	Manual	60-90% reducción	Manual	Manual	Manual
Curva de aprendizaje	Baja	Media-alta	Baja	Media	Baja
Setup inicial	Minutos	Horas	Minutos	Horas	Minutos

Cuándo es Mejor la Alternativa

CLAUDE.md simple es suficiente cuando:

• Usás Claude Code esporádicamente (menos de 5 horas/semana)
• Trabajás en proyectos cortos o experimentales sin convenciones establecidas
• No querés invertir tiempo en setup inicial

Cursor Rules puede ser mejor cuando:

• Trabajás principalmente en Cursor IDE
• El editor integration es más importante que los workflows de agente
• Tu equipo ya tiene convenciones de Cursor establecidas

OpenCode puede ser mejor cuando:

• Querés máxima flexibilidad en la configuración del agente
• Tenés casos de uso muy específicos que requieren eventos personalizados
• El ecosistema de plugins de OpenCode resuelve problemas específicos que ECC no cubre

La Propuesta de Valor Única de ECC

Lo que ECC ofrece que ninguna alternativa tiene completamente:

1. Sistema de aprendizaje persistente: Los instincts que ECC acumula con el tiempo son únicos. No hay otra herramienta que extraiga y persista conocimiento de sesiones de agente de esta manera.

2. SDD workflow integrado: La integración del Spec-Driven Development con los demás componentes de ECC crea un flujo completo desde la idea hasta el archive del change.

3. Profundidad de especialización de agentes: Los 25 agentes no son genéricos — están especializados para tipos específicos de trabajo con prompts y configuraciones probadas.

4. Optimización económica sistémica: La combinación de selección de modelos + RTK + skills optimizados + contexts acotados produce una reducción de tokens que es difícil de replicar con configuraciones más simples.

---

Compatibilidad Cross-Platform

ECC está diseñado para funcionar con múltiples herramientas de desarrollo con IA. La estrategia de compatibilidad es pragmática: máximo soporte para Claude Code (el target principal), soporte completo para las alternativas más populares.

Claude Code — Target Principal

Claude Code es el ambiente para el que ECC está optimizado. Todos los componentes funcionan en su capacidad completa:

• Los hooks se registran en .claude/settings.json
• Los agentes se definen en .claude/agents/
• Los skills se acceden via el sistema de skills nativo
• Los commands se invocan con la sintaxis /command
• El CLAUDE.md del proyecto se lee automáticamente

La integración es nativa y sin fricción. La única configuración adicional necesaria es apuntar al directorio de ECC en el CLAUDE.md del proyecto.

Cursor IDE — Soporte Completo

Cursor lee el archivo .cursorrules en la raíz del proyecto. ECC incluye un generador que produce un .cursorrules optimizado basado en los rules y contexts relevantes para el proyecto.

Los hooks en Cursor funcionan de manera diferente — Cursor tiene un sistema de eventos propio. ECC incluye adaptadores que mapean los hooks de ECC al sistema de eventos de Cursor.

Los agents de ECC se pueden usar en Cursor a través del sistema de composer de Cursor, con algunas limitaciones: la selección de modelos no es tan flexible y algunos hooks avanzados no tienen equivalente en Cursor.

Setup para Cursor:

# Generar .cursorrules desde los rules de ECC
node scripts/generate-cursor-rules.js > .cursorrules

# Copiar contexts relevantes como Cursor chat contexts
node scripts/generate-cursor-contexts.js

OpenCode — Plugin Completo con 11 Eventos

OpenCode tiene el sistema de eventos más rico de las alternativas a Claude Code. ECC aprovecha los 11 eventos de OpenCode para implementar una versión completa del sistema de hooks.

Los 11 eventos de OpenCode que ECC mapea:

1. file:write → verify-syntax hook
2. file:delete → dependency-check hook
3. task:start → context-inject hook
4. task:complete → instinct-persist hook
5. task:fail → error-document hook
6. session:start → warm-start hook
7. session:end → session-summary hook
8. tool:use → token-track hook
9. agent:spawn → model-select hook
10. git:commit → lint-check hook
11. git:push → security-scan hook

El AGENTS.md en la raíz del proyecto es el punto de entrada para OpenCode — es el formato que OpenCode lee para entender las convenciones del proyecto.

Codex CLI — Config de Referencia

Codex CLI es más minimalista que las otras opciones. ECC provee una configuración de referencia que incluye:

• AGENTS.md: El archivo universal que Codex CLI lee para instrucciones del proyecto
• Subset de rules: Las rules más importantes en un formato compatible con Codex
• Scripts adaptados: Versiones de los scripts que funcionan con los comandos de Codex

El soporte para Codex CLI es deliberadamente más limitado — Codex es una herramienta de menor escala y la complejidad completa de ECC sería contraproducente.

El Archivo AGENTS.md Universal

AGENTS.md en la raíz del proyecto es el punto de convergencia de compatibilidad. Todas las herramientas lo leen, aunque lo usan de maneras ligeramente diferentes.

ECC genera y mantiene el AGENTS.md del proyecto automáticamente, asegurando que siempre refleja el estado actual de las convenciones y configuraciones.

La estructura del AGENTS.md incluye:

• Descripción del proyecto y stack tecnológico
• Convenciones de código más importantes
• Instrucciones específicas por sección del codebase
• Herramientas disponibles y cómo usarlas
• Anti-patrones específicos de este proyecto

---

El Modelo Mental: Capas de Abstracción

La manera más clara de entender cómo ECC funciona es pensar en capas de abstracción. Cada capa resuelve una categoría de problemas y está apoyada en las capas inferiores.

graph TB
    L4["Capa 4: Workflows\nSDD, debugging, review, refactoring\n(procesos completos de desarrollo)"]
    L3["Capa 3: Especialización\nAgentes, skills, comandos\n(quién hace qué y cómo)"]
    L2["Capa 2: Automatización\nHooks, scripts\n(cuándo y qué automáticamente)"]
    L1["Capa 1: Convenciones\nRules, contexts\n(qué está siempre activo)"]
    L0["Capa 0: Infraestructura\nMCP, CLAUDE.md, AGENTS.md\n(conexión con el mundo externo)"]

    L4 --> L3
    L3 --> L2
    L2 --> L1
    L1 --> L0

Capa 0 — Infraestructura: La conexión entre el agente y el entorno. Los archivos de configuración, los servidores MCP, los puntos de entrada por herramienta. Sin esta capa, el agente no sabe dónde está ni qué tiene disponible.

Capa 1 — Convenciones: El “siempre” del sistema. Las rules definen comportamientos que se aplican independientemente del contexto. Los contexts definen qué rules están activas según el modo de trabajo. Esta capa es la que garantiza consistencia entre sesiones.

Capa 2 — Automatización: El “cuándo” del sistema. Los hooks convierten eventos del sistema en acciones. Esta capa elimina la carga cognitiva de recordar qué hacer después de cada acción. El desarrollador no necesita pensar “después de modificar este archivo, debería correr el linter” — el hook lo hace automáticamente.

Capa 3 — Especialización: El “quién” y “cómo” del sistema. Los agentes especializados traen expertise específico a tipos específicos de tareas. Los skills codifican workflows probados. Los commands dan acceso explícito a capacidades de alto nivel. Esta capa es donde ocurre la mayor parte del trabajo.

Capa 4 — Workflows: El “qué” de alto nivel del sistema. Los procesos completos de desarrollo (SDD, debugging, review) que orquestan todas las capas inferiores para lograr objetivos de alto nivel. Esta capa es la más cercana al desarrollador y la más visible.

La clave del modelo de capas es que cada capa puede ser usada independientemente, pero el valor máximo se obtiene cuando todas trabajan juntas. Un desarrollador puede adoptar ECC capa por capa, empezando por las capas 0 y 1 (infraestructura y convenciones) y gradualmente adoptando las capas superiores conforme se familiariza con el sistema.

---

Números del Sistema

ECC tiene escala real. Entender qué representa cada número ayuda a dimensionar la profundidad del sistema.

25 Agentes Especializados

Los 25 agentes no son 25 variantes del mismo prompt genérico. Cada uno está especializado con:

• Un dominio de expertise específico
• Un conjunto acotado de herramientas
• Un modelo apropiado para el tipo de tarea
• Criterios de activación claros

Los 25 agentes cubren las áreas más críticas del desarrollo: implementación, testing, seguridad, documentación, debugging, refactoring, arquitectura, data modeling, API design, performance, accessibility, devops, code review, y varias más.

¿Qué significa tener 25 agentes? Significa que para cada tipo importante de tarea de desarrollo, hay un agente que:

• Ya sabe cómo abordar ese tipo de tarea
• Usa el modelo apropiado (economía de tokens)
• Tiene los checks de verificación correctos
• Sabe qué errores son comunes y cómo evitarlos

108 Skills

108 skills representa la codificación de más de 10 meses de workflows. Cada skill es el resultado de al menos una sesión donde el proceso ad-hoc fue lo suficientemente valioso para formalizarlo.

Los 108 skills se pueden categorizar aproximadamente:

• ~30 skills de implementación (diferentes lenguajes, frameworks, patrones)
• ~20 skills de testing y verificación
• ~15 skills de arquitectura y diseño
• ~12 skills de git y colaboración
• ~10 skills de optimización y performance
• ~8 skills de seguridad
• ~7 skills de documentación
• ~6 skills de debugging

¿Qué significa tener 108 skills? Significa que para la gran mayoría de workflows de desarrollo recurrentes, ya existe un skill que define el proceso óptimo. El desarrollador no necesita descubrir el mejor proceso para hacer code review de seguridad — ya está codificado.

57 Comandos

57 comandos representan la interfaz explícita del sistema. Son los workflows de alto nivel que el desarrollador invoca conscientemente.

La distribución aproximada:

• ~20 comandos de SDD workflow
• ~10 comandos de code review y análisis
• ~8 comandos de debugging y troubleshooting
• ~7 comandos de gestión de código (refactor, migrate, cleanup)
• ~5 comandos de documentación
• ~4 comandos de gestión de sesión
• ~3 comandos de infraestructura (MCP, hooks, agents)

¿Qué significa tener 57 comandos? Significa que hay 57 workflows de alto nivel que se pueden activar con una sola instrucción. /security-audit en lugar de “corre un análisis de seguridad completo del codebase usando el modelo Opus, verifica OWASP Top 10, analiza las dependencias por vulnerabilidades conocidas, y produce un reporte estructurado con prioridades de remediación”.

20+ Hooks

Los 20+ hooks cubren el ciclo completo del evento del sistema: antes y después de cada operación importante. Los hooks son el sistema nervioso autónomo de ECC — responden automáticamente sin requerir intervención consciente.

¿Qué significa tener 20+ hooks? Significa que las verificaciones más importantes ocurren automáticamente. El desarrollador no necesita recordar hacer lint después de cada cambio, ni persistir instincts al final de cada sesión, ni verificar que el build no se rompió antes de hacer commit.

34 Rules

34 rules es el balance entre tener suficientes convenciones para garantizar consistencia y no tener tantas que el sistema se vuelva difícil de entender. Cada rule existe porque hay un patrón recurrente donde los agentes toman malas decisiones cuando no tienen la convención explícita.

¿Qué significa tener 34 rules? Significa que hay 34 categorías de decisiones donde el agente tiene instrucciones explícitas en lugar de depender de su conocimiento general. Las rules son las vallas de seguridad que previenen la mayoría de los errores comunes.

---

¿Cuándo Usar ECC?

La decisión de adoptar ECC no es binaria — hay niveles de adopción que tienen sentido para diferentes situaciones.

Criterios para Adopción Completa

Adoptá ECC completamente si se cumplen la mayoría de estos criterios:

Frecuencia de uso alta: Si usás Claude Code más de 10 horas por semana, el ROI de ECC es inmediato. El costo de setup (unas pocas horas) se recupera en la primera semana.

Proyectos con convenciones establecidas: ECC brilla cuando hay convenciones que vale la pena reforzar consistentemente. Proyectos sin convenciones se benefician menos.

Trabajo en equipo: Cuando múltiples desarrolladores usan Claude Code en el mismo proyecto, ECC garantiza consistencia entre sesiones de diferentes personas.

Proyectos de larga duración: El valor del sistema de aprendizaje es proporcional a la duración del proyecto. En proyectos de más de un mes, los instincts acumulados hacen una diferencia significativa.

Codebase de tamaño medio a grande: En codebases donde la exploración ad-hoc es costosa en tokens, los skills de research-first generan ahorro inmediato.

Preocupación por costos: Si el gasto en tokens es un factor, ECC puede reducirlo 60-90% en el uso diario.

Criterios para Adopción Parcial

Adoptá ECC parcialmente si:

Usás Claude Code regularmente pero no intensivamente: Implementá solo las capas 0-2 (infraestructura, convenciones, automatización básica). El valor de las capas superiores requiere uso más intensivo para justificar el costo de setup.

Tenés un stack tecnológico específico no cubierto: ECC tiene cobertura amplia pero no es exhaustivo. Si tu stack es muy específico, puede que necesites crear skills personalizados antes de que el sistema sea útil.

Preferís adopción gradual: Empezá con los hooks de verificación y el sistema de rules. Agregá skills y agentes conforme los necesitás.

Casos de Uso Donde ECC Agrega Máximo Valor

Desarrollo de API backend: Los hooks de verificación, los skills de API design, y el security-agent crean una combinación muy poderosa para desarrollo de APIs.

Refactoring de codebase legada: El refactor-agent con sus checkpoints de verificación y el proceso SDD para planificar el refactoring reducen el riesgo de regresiones.

Proyectos con requisitos de seguridad: El security-agent y los hooks de análisis de seguridad son especialmente valiosos cuando la seguridad no es negociable.

Equipos que adoptan AI por primera vez: ECC provee estructura que ayuda a los equipos a aprender buenos hábitos de uso de agentes de IA desde el inicio.

Freelancers con múltiples proyectos: El sistema de instincts y la portabilidad de los skills entre proyectos crea economías de escala.

Anti-Casos: Cuándo No es la Herramienta Correcta

Exploración y experimentación rápida: Si estás explorando una idea nueva y no tenés convenciones establecidas, ECC agrega fricción sin beneficio. Un CLAUDE.md simple es suficiente.

Proyectos de un día: El costo de setup no se justifica para proyectos que durarán menos de una semana.

Usuarios que prefieren control total: ECC automatiza muchas decisiones. Si preferís control manual sobre cada interacción con el agente, ECC será frustrante.

Stacks muy experimentales: Si estás trabajando con tecnologías tan nuevas que no hay skills relevantes, tendrías que construir la mayor parte de ECC desde cero para tu caso. Es más eficiente empezar simple y agregar estructura conforme el proyecto madura.

---

El Ciclo de Mejora Continua

ECC no es estático. El sistema está diseñado para mejorar con el uso, tanto a nivel de proyecto (instincts específicos al proyecto) como a nivel del sistema base (actualización de skills y agentes conforme se descubren mejores patrones).

El Ciclo de Aprendizaje de Proyecto

stateDiagram-v2
    [*] --> Sesión_Activa
    Sesión_Activa --> Tarea_Completada
    Tarea_Completada --> Extracción_Instincts
    Extracción_Instincts --> Instincts_Candidatos
    Instincts_Candidatos --> Revisión_Humana
    Revisión_Humana --> Instinct_Aprobado: Sí, es un patrón válido
    Revisión_Humana --> Instinct_Descartado: No es generalizable
    Instinct_Aprobado --> Base_de_Conocimiento
    Base_de_Conocimiento --> Sesión_Activa: Inyectado en próxima sesión
    Instinct_Descartado --> [*]

El ciclo empieza con una sesión de trabajo normal. Al completar tareas, el hook PostTask activa el proceso de extracción de instincts. El script instinct-extractor.js analiza el historial de la sesión y genera candidatos a instincts — observaciones sobre el codebase o el proceso que podrían ser útiles en el futuro.

Los instincts candidatos se presentan al desarrollador para revisión. No todos los patrones observados son generalizables — algunos son específicos a una situación única. El desarrollador aprueba los instincts que sí son generalizables y descarta los que no.

Los instincts aprobados se persisten en .claude/memory/ y se inyectan automáticamente en sesiones futuras relevantes. Con el tiempo, la base de conocimiento crece y el agente empieza a tener mejor “intuición” sobre el proyecto específico.

El Ciclo de Mejora del Sistema Base

A nivel del sistema ECC mismo, hay un ciclo similar. Cuando un skill produce resultados sub-óptimos, hay un proceso documentado para identificar qué falló y actualizar el skill. El repositorio de ECC recibe contribuciones de mejoras basadas en uso real.

Este ciclo tiene un efecto compuesto importante: conforme ECC mejora y los modelos de Claude mejoran, los beneficios se multiplican. Un skill diseñado hoy puede volverse más efectivo mañana simplemente porque el modelo mejoró — y el skill está estructurado de manera que aprovecha las mejoras del modelo.

Midiendo el Progreso

ECC incluye métricas para medir el progreso del ciclo de mejora:

Token efficiency ratio: Tokens usados por tarea comparado con el baseline histórico. Un ratio que mejora con el tiempo indica que los instincts y skills están funcionando.

First-attempt success rate: Porcentaje de tareas que se completan correctamente sin necesidad de correcciones. Una tasa que mejora indica que el contexto de proyecto está siendo usado efectivamente.

Session productivity: Features implementadas, bugs resueltos, o PRs revisados por hora de sesión. Una métrica de alto nivel que captura el efecto combinado de todas las optimizaciones.

Instinct utilization: Cuántos instincts del proyecto se usan activamente vs. cuántos están en la base de conocimiento pero raramente se acceden. Ayuda a curar la base de conocimiento eliminando instincts obsoletos.

---

Primeros Pasos: La Mentalidad Correcta

Adoptar ECC efectivamente requiere un cambio de mentalidad. Los desarrolladores que obtienen mayor valor de ECC son los que entienden que están invirtiendo en infraestructura de desarrollo, no en una herramienta que da resultados inmediatos sin esfuerzo.

Mentalidad 1: Inversión vs. Gasto

El setup inicial de ECC toma tiempo. Entender los componentes, configurar los hooks, personalizar las rules para el proyecto — esto es una inversión que tiene un payback. La mentalidad correcta no es “¿por qué tengo que hacer todo esto?”, sino “¿cuándo recupero este tiempo invertido?”.

La respuesta típica: para uso intensivo diario, el punto de equilibrio es de 1-2 semanas. Después de ese punto, cada semana de uso produce ROI positivo acumulado.

Mentalidad 2: El Sistema es Tuyo, No una Caja Negra

ECC provee componentes probados, pero el sistema final es tuyo. Los skills se deben adaptar a las convenciones de tu proyecto. Los hooks se deben ajustar a tu stack tecnológico. Las rules se deben actualizar para reflejar las decisiones arquitectónicas de tu equipo.

Un error común es usar ECC sin adaptarlo y luego frustrarse cuando los skills no producen exactamente el resultado esperado. Los skills son puntos de partida, no soluciones finales.

Mentalidad 3: Fallos como Información

Cuando ECC no produce el resultado esperado — cuando un skill falla, cuando un hook genera un falso positivo, cuando un agente toma una decisión incorrecta — esto es información valiosa, no solo un problema a resolver.

La pregunta productiva no es “¿por qué esto no funciona?”, sino “¿qué debería agregar al sistema para que esto funcione mejor la próxima vez?” Cada fallo es una oportunidad de mejorar el sistema.

Mentalidad 4: Empezar Simple y Agregar Complejidad

No hay que adoptar los 25 agentes, los 108 skills, y los 20 hooks en el primer día. La adopción gradual por capas (como se describió en el modelo de capas) es más efectiva porque:

1. Permite entender cada componente antes de agregar el siguiente
2. El valor de las capas inferiores es inmediato y no requiere que las capas superiores estén configuradas
3. Reduce el riesgo de configuraciones incorrectas que afectan todo el sistema

El orden recomendado de adopción:

1. CLAUDE.md básico con rules fundamentales
2. Hooks de verificación post-edit
3. Skills más frecuentes (search-first, code-review)
4. Agentes especializados para las tareas más recurrentes
5. SDD workflow completo
6. Sistema de instincts y aprendizaje

Mentalidad 5: El Agente como Colega, No como Herramienta

El mayor cambio de mentalidad que requiere ECC es ver al agente de IA no como una herramienta que ejecuta comandos, sino como un colega con quien se trabaja colaborativamente.

Un colega necesita contexto para hacer buen trabajo. Un colega mejora con feedback. Un colega tiene áreas de expertise y áreas donde necesita ayuda. Un colega comete errores y aprende de ellos.

ECC está diseñado para hacer más productiva esa relación colaborativa: proveyendo al agente el contexto que necesita, capturando el feedback de manera sistemática, aprovechando las áreas de expertise via agentes especializados, y aprendiendo de los errores via el sistema de instincts.

---

Ejercicios Prácticos

Los siguientes ejercicios están diseñados para construir comprensión práctica de los conceptos del capítulo. Se recomiendan hacerlos en orden.

Ejercicio 1: Auditoría de tu Workflow Actual

Objetivo: Identificar dónde en tu workflow actual de Claude Code estás perdiendo más valor.

Procedimiento:

1. En tu próxima sesión de Claude Code, toma notas de:

   • Cuántas veces el agente exploró archivos que ya había explorado antes
   • Cuántas veces el agente ignoró convenciones del proyecto
   • Cuántas veces tuviste que corregir código que “parecía” correcto
   • Cuántas veces re-explicaste el mismo contexto

2. Al final de la sesión, categoriza cada ineficiencia en uno de los 5 problemas de ECC (context rot, costos descontrolados, falta de estándares, inconsistencia, dificultad de paralelización)

3. Identifica cuál de los 5 problemas es el más costoso en tu workflow

Resultado esperado: Una lista priorizada de problemas que ECC resuelve, ordenada por impacto en tu caso específico. Esto te ayudará a saber por qué capa de ECC empezar la adopción.

Ejercicio 2: Mapeando tu Codebase para ECC

Objetivo: Entender qué información del proyecto debe capturarse en el CLAUDE.md inicial.

Procedimiento:

1. Lista las 5 convenciones más importantes de tu proyecto (naming conventions, patrones de arquitectura, estándares de error handling, etc.)

2. Para cada convención, identifica:

   • ¿El agente la sigue consistentemente sin instrucciones? → No necesita rule
   • ¿El agente la sigue solo cuando se la recordás? → Candidata a rule
   • ¿El agente la ignora incluso cuando se la recordás? → Necesita skill + rule

3. Lista las 3 áreas del codebase donde el agente comete más errores

4. Identifica qué contexto del proyecto necesitaría el agente para no cometer esos errores

Resultado esperado: El contenido inicial de tu CLAUDE.md personalizado para el proyecto, con las convenciones más críticas expresadas como rules.

Ejercicio 3: Diseñando tu Primer Skill

Objetivo: Crear un skill personalizado para el workflow más recurrente en tu proyecto.

Procedimiento:

1. Identifica el tipo de tarea que repetís más frecuentemente (ejemplos: “crear nuevo endpoint REST”, “implementar componente React”, “agregar test de integración”)

2. Escribe paso a paso el proceso óptimo para esa tarea, incluyendo:

   • Qué investigar antes de empezar
   • Los pasos de implementación en orden
   • Qué verificar en cada paso
   • Cómo saber que la tarea está completa

3. Formatealo como un skill de ECC (secciones: When to use, How it works, Examples, Edge cases)

4. Usalo en tu próxima tarea de ese tipo y documenta qué funcionó y qué necesita ajuste

Resultado esperado: Un skill personalizado que define el proceso óptimo para tu tarea más recurrente. Este skill se volverá más valioso con cada uso porque podrás refinarlo.

Ejercicio 4: Configurando los Hooks de Verificación

Objetivo: Implementar el hook de verificación más básico y medir su impacto.

Procedimiento:

1. Identifica el verificador más básico para tu stack (examples: tsc --noEmit para TypeScript, eslint para JavaScript, cargo check para Rust)

2. Crea un hook PostToolUse que corra ese verificador después de cada modificación de archivo de código

3. Usá el hook durante una semana y documenta:

   • Cuántos errores capturó que hubieras descubierto más tarde
   • Cuántos falsos positivos generó (errores esperados durante implementación en progreso)
   • Cuánto tiempo de debugging le atribuís al hook

4. Basado en los falsos positivos, refiná el hook (por ejemplo, ignorar ciertos tipos de errores durante implementación activa)

Resultado esperado: Un hook de verificación calibrado a tu workflow específico, con datos reales sobre su impacto.

Ejercicio 5: Tu Primer Ciclo de Instincts

Objetivo: Vivir el ciclo completo de aprendizaje de ECC una vez.

Procedimiento:

1. Al final de tu próxima sesión de trabajo con Claude Code (de al menos 2 horas), revisa el historial de la sesión

2. Identifica 3 observaciones del tipo:

   • “Aprendí que en este codebase, [algo específico] funciona de manera diferente a lo esperado”
   • “La próxima vez que haga [tipo de tarea], debería empezar por [acción específica]”
   • “El agente tuvo problemas con [área], la solución fue [contexto específico]”

3. Escribe cada observación como un instinct en el formato: Contexto: [cuándo aplica] | Observación: [qué aprendiste] | Acción: [qué hacer diferente]

4. Guarda los instincts en .claude/memory/project-instincts.md

5. Al inicio de tu próxima sesión, lee esos instincts y verifica si alguno es relevante para la tarea que vas a hacer

Resultado esperado: Tu primera base de instincts de proyecto. Con el tiempo, esta base se convierte en uno de los activos más valiosos de tu workflow con Claude Code.

---

Anatomía de un Agente ECC: Lectura Técnica Profunda

Para entender realmente cómo funciona ECC, vale la pena diseccionar la anatomía de un agente real. Tomemos el security-agent como ejemplo porque es uno de los más críticos y mejor diseñados.

Estructura de Frontmatter de un Agente

---
name: security-analyst
description: >
  Specialized security analysis agent. Use when analyzing code for
  security vulnerabilities, reviewing authentication/authorization logic,
  checking for injection vulnerabilities, or performing security audits.
  Always uses Opus for maximum accuracy.
tools:
  - Read
  - Grep
  - Bash
model: claude-opus-4-5
---

Cada campo tiene significado específico:

name: El identificador único que otros agentes y commands usan para referenciar este agente. Es convención usar kebab-case.

description: Este campo es crítico. Claude lee esta descripción para decidir si delegar una tarea a este agente. Una descripción vaga resulta en delegación incorrecta. Una descripción demasiado amplia hace que el agente sea invocado cuando no es necesario. La descripción debe ser precisa y restrictiva.

tools: La lista de herramientas disponibles para el agente. Limitar las herramientas no es solo sobre seguridad — también es sobre economía de tokens. Un agente que tiene acceso solo a Read y Grep no puede escribir archivos accidentalmente, y sus tokens de herramienta son más baratos que los de un agente con acceso completo.

La lista de herramientas de Claude Code incluye:

• Read: Leer archivos
• Write: Escribir archivos
• Edit: Editar secciones de archivos
• Bash: Ejecutar comandos del sistema
• Grep: Buscar patrones en archivos
• Glob: Listar archivos por patrón
• WebFetch: Obtener contenido de URLs
• TodoWrite/TodoRead: Gestionar lista de tareas

Un agente de análisis de seguridad no necesita Write ni Edit — solo lee y analiza. Restricción mínima de privilegios aplicada a agentes de IA.

model: La selección de modelo a nivel de agente. Esto es central al principio de economía de tokens. El security-agent siempre usa Opus porque los falsos negativos en seguridad son inaceptablemente costosos.

El Body del Agente: Instrucciones de Comportamiento

Después del frontmatter, el cuerpo del agente define cómo debe comportarse. Un agente bien diseñado tiene estas secciones:

Rol y Especialización: Define el expertise del agente de manera que calibre su “modo de pensar”.

You are a security analyst specialized in application security.
Your role is to identify vulnerabilities, not to implement fixes.
For every vulnerability found, provide: severity (CRITICAL/HIGH/MEDIUM/LOW),
description, proof of concept, and remediation guidance.

Metodología: Define el proceso paso a paso que el agente debe seguir.

## Analysis Methodology

1. Map the attack surface: identify all entry points (APIs, file uploads, user inputs)
2. Trace data flow from entry to storage/output
3. Check for OWASP Top 10 in order of severity
4. Analyze authentication and authorization logic
5. Review cryptographic implementations
6. Check for sensitive data exposure
7. Validate dependency security (known CVEs)

Output Format: Define el formato exacto del reporte de seguridad.

## Output Format

For each vulnerability found:

SEVERITY: [CRITICAL|HIGH|MEDIUM|LOW] TYPE: [Injection|Auth|XSS|CSRF|etc] LOCATION: [file:line] DESCRIPTION: Clear explanation of the vulnerability EXPLOIT: How it could be exploited REMEDIATION: Specific fix with code example

Scope Limits: Define qué está dentro y fuera del scope del agente.

## Out of Scope
- Performance issues (unless they enable DoS)
- Code style violations
- Architecture decisions (unless they create security issues)
- Business logic bugs (unless they have security implications)

Esta estructura hace que el agente sea predecible — siempre produce el mismo tipo de output en el mismo formato, independientemente de quién lo invoca o en qué sesión.

---

Anatomía de un Skill ECC: Lectura Técnica Profunda

Si los agentes son el “quién”, los skills son el “cómo”. Diseccionemos el skill search-first — el más fundamental de ECC.

Estructura Completa del Skill

# Search First

## When to use
Before implementing ANY new functionality or modifying existing code.
Exceptions:
- Creating a completely new project from scratch
- Writing a one-off script with no codebase integration

## How it works

### Phase 1: Understand the request
Before searching, clarify what you're looking for:
- What is the primary entity or concept involved?
- What actions need to be performed (CRUD, transformation, validation)?
- What are the boundaries? (module, service, layer)

### Phase 2: Broad search
Search for related code using multiple strategies:

1. **Name-based search**: Search for the primary entity name

Grep: pattern=“EntityName” glob=”**/*.ts”

2. **Concept-based search**: Search for related concepts if name search is insufficient

Grep: pattern=“(authenticate|auth|login|token)” glob=”**/*.ts”

3. **Directory mapping**: Understand the structure of the relevant area

Glob: pattern=“src/auth/**/*”

### Phase 3: Deep read
For each relevant file found:
1. Read the full file if < 200 lines
2. Read relevant sections if > 200 lines
3. Note: naming conventions, error handling patterns, imports used

### Phase 4: Dependency mapping
Identify what the relevant code depends on and what depends on it:
- Upstream: what does this code call/import?
- Downstream: what calls/imports this code?

### Phase 5: Test coverage mapping
Find existing tests for the code you're about to touch:

Grep: pattern=“describe.*EntityName|test.entityName” glob=”**/.test.ts”

### Phase 6: Document findings
Before implementing, produce a brief summary:
- Existing relevant code: [list files and their purpose]
- Patterns to follow: [naming, error handling, structure]
- Tests to preserve: [list test files]
- Dependencies to be aware of: [upstream and downstream]

## Examples

### Example 1: "Add user profile update endpoint"

Search sequence:
1. `Grep "user" src/routes/` → Find user routes
2. `Read src/routes/user.ts` → Understand route patterns
3. `Grep "updateUser\|UserUpdate" src/` → Find any existing update logic
4. `Read src/services/userService.ts` → Understand service layer
5. `Grep "user" src/repositories/` → Find data access patterns
6. `Glob "src/**/*.test.ts" | Grep "user"` → Find user tests

Output: "Routes follow Express pattern with try-catch, services use Result type,
repositories use Prisma, tests use jest with supertest. No existing update logic found."

### Example 2: "Fix authentication bug"

Search sequence:
1. `Grep "authentication\|login\|auth" src/` → Map auth code
2. `Read src/middleware/auth.ts` → Current auth implementation
3. `Grep "JWT\|token\|session" src/` → Token handling
4. `Read src/config/auth.ts` → Auth configuration
5. Find and read recent auth-related tests

Output: "Auth uses JWT with RS256, tokens expire in 15min, refresh tokens in Redis.
Bug likely in middleware, test at src/__tests__/auth.test.ts."

## Edge Cases

### Large codebases (> 500 files)
Don't try to map everything. Focus on the module/package boundary of the change.
Use directory-level searches before file-level searches.

### Unfamiliar frameworks
When the codebase uses an unfamiliar framework, search for framework-specific patterns
before searching for feature-specific code. Example: in a NestJS app, understand
the module/controller/service/repository pattern before searching for "user".

### Legacy code
In legacy codebases, expect multiple implementations of the same concept.
Document all implementations found and note which one is "current" (recently modified).

## Related Skills
- `code-review`: Use after implementing to verify consistency with findings
- `test-coverage-analysis`: Use to understand existing test coverage before adding tests
- `dependency-audit`: Use when the search reveals complex dependency chains

Este nivel de detalle en un skill es lo que hace que ECC produzca resultados consistentes. El agente no está siguiendo una instrucción vaga de “investiga antes de implementar” — está siguiendo un proceso de 6 fases con ejemplos concretos y manejo de edge cases.

---

Anatomía de un Hook ECC: Lectura Técnica Profunda

Los hooks son la automatización del sistema. Veamos en detalle cómo funciona el hook de verificación post-edición, que es el más activo en una sesión típica.

Estructura del Hook en settings.json

Los hooks de Claude Code se definen en .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "node /path/to/ecc/scripts/verify-edit.js"
          }
        ]
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "node /path/to/ecc/scripts/check-dangerous-command.js"
          }
        ]
      }
    ]
  }
}

Variables de Entorno Disponibles en Hooks

Cuando un hook se activa, Claude Code provee información sobre el evento a través de variables de entorno:

Variable	Contenido	Ejemplo
CLAUDE_TOOL_NAME	Herramienta que se usó	"Edit"
CLAUDE_FILE_PATHS	Archivos afectados (separados por :)	"src/auth.ts:src/auth.test.ts"
CLAUDE_TOOL_INPUT	Input completo de la herramienta (JSON)	{"file_path": "src/auth.ts", ...}
CLAUDE_TOOL_OUTPUT	Output de la herramienta (JSON)	{"success": true}
CLAUDE_SESSION_ID	ID de la sesión actual	"sess_abc123"

El Script verify-edit.js

#!/usr/bin/env node
// scripts/verify-edit.js — Verifica archivos después de edición

const { execSync } = require('child_process');
const path = require('path');

const filePaths = (process.env.CLAUDE_FILE_PATHS || '').split(':').filter(Boolean);

if (filePaths.length === 0) {
  process.exit(0); // Nada que verificar
}

const results = [];

for (const filePath of filePaths) {
  const ext = path.extname(filePath);

  try {
    if (['.ts', '.tsx'].includes(ext)) {
      execSync(`npx tsc --noEmit --skipLibCheck ${filePath}`, { stdio: 'pipe' });
      results.push({ file: filePath, status: 'ok' });
    } else if (['.js', '.jsx', '.mjs'].includes(ext)) {
      execSync(`npx eslint --no-eslintrc -c .eslintrc.json ${filePath}`, { stdio: 'pipe' });
      results.push({ file: filePath, status: 'ok' });
    } else if (ext === '.py') {
      execSync(`python -m py_compile ${filePath}`, { stdio: 'pipe' });
      results.push({ file: filePath, status: 'ok' });
    }
    // Agregar más lenguajes según necesidad
  } catch (error) {
    results.push({
      file: filePath,
      status: 'error',
      message: error.stdout?.toString() || error.message
    });
  }
}

const errors = results.filter(r => r.status === 'error');

if (errors.length > 0) {
  console.error('Verification failed after edit:');
  for (const err of errors) {
    console.error(`  ${err.file}: ${err.message}`);
  }
  process.exit(1); // Exit code 1 hace que Claude Code muestre el error
}

process.exit(0);

Cómo Claude Code Procesa el Resultado del Hook

Cuando un hook retorna exit code 1, Claude Code:

1. Muestra el stderr del hook como un mensaje en la conversación
2. Marca la herramienta como fallida
3. El agente ve el error y puede corregirlo inmediatamente

Esto crea un loop de feedback inmediato: el agente edita → el hook detecta el error → el agente ve el error → el agente corrige → el hook confirma que está bien.

El tiempo total de este loop es de segundos, no minutos. Es la diferencia entre “detecto el error mientras edito” y “detecto el error cuando corro todos los tests al final”.

Hooks de Notificación

Además de los hooks de comando, ECC usa hooks de notificación para comunicar información al desarrollador sin interrumpir el flujo del agente:

{
  "hooks": {
    "Notification": [
      {
        "matcher": ".*",
        "hooks": [
          {
            "type": "command",
            "command": "node scripts/notify.js"
          }
        ]
      }
    ]
  }
}

Los hooks de notificación se usan para:

• Alertar cuando el agente detecta que está tomando más tiempo del esperado
• Notificar cuando se ha completado una tarea larga
• Avisar cuando el uso de tokens supera un umbral
• Informar cuando el agente necesita confirmación antes de una operación destructiva

---

Economía de Tokens: Análisis Cuantitativo

El principio de economía de tokens merece un análisis más cuantitativo para entender por qué ECC puede lograr reducciones del 60-90%.

Fuentes de Desperdicio de Tokens

Hay tres categorías principales de desperdicio:

1. Contexto innecesario (40-60% del desperdicio típico)

Un desarrollador que dice “implementa una función de autenticación” sin más contexto lleva al agente a explorar el codebase de manera expansiva — lee todos los archivos que podrían ser relevantes, incluyendo muchos que no lo son. En un proyecto de 200 archivos, esto puede resultar en 50,000-100,000 tokens solo en exploración.

Con ECC, el skill search-first estructura la exploración de manera eficiente. La misma tarea toma 15,000-25,000 tokens en exploración.

2. Iteraciones de corrección (20-30% del desperdicio típico)

Sin verificación continua, los errores se acumulan y se descubren al final. Corrección de errores al final de la sesión: el agente necesita re-leer el contexto, entender el error, re-leer el código relevante, y corregir. Esto puede tomar 20,000-40,000 tokens por ciclo de corrección.

Con los hooks de verificación, los errores se detectan y corrigen inmediatamente. El costo por corrección: 2,000-5,000 tokens (el agente ya tiene el contexto en ventana).

3. Modelo incorrecto para la tarea (10-30% del desperdicio típico)

Usar Opus para una tarea que Haiku puede hacer no solo cuesta más por token — Opus también tiende a generar respuestas más largas y elaboradas, multiplicando el costo.

Ejemplo concreto:

• Tarea: “¿Qué archivos contienen la lógica de autenticación?”
• Haiku: 500 tokens de input + 300 tokens de output = 800 tokens
• Opus: 500 tokens de input + 800 tokens de output = 1,300 tokens (Opus elabora más)
• Costo Haiku: ~$0.001
• Costo Opus: ~$0.02
• Factor: 20x más caro para el mismo resultado

RTK: Rust Token Killer

RTK es una herramienta complementaria que actúa como proxy entre Claude Code y el sistema operativo. Su función es filtrar el output de comandos antes de que llegue al contexto del agente.

El problema que resuelve: muchos comandos producen output verboso que el agente no necesita completamente. Un git diff en un repositorio grande puede producir 50,000 caracteres de output, de los cuales el agente necesita quizás 5,000 para responder la pregunta.

RTK filtra:

• Líneas de output repetitivas (como stacktraces muy largos)
• Secciones de archivos no modificadas en diffs
• Metadata de herramientas que el agente no necesita ver
• Output de comandos de instalación de dependencias

El ahorro de RTK varía mucho según el tipo de trabajo:

• Trabajo con git: 40-70% de reducción de output
• Trabajo con build tools: 50-80% de reducción
• Trabajo con tests verbosos: 30-60% de reducción
• Trabajo con análisis de archivos: 10-30% de reducción

Cálculo de ROI de ECC

Con datos concretos, el ROI de ECC se puede estimar:

Antes de ECC (sesión típica de 4 horas):

• Exploración: 80,000 tokens
• Implementación: 60,000 tokens
• Correcciones: 40,000 tokens
• Total: 180,000 tokens
• Costo (con Sonnet): ~$0.54

Con ECC (misma sesión):

• Exploración (search-first): 25,000 tokens
• Implementación (con contexto): 45,000 tokens
• Correcciones (verificación continua): 8,000 tokens
• Total: 78,000 tokens
• Costo (con selección de modelos): ~$0.18

Reducción: 57% en tokens, 67% en costo (porque la selección de modelos mueve algunas tareas a Haiku).

Para un desarrollador que hace 4 horas de trabajo con Claude Code por día:

• Sin ECC: ~$150/mes en tokens
• Con ECC: ~$50/mes en tokens
• Ahorro mensual: ~$100

En un año, el ahorro monetario (~$1,200) supera con creces el tiempo de setup de ECC (~8-16 horas de inversión inicial).

---

La Historia de los Instincts: Caso de Uso Real

El sistema de instincts es quizás el componente más diferenciador de ECC. Vale la pena explicarlo a través de un caso de uso real y detallado.

El Problema que Motiva los Instincts

Imaginá un proyecto donde el sistema de autenticación usa JWTs con una peculiaridad: el campo sub del JWT no es el ID del usuario en la base de datos, sino un identificador compuesto con el formato {tenantId}:{userId}. Esta es una decisión de diseño específica de este proyecto que ningun agente puede saber de antemano.

Sin instincts, en cada sesión que involucra autenticación, el agente comete el mismo error: trata el sub como un ID de usuario simple. El desarrollador corrige el error. La siguiente sesión, el mismo error.

El Ciclo de Instinct para este Problema

Sesión 1 (sin instincts):

1. Desarrollador pide implementar un endpoint que devuelve el perfil del usuario autenticado
2. Agente lee el JWT, extrae req.user.sub, lo usa como ID para consultar la base de datos
3. La consulta falla porque sub es "tenant123:user456", no un ID simple
4. Desarrollador explica el formato compuesto
5. Agente corrige, parsea el sub, extrae el userId
6. Implementación correcta

Extracción del instinct (post-sesión): El hook PostTask analiza la sesión y detecta que hubo un error sobre el formato del campo sub en el JWT que fue corregido. Genera un instinct candidato:

Contexto: Al trabajar con autenticación y el usuario actual
Observación: El campo 'sub' del JWT no es un ID de usuario simple.
             Formato: '{tenantId}:{userId}' (ej: 'tenant123:user456')
Acción: Siempre parsear el sub: const [tenantId, userId] = req.user.sub.split(':')
        Nunca usar req.user.sub directamente como userId en queries de DB
Evidencia: Error en sesión 2025-01-15, archivo src/routes/user.ts línea 23

El desarrollador revisa el instinct y lo aprueba — es una observación válida y generalizable.

Sesión 2 (con instinct):

1. El hook de inicio de sesión inyecta el instinct en el contexto
2. Desarrollador pide implementar otro endpoint con usuario autenticado
3. Agente lee el instinct, entiende el formato especial del sub
4. Implementación correcta desde el primer intento
5. No hay error, no hay corrección, no hay tokens desperdiciados en el ciclo de corrección

La Evolución de los Instincts

Los instincts no son estáticos. Con el tiempo, se pueden refinar:

Versión 1 del instinct (detectado automáticamente):

El sub del JWT tiene formato especial: tenantId:userId

Versión 2 (después de más experiencia):

El sub del JWT tiene formato {tenantId}:{userId}.
Existe un helper: src/utils/auth.ts#parseJwtSub(sub) que hace el parsing.
Usarlo siempre en lugar de hacer el split manualmente.
También: los JWTs de usuarios admin tienen solo userId (sin tenantId), manejar el caso.

Versión 3 (después de descubrir más edge cases):

JWTs en este proyecto:
- Usuarios normales: sub = "{tenantId}:{userId}" (ej: "t123:u456")
- Usuarios admin: sub = "admin:{userId}" (ej: "admin:u789")
- Service accounts: sub = "svc:{serviceId}" (ej: "svc:billing")

Helper: src/utils/auth.ts#parseJwtSub(sub) retorna { type, tenantId?, userId?, serviceId? }
Tests: src/__tests__/utils/auth.test.ts — tiene casos para los tres tipos

Nota: La doc dice que tenantId puede contener ":" pero en la práctica nunca ocurre.
Si se implementa soporte multi-tenant completo, revisar este supuesto.

Esta evolución es el aprendizaje continuo en acción. El instinct de la versión 3 tiene más información, mejor estructura, y documenta incluso deudas técnicas potenciales.

Instincts a Nivel de Codebase

Además de los instincts específicos como el del JWT, ECC acumula instincts de más alto nivel sobre el codebase en general:

# Instincts de Arquitectura

El proyecto usa Clean Architecture con estas capas estrictas:
- routes/ → controllers/ → services/ → repositories/ → database/
NUNCA saltear capas. Un controller no puede importar directamente de repositories/.
Si ves un import cross-layer, es un bug a reportar, no un patrón a seguir.

# Instincts de Testing

Los tests de integración en este proyecto requieren que la DB de test esté limpia.
Usar beforeEach(() => db.truncate()) en tests que modifican datos.
Los tests en /unit/ son unitarios puros con mocks.
Los tests en /integration/ usan la DB real de test.
NUNCA mockear la DB en tests de integration/ — ese es el punto de los integration tests.

# Instincts de Performance

Las queries sobre la tabla `events` son lentas con más de 10,000 registros.
Siempre agregar LIMIT a queries sobre events si no hay necesidad de todos los registros.
El índice compuesto (tenantId, createdAt) existe pero solo aplica si la query usa ambas columnas.

Con el tiempo, esta base de instincts se convierte en una documentación viva del proyecto — más actualizada que la documentación formal porque se actualiza en tiempo real conforme se trabaja.

---

Patrones de Paralelización Avanzada

La paralelización con git worktrees es uno de los superpoderes de ECC. Merece una explicación detallada porque la mayoría de los desarrolladores no están familiarizados con git worktrees.

¿Qué son los Git Worktrees?

Un git worktree es un directorio de trabajo adicional conectado al mismo repositorio git. A diferencia de un clone, los worktrees comparten el mismo historial de git, pero cada uno tiene su propio working directory y puede estar en una rama diferente.

# Repositorio principal
/projects/myapp/          # Worktree principal (main branch)

# Worktrees adicionales
/projects/myapp-feature-auth/    # Worktree para feature/auth branch
/projects/myapp-bugfix-db/       # Worktree para bugfix/db-connection

Cada worktree es completamente independiente — puedes editar archivos en uno sin que afecte los otros. Y lo más importante para ECC: puedes tener múltiples instancias de Claude Code trabajando simultáneamente en diferentes worktrees.

El Flujo de Paralelización con ECC

sequenceDiagram
    participant Dev as Desarrollador
    participant Orq as Agente Orquestador
    participant A1 as Agente 1 (Worktree 1)
    participant A2 as Agente 2 (Worktree 2)
    participant Git as Git Repository

    Dev->>Orq: "Implementar autenticación OAuth y sistema de notificaciones"
    Orq->>Orq: Analiza dependencias entre tareas
    Orq->>Dev: "Estas tareas son independientes, las paralelizo"
    Dev->>Orq: Confirma

    Orq->>Git: git worktree add /tmp/auth feature/auth
    Orq->>Git: git worktree add /tmp/notifications feature/notifications

    par Trabajo paralelo
        Orq->>A1: Trabajá en /tmp/auth — implementar OAuth
        Orq->>A2: Trabajá en /tmp/notifications — implementar notificaciones
    end

    A1->>Git: git commit "feat: implement OAuth"
    A2->>Git: git commit "feat: implement notifications"

    Orq->>Dev: "Ambas features completadas, revisá los PRs"
    Orq->>Git: Cleanup worktrees

Cuándo Paralelizar y Cuándo No

ECC tiene criterios específicos para decidir si paralelizar:

Paralelizar cuando:

• Las tareas no modifican los mismos archivos
• Las tareas no tienen dependencias de datos entre sí (una no necesita que la otra esté lista)
• El overhead de coordinación es menor al ahorro de tiempo por paralelización
• Tenés suficiente capacidad de API (no estás cerca de los rate limits)

No paralelizar cuando:

• Las tareas modifican archivos compartidos (inevitable conflicto de merge)
• Una tarea depende del output de otra
• Las tareas son cortas (< 15 min) — el overhead de setup de worktrees no vale la pena
• El codebase tiene acoplamiento alto — las tareas que parecen independientes podrían no serlo

El Plan de Paralelización

Antes de lanzar agentes paralelos, ECC requiere un plan explícito que defina:

Boundaries: Qué archivos y directorios “pertenecen” a cada agente. Si un agente modifica un archivo fuera de su boundary, se detiene y consulta.

## Plan de Paralelización

### Agente 1 (feature/oauth)
Boundary: src/auth/, src/middleware/auth*, tests/auth/
Tarea: Implementar OAuth con Google y GitHub
No tocar: src/routes/, src/services/ (excepto authService)

### Agente 2 (feature/notifications)
Boundary: src/notifications/, src/jobs/notification*, tests/notifications/
Tarea: Implementar sistema de notificaciones por email y push
No tocar: src/auth/, src/middleware/

### Shared files (coordinar cambios)
- src/config/index.ts (agregar config de OAuth Y de notificaciones)
- src/types/user.ts (posibles campos nuevos en User type)
- package.json (dependencias nuevas)

Protocolo para shared files:
1. Agente 1 modifica los shared files para OAuth
2. Agente 2 hace cherry-pick de esos commits y agrega sus cambios encima
3. Merge en main con revisión manual de conflictos en shared files

Este nivel de planificación previene la mayoría de los problemas de paralelización. Los conflicts que ocurren son predecibles y manejables.

---

Spec-Driven Development (SDD) Integrado con ECC

SDD es el workflow de más alto nivel en ECC. Es el proceso completo desde la idea hasta el código verificado y archivado. Merece una explicación detallada porque es lo que más diferencia el trabajo serio con ECC del uso ad-hoc de Claude Code.

¿Qué es SDD?

Spec-Driven Development es la práctica de crear especificaciones completas antes de implementar. No porque la especificación sea perfecta, sino porque el proceso de escribirla revela ambigüedades, conflictos, y supuestos implícitos que serían mucho más costosos de descubrir durante la implementación.

En el contexto de ECC, SDD está automatizado a través del sistema de commands y agentes. El desarrollador propone un change, y ECC orquesta la creación de todos los artefactos necesarios.

Los Artefactos de SDD

Cada change en SDD produce un conjunto de artefactos ordenados en una cadena de dependencias:

graph LR
    P[proposal.md] --> S[spec.md]
    S --> D[design.md]
    D --> T[tasks.md]
    T --> A[apply]
    A --> V[verify]
    V --> AR[archive]

proposal.md: El documento inicial que responde “¿qué queremos cambiar y por qué?”. Incluye el problema, la solución propuesta, el impacto esperado, y los trade-offs. No tiene código — es un documento de alineación.

spec.md: Los requerimientos funcionales y no funcionales del change. Define los criterios de aceptación de manera testeable: “dado X, cuando Y, entonces Z”. Este documento es la fuente de verdad para verificación.

design.md: Las decisiones técnicas de implementación. Qué se crea, qué se modifica, qué se elimina. Los diagramas de secuencia, los esquemas de datos, las interfaces públicas. Este documento es lo que el agente de implementación lee antes de escribir código.

tasks.md: La lista de tareas atómicas ordenadas por dependencias. Cada tarea es lo suficientemente pequeña para ser implementada en una sesión (< 2 horas) y lo suficientemente bien definida para que no haya ambigüedad sobre cuándo está completa.

apply: La implementación real, guiada por tasks.md y diseñada según design.md.

verify: La verificación sistemática contra spec.md. No es “¿pasa los tests?” sino “¿cumple todos los criterios de aceptación del spec?”.

archive: El cierre formal del change con documentación de lo que se aprendió.

El Flujo SDD en Práctica

# 1. Iniciar un nuevo change
/sdd-new "implementar sistema de rate limiting por IP y por usuario"

# ECC crea automáticamente:
# openspec/changes/rate-limiting/proposal.md

# 2. Revisar y aprobar la propuesta
# El desarrollador revisa proposal.md y hace ajustes si es necesario

# 3. Generar el resto de los artefactos (si la propuesta está bien)
/sdd-ff rate-limiting

# ECC crea secuencialmente:
# openspec/changes/rate-limiting/spec.md
# openspec/changes/rate-limiting/design.md
# openspec/changes/rate-limiting/tasks.md

# 4. Implementar (tarea por tarea)
/sdd-apply rate-limiting

# 5. Verificar
/sdd-verify rate-limiting

# 6. Archivar
/sdd-archive rate-limiting

¿Por Qué SDD Funciona Mejor con Agentes de IA?

Hay una razón profunda por la que SDD es especialmente valioso con agentes de IA, más allá de las razones generales que aplican a cualquier proceso de desarrollo.

Los agentes de IA son muy buenos en seguir especificaciones claras y muy malos en inferir especificaciones implícitas. Un desarrollador humano puede trabajar con requerimientos ambiguos porque tiene contexto de negocio, puede hacer preguntas, y puede ejercer juicio. Un agente de IA en situaciones ambiguas hace supuestos — y los supuestos incorrectos se propagan a través de toda la implementación.

SDD elimina la ambigüedad antes de la implementación. Cuando el agente de implementación recibe tasks.md con tareas bien definidas y design.md con las decisiones técnicas ya tomadas, el espacio de error es mínimo. El agente no necesita inferir nada — todo está especificado.

El resultado es implementaciones que son correctas en el primer intento con una frecuencia significativamente mayor. Lo que se traduce directamente en menos tokens gastados en correcciones.

---

Configuración Avanzada: El CLAUDE.md del Proyecto

El CLAUDE.md del proyecto es el punto de entrada de ECC para cada sesión. Un CLAUDE.md bien diseñado es la diferencia entre un agente que empieza “frío” (sin contexto del proyecto) y uno que empieza “caliente” (con el contexto correcto).

Estructura del CLAUDE.md Óptimo

Un CLAUDE.md óptimo para ECC tiene estas secciones, en este orden:

1. Project Overview (conciso) No más de 5 líneas. El agente necesita saber qué es el proyecto, no leer un README completo.

# Project: PayFlow API
Backend API for payment processing. Node.js + TypeScript + PostgreSQL.
Handles payment intents, subscriptions, and invoicing for SaaS products.
Critical: PCI-DSS compliance required. Never log payment data.

2. Architecture Rules (invariantes) Las reglas de arquitectura que no tienen excepciones.

# Architecture
- Hexagonal architecture: domain/ → application/ → infrastructure/
- NEVER import from infrastructure/ in domain/ or application/
- All external services accessed through ports (interfaces) in application/ports/
- Database access ONLY through repositories in infrastructure/repositories/

3. Technology Stack and Conventions Las convenciones específicas del proyecto.

# Stack
- TypeScript strict mode (no any, no as any)
- Express with async/await (no callbacks)
- Prisma ORM — never write raw SQL unless absolutely necessary
- Jest for tests — integration tests in /tests/integration/, unit in /tests/unit/
- Zod for validation at API boundary only

4. Critical Do-Nots Los errores que se han cometido antes y deben evitarse.

# Never Do This
- Never use console.log in production code → use logger from src/lib/logger.ts
- Never hardcode URLs → use config from src/config/index.ts
- Never throw errors from repositories → return Result<T, Error>
- Never bypass auth middleware → check auth in router, not in controller
- Never modify migrations already applied → create new migration instead

5. ECC Integration

# ECC Configuration
Using Everything Claude Code. Key settings:
- SDD enabled for features > 2 days of work
- Always run search-first before implementing
- Use security-agent for any auth/payment code
- Instincts location: .claude/memory/instincts.md

6. Current State (dinámico) Esta sección se actualiza con el estado actual del proyecto.

# Current State (updated: 2025-01-20)
Active changes:
- feature/oauth (75% complete, see openspec/changes/oauth/)
- bugfix/subscription-renewal (pending review)

Known issues:
- Performance regression in /events endpoint (ticket #234)
- Tests flaky in tests/integration/webhooks.test.ts (race condition, ticket #235)

Automatización del CLAUDE.md

ECC puede actualizar automáticamente la sección “Current State” del CLAUDE.md al final de cada sesión. El hook PostTask extrae el estado del proyecto y actualiza el archivo.

// scripts/update-project-state.js
const fs = require('fs');
const { execSync } = require('child_process');

// Leer changes activos desde openspec/
const changesDir = 'openspec/changes';
const activeChanges = fs.readdirSync(changesDir)
  .filter(dir => {
    const state = JSON.parse(fs.readFileSync(`${changesDir}/${dir}/state.json`, 'utf8'));
    return state.status !== 'archived';
  })
  .map(dir => {
    const state = JSON.parse(fs.readFileSync(`${changesDir}/${dir}/state.json`, 'utf8'));
    return `- ${dir} (${state.completion}% complete, status: ${state.status})`;
  });

// Leer issues conocidos del tracker local
const knownIssues = JSON.parse(fs.readFileSync('.claude/known-issues.json', 'utf8'));

// Actualizar la sección Current State del CLAUDE.md
const claudeMd = fs.readFileSync('CLAUDE.md', 'utf8');
const updated = claudeMd.replace(
  /# Current State[\s\S]*?(?=\n#|$)/,
  `# Current State (updated: ${new Date().toISOString().split('T')[0]})\n` +
  `Active changes:\n${activeChanges.join('\n')}\n\n` +
  `Known issues:\n${knownIssues.map(i => `- ${i.description} (ticket #${i.id})`).join('\n')}\n`
);
fs.writeFileSync('CLAUDE.md', updated);

Esto asegura que el CLAUDE.md siempre tiene información actualizada, sin requerir que el desarrollador lo actualice manualmente.

---

Integración con Herramientas Externas via MCP

El Model Context Protocol (MCP) extiende el alcance de Claude Code más allá del filesystem local. ECC incluye configuraciones probadas para los MCPs más útiles en desarrollo profesional.

GitHub MCP: Trabajando con Issues y PRs

El GitHub MCP permite que Claude Code acceda a la API de GitHub sin salir del contexto de la sesión.

Casos de uso en ECC:

• Leer el issue antes de empezar a trabajar en él (para entender el contexto completo)
• Crear el PR con descripción generada automáticamente desde los commits
• Revisar comentarios de PR directamente en la sesión
• Verificar el estado de CI antes de hacer merge

Configuración en .claude/mcp-configs/github.json:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Con el GitHub MCP activo, el command /review-pr 123 puede acceder directamente al PR, sus diff, y sus comentarios existentes sin que el desarrollador tenga que copiar y pegar manualmente.

Context7 MCP: Documentación en el Contexto

Context7 es un MCP que provee documentación actualizada de librerías directamente en el contexto de Claude Code. En lugar de que el agente dependa de su conocimiento de entrenamiento sobre una librería (que puede estar desactualizado), consulta la documentación actual.

Casos de uso:

• “¿Cómo se configura Prisma con PostgreSQL con connection pooling?” → Context7 consulta la doc actual de Prisma
• “¿Cuál es la API correcta de React 19 para suspense?” → Context7 consulta la doc de React 19
• “¿Cuáles son las opciones de configuración de Zod v3?” → Context7 consulta la doc de Zod

La reducción de errores por APIs desactualizadas o mal recordadas es significativa, especialmente en proyectos que usan versiones recientes de librerías que pueden no estar en el training data del modelo.

---

Resumen y Checklist

Este capítulo cubrió los fundamentos de Everything Claude Code: qué es, por qué existe, sus principios fundamentales, y cómo funciona en términos de arquitectura.

Puntos Clave

ECC es infraestructura, no una herramienta: La distinción más importante. Como infraestructura, requiere inversión inicial y mejora con el tiempo.

Los 4 principios son restricciones de diseño, no sugerencias: Research-before-code, verificación continua, economía de tokens, y aprendizaje persistente — violar cualquiera de estos principios reduce el valor del sistema.

El sistema de capas es la clave conceptual: Las 5 capas (infraestructura, convenciones, automatización, especialización, workflows) se construyen una sobre la otra. La adopción por capas es la estrategia más efectiva.

El efecto compuesto es el argumento económico: Los componentes individuales tienen valor, pero el valor del sistema completo es exponencialmente mayor que la suma de las partes.

La compatibilidad cross-platform es pragmática: Claude Code es el target principal, pero el sistema funciona en Cursor, OpenCode, y Codex CLI con diferentes niveles de fidelidad.

Checklist del Capítulo

Antes de avanzar al Capítulo 2, verificá que podés responder estas preguntas:

• ¿Puedo explicar la diferencia entre ECC y un CLAUDE.md bien escrito?
• ¿Entiendo los 5 problemas que ECC resuelve y cuál es el más relevante para mi caso?
• ¿Puedo nombrar los 4 principios fundamentales y dar un ejemplo de cada uno?
• ¿Entiendo el propósito de cada directorio de la arquitectura de ECC?
• ¿Conozco la diferencia entre un agent, un skill, y un command?
• ¿Entiendo por qué los hooks son importantes y cómo funcionan?
• ¿Puedo aplicar la tabla de selección de modelos a mis tareas más comunes?
• ¿Hice al menos uno de los 5 ejercicios prácticos?
• ¿Identifiqué cuál capa de ECC debería adoptar primero en mi contexto?

Preview del Capítulo 2

El Capítulo 2 se enfoca en la instalación y configuración inicial de ECC. Cubrirá el proceso de instalación paso a paso, la estructura de directorios en detalle, la configuración del CLAUDE.md del proyecto, los primeros hooks que debés activar, y cómo verificar que todo funciona correctamente.

El Capítulo 2 es más técnico que este — habrá comandos concretos, archivos de configuración reales, y verificaciones específicas. Se recomienda tener el repositorio de ECC clonado antes de empezar a leerlo.

---

Este capítulo forma parte del tutorial completo de Everything Claude Code. Los siguientes capítulos profundizan en cada componente y workflow con nivel técnico progresivo.

El objetivo de ECC no es hacer que el agente sea inteligente — ya lo es. El objetivo es hacer que esa inteligencia sea consistente, eficiente, y acumulable. Esa es la diferencia entre una herramienta poderosa usada de manera ad-hoc y una infraestructura de desarrollo que mejora con el tiempo.