ECC é um sistema de engenharia open source para agentes de código: instala um fluxo fixo de planejar → testar → implementar → revisar → verificar no Claude Code, Codex, Cursor e em mais uma dezena de harnesses. Em vez de reconstruir esse processo em cada prompt, você o instala uma vez e passa a ser parte de como seu agente funciona.
Nota de 18 de setembro de 2026. Este artigo substitui nossa versão de maio de 2026. Três coisas nela estavam erradas ou haviam caducado: o repositório mudou de nome de
everything-claude-codeparaECC, a versão e as contagens de componentes avançaram dois releases, e atribuímos a origem do ECC a um hackathon. Esse último ponto foi um erro nosso, corrigido abaixo.
Cobri esse projeto duas vezes este ano e as duas vezes subestimei em que estava se tornando. Em maio parecia um plugin bem construído com um scanner de segurança interessante acoplado. Hoje tem 262K estrelas, 39.2K forks e —mais importante para qualquer um que esteja tomando uma decisão de adoção— deixou de ser um plugin do Claude Code.
A mudança de nome é o sinal.
O que é ECC e por que mudou de nome?
O projeto se chamava Everything Claude Code. Hoje é simplesmente ECC e o repositório vive em affaan-m/ECC. Isso não é cosmético. Uma ferramenta que leva o nome do produto de um único provedor não pode se posicionar com credibilidade como a camada de portabilidade entre sete deles.
Agora há três identificadores públicos, e o README é explícito em que não são intercambiáveis:
| O quê | Identificador |
|---|---|
| Repositório no GitHub | affaan-m/ECC |
| Plugin do Claude Code | ecc@ecc |
| Pacote npm | ecc-universal |
O identificador do plugin é curto propositalmente: nomes longos de marketplace superam os validadores de comprimento de alguns clientes Desktop e de API. O README chama o antigo identificador longo de „apenas um alias herdado‟, o que significa que qualquer instrução de instalação que você tenha salvo no início deste ano —incluindo a nossa de maio— aponta para o nome errado.
O release atual é o 2.2.1, publicado no npm em 8 de setembro de 2026. Licença MIT, e o README se compromete a mantê-la de forma permanente.
O que ECC inclui quando você o instala?
| Componente | Quantidade | O que faz |
|---|---|---|
| Agentes | 68 | Planejamento, revisão, reparo de builds, segurança, arquitetura, revisão por linguagem |
| Skills | 292 | TDD, investigação, segurança, docs, frontend, dados, ML, operações |
| Comandos | 94 | Shims de slash commands, mantidos como compatibilidade na migração para skills |
| Hooks e memória | Runtime | Enforcement, resumos de sessão, aprendizado contínuo, controle de contexto |
| Regras | Seletivas | Padrões sempre carregados que você escolhe por linguagem |
| AgentShield | Incluído | Escaneia prompts, hooks, config de MCP, permissões, secrets e arquivos de agentes |
Nosso artigo de maio dizia 28 agentes. A direção do movimento é óbvia, e também é a primeira coisa que eu questionaria: 292 skills é muita superfície para auditar. O próprio README o concede. O plugin do Claude Code „o anuncia ao modelo o catálogo instalado‟, assim a documentação recomenda um perfil seletivo quando o footprint de contexto importa. É algo inusitadamente honesto para que um projeto escreva sobre sua própria via de instalação principal.
Para que servem os 68 subagentes do Claude Code?
A decisão arquitetônica que me parece mais defensável é que as skills, não os comandos, são agora a superfície principal. Os comandos ficam como shims; os retirados foram movidos para um diretório legacy-command-shims/ ao qual você precisa optar explicitamente. É deprecação com rota de migração, não um rename que quebra tudo.
Os 68 agentes estão especializados por função e por linguagem: planejamento, arquitetura, guia de TDD, revisão de código, revisão de segurança, resolução de erros de build, e revisores dedicados para TypeScript, Python, Go, Rust, Java, Kotlin, C++, F# e ArkTS, entre outros.
O valor real de um subagente não é que saiba mais. É que funciona com seu próprio contexto e suas próprias permissões de ferramentas. O revisor de código não vê o raciocínio com o qual esse código foi escrito, e por isso encontra coisas que o contexto original não consegue ver. Isolar planejamento, implementação e revisão em contextos separados é o mecanismo, e a contagem de agentes é apenas a consequência.
Quais harnesses o projeto suporta de verdade?
Aqui o projeto ganha a credibilidade, porque publica uma matriz de capacidades que admite onde não funciona:
| Harness | Status |
|---|---|
| Claude Code | Estável, primário |
| Codex | Plugin nativo suportado |
| Cursor | Adaptador de projeto em beta |
| OpenCode | Plugin compilado em beta |
| GitHub Copilot | Apenas instruções: sem hooks, sem agentes, sem delegação |
| Gemini, Zed, Antigravity, Qwen, Hermes, OpenClaw, Kimi, CodeBuddy, JoyCode | Adaptadores experimentais ou mínimos |
O enquadramento do próprio README: você deve tratar essas etiquetas „como declarações de capacidade, não como níveis de marketing‟. O suporte para Copilot significa um arquivo de instruções versionado e cinco arquivos de prompt, e a documentação o diz sem rodeios: Copilot não tem sistema de hooks nem API de subagentes, assim a camada de automação simplesmente não existe.
Compare isso com como a maioria das ferramentas multiplataforma é comercializada e você entende por que mais de 113 contributors continuam aparecendo.
Por que a memória entre harnesses importa mais que o número de agentes?
Porque é o problema real que os times têm em 2026, e quase ninguém está resolvendo.
Se seu time usa Claude Code e Codex e Cursor —como faz hoje a maioria—, o contexto acumulado de seu agente fica preso por ferramenta. Cada mudança começa do zero. A resposta do ECC é o Memory Vault: documentos markdown portáveis sob .ecc/memory/ para escopo de projeto e time, e ~/.ecc/memory/ para escopo de usuário, legíveis por Claude, Codex, Hermes, OpenClaw e Kimi através de um único formato.
Duas ressalvas que importam, ambas da documentação do projeto. O runtime não fica no PATH com as instalações de plugin, mínima ou manual: o pacote npm se instala separadamente. E o limite de confiança está declarado sem ambiguidade: a memória é „contexto não revisado, não política executável‟. As entradas recuperadas nunca devem ser tratadas como instruções.
Para qualquer um que tenha pensado em prompt injection através de um armazenamento de contexto compartilhado, esse é o padrão correto. E é o oposto do que diria um provedor que tenta vender a você uma função de memória.## Quanto contexto consome e o que você deveria desativar?
O guia do próprio ECC é o mais útil do repositório para um líder técnico, e contradiz o instinto maximalista que o número de estrelas convida.
Configuração recomendada para ~/.claude/settings.json, segundo o guia de otimização de tokens do projeto:
{
"model": "sonnet",
"env": {
"MAX_THINKING_TOKENS": "10000",
"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50",
"CLAUDE_CODE_SUBAGENT_MODEL": "haiku"
}
}
E a restrição que eu colocaria na frente de cada engenheiro de um time que adote isto: não habilite todos os servidores MCP de uma vez. As descrições de ferramentas de cada servidor consomem sua janela de contexto antes de você escrever qualquer coisa. Os limites que o projeto declara são menos de 10 servidores MCP por projeto e menos de 80 ferramentas ativas.
ECC pratica isso consigo mesmo. Envia exatamente um conector MCP por padrão, chrome-devtools. Uma auditoria de junho de 2026 removeu os seis anteriores. Um projeto que elimina seus próprios padrões para proteger seu orçamento de contexto está fazendo um argumento de design, não de marketing.
Que riscos existem antes de adotar em equipe?
Quatro, colocados com honestidade.
Um único mantenedor. ECC publica a cada semana para sete ambientes de teste sobre o trabalho de uma pessoa, financiado por patrocinadores e um GitHub App pago (ECC Pro, repositórios privados a partir de 19 dólares por assento ao mês; o repositório OSS continua MIT). É um throughput notável e uma dependência concentrada.
Empilhar instalações quebra coisas. Instalar o plugin e depois executar o instalador manual duplica skills, comandos e hooks, e faz com que os hooks sejam executados duas vezes. O repositório tem um histórico documentado de exatamente este problema. Escolha um único caminho por ambiente de teste.
Windows não está no mesmo nível. O CLI principal funciona em Windows, macOS e Linux, mas o daemon observador de continuous-learning v2 e as escrituras do memory vault têm bugs abertos no Windows nativo, e várias funcionalidades apoiadas em shell precisam de Git Bash ou WSL.
Parte do roadmap não foi entregue. O cliente de computação de Itô está explicitamente não publicado — você o compila localmente — e a inferência gerenciada através dele não está ativa. No momento da publicação desta nota, você precisa ler as declarações de capacidade, não a lista de features.
Também vale etiquetar: os 1.282 testes, a cobertura de 98% e as 102 regras de análise estática do AgentShield são números informados pelo próprio projeto, não auditados independentemente. São plausíveis e surpreendentemente específicos. Continuam sendo autoinformados.
Nossa correção sobre a origem
Nosso artigo de maio se intitulava “De Hackathon para 197K Estrelas”. Esse enquadramento estava errado, e vale corrigi-lo com precisão em vez de em silêncio.
AgentShield — o componente de scanner de segurança — foi construído no Claude Code Hackathon de Cerebral Valley × Anthropic, em fevereiro de 2026. Separadamente, o mantenedor venceu um hackathon de Anthropic × Forum Ventures em setembro de 2025 e construiu zenith.chat com fluxos agênticos. Esse é seu trajeto, não a história de origem do ECC. O README não atribui ECC a um hackathon, e nós também não deveríamos ter feito.
Se você chegou procurando a parte de segurança, cobrimos em detalhes aqui: Everything Claude Code (ECC): O Scanner que Audita sua Configuração de IA Antes que um Atacante Faça. Observe que os comandos de instalação daquele artigo são anteriores à mudança de nome.
Minha leitura: isto já é infraestrutura, não ferramenta
Em maio argumentei que ECC estava se tornando o .editorconfig do comportamento de agentes: um arquivo em que ninguém pensa e que todo projeto assume estar presente. Continuo acreditando que a forma daquele argumento estava correta, e quero ser específico sobre qual parte entendi mal.
Eu a coloquei como um padrão para o comportamento dos agentes. O que os últimos quatro meses mostram é que a camada durável não é o comportamento, é a portabilidade. As regras e a aplicação de TDD são valiosas, mas também são a parte que qualquer time poderia escrever por conta própria em uma semana. O que um time não consegue construir facilmente é uma definição única de seu processo de engenharia que sobreviva a uma mudança de Claude Code para Codex, mais um armazenamento de contexto que viaje com ela.
Essa é a aposta que a mudança de nome faz, e é por isso que hoje avaliaria ECC de forma diferente de como fiz em maio. A pergunta não é “deveríamos adotar ECC”. É mais restrita e mais útil: quanto da nossa configuração de agentes queremos que seja portável entre provedores, e o quanto estamos dispostos a pagar em orçamento de contexto por isso?
A resposta provavelmente não é o catálogo completo de 292 skills. A instalação seletiva existe precisamente porque o mantenedor sabe disso.
Seu time já chegou ao ponto em que o contexto do agente preso em uma única ferramenta se tornou um custo real? Esse é o problema para o qual ECC agora aponta, e tenho curiosidade em saber se ele aterrissa.