Everything Claude Code: a história do ECC e o que vale aprender com ele

O hackathon ajuda a explicar por que o ECC chamou atenção. O aprendizado mais durável, porém, está na tentativa de transformar bons hábitos em um sistema pequeno, explícito e verificável para trabalhar com agentes.

Tudo começou com uma história curiosa

Nos últimos dias, comecei a ver o mesmo repositório aparecer em vários lugares. GitHub, X, LinkedIn, vídeos e discussões entre desenvolvedores repetiam o nome Everything Claude Code, hoje apresentado também como ECC.

Minha primeira impressão foi simples: deve ser mais um repositório enorme de prompts. Só que, quando comecei a pesquisar para gravar um vídeo sobre ele, encontrei uma história mais interessante.

Ela envolvia um hackathon organizado pela Forum Ventures com a Anthropic, um produto construído sob pressão e uma forma de trabalhar com Claude Code que depois foi organizada e expandida em público. Foi essa história que virou a primeira parte do vídeo.

Depois de gravar, a pergunta que ficou comigo foi outra: o que realmente vale aprender com esse repositório quando a curiosidade inicial passa?

O que aconteceu no hackathon

Em setembro de 2025, a Forum Ventures promoveu em Nova York um hackathon de agentes de IA com participação da Anthropic. A proposta divulgada pela organização era reunir mais de 75 participantes técnicos para sair de uma ideia a uma demonstração funcional em dez horas.

Affaan Mustafa e David Rodriguez participaram como equipe. Segundo o relato publicado por David, eles ficaram em primeiro lugar entre 22 equipes com um produto chamado PMF Probe, que hoje aparece como Zenith.

A ideia era ajudar fundadores na descoberta de clientes: a pessoa apresentava um produto, conversava com personas sintéticas e depois confrontava aquelas hipóteses com sinais de usuários reais. A página atual do Zenith mostra uma plataforma full stack com Next.js, FastAPI, Supabase, Claude, Google Cloud Run e fallback com Gemini.

O produto premiado foi PMF Probe, hoje Zenith. O repositório ECC atual veio depois e cresceu muito além daquele ambiente. O hackathon contextualiza o modo de trabalho; ele não torna todo o repositório atual o projeto vencedor da competição.

Da experiência individual para um sistema público

O que mais me chamou atenção não foi apenas a vitória. Foi descobrir que Affaan resolveu organizar e publicar grande parte do ambiente que vinha construindo para trabalhar com Claude Code.

Quando você abre o repositório, encontra agentes especializados, skills, rules, hooks, comandos, memória, configurações MCP, scripts, testes, documentação e adaptadores para diferentes ferramentas.

É daí que vem a comparação com um “sistema operacional” para agentes. Eu entendo a metáfora, mas prefiro uma descrição mais precisa: o ECC funciona como uma camada operacional e uma biblioteca de decisões para organizar como agentes trabalham.

1planejar2  -> testar3  -> implementar4  -> revisar5  -> verificar6  -> registrar contexto7  -> melhorar o processo

O problema que o ECC tenta resolver

Se você usa IA para desenvolver, provavelmente já abriu uma conversa nova, explicou o projeto, pediu uma funcionalidade e só depois lembrou regras, testes e validações que deveriam ter entrado desde o começo.

• O plano se perde no histórico do chat.
• O agente implementa antes de entender o contexto.
• Testes e segurança dependem de um lembrete manual.
• A revisão acontece no mesmo contexto que escreveu o código.
• A sessão termina e parte do raciocínio desaparece.

O problema não é apenas o modelo esquecer uma instrução. É que práticas importantes continuam dependendo da memória de quem escreve o prompt. O ECC tenta transformar aprendizados recorrentes em artefatos que podem ser lidos, versionados, acionados e verificados.

A pergunta deixa de ser “qual é o melhor prompt?” e passa a ser “qual é o menor sistema que ajuda o agente a trabalhar com contexto, responsabilidade e evidência?”.

O mapa técnico do ECC

Para entender o repositório sem cair em um tour por centenas de arquivos, ajuda separar as camadas pela função e pelo comportamento de contexto.

• Rules mantêm políticas e padrões duráveis no contexto.
• Skills carregam conhecimento ou workflows quando a tarefa precisa deles.
• Agentes separam responsabilidade, contexto e ferramentas.
• Comandos oferecem entradas explícitas para workflows.
• Hooks reagem a eventos fora do raciocínio do modelo.
• Memória preserva decisões, evidências e próximos passos.
• Testes, evals e CI produzem evidência verificável.
• Adapters traduzem parte do sistema para outros harnesses.

Essas peças não têm o mesmo custo nem o mesmo risco. Uma rule pode ficar sempre no contexto, uma skill pode entrar sob demanda, um agente pode receber ferramentas próprias e um hook pode executar fora do prompt. Colocar tudo na categoria genérica de “prompt” esconde justamente as diferenças que importam.

Quatro ideias que valem estudar

1. Rules e skills não são a mesma coisa

Rules são adequadas para políticas realmente duráveis do projeto: não incluir segredos, validar entradas, seguir o padrão de erros e respeitar o escopo. Skills fazem mais sentido para processos situacionais, como TDD, revisão de segurança, investigação de bug ou verification loop.

Contexto é orçamento. Mais instruções não significam automaticamente mais qualidade; às vezes significam mais conflito, ruído e menos espaço para o problema real.

2. Um agente especializado precisa mudar algo de verdade

Um planner pode explorar o projeto e produzir um plano sem editar. Um implementador recebe o plano aprovado e altera apenas o escopo necessário. Um reviewer volta em modo de leitura e procura regressões, falhas de autorização e testes ausentes.

Trocar apenas o nome da persona não cria arquitetura. Um agente especializado começa a fazer diferença quando muda contexto, objetivo, responsabilidade, ferramentas, permissões ou critério de saída.

3. Hooks ajudam, mas CI decide

Hooks podem avisar sobre uma prática, bloquear um padrão perigoso, executar formatação, verificar tipos ou registrar estado. Isso reduz a dependência de o modelo lembrar de tudo, mas um hook local pode estar desabilitado, falhar ou não existir em outro harness.

Modelo probabilístico propõe e executa. Automação determinística prova. O agente pode dizer que testou; o pipeline precisa mostrar o resultado.

4. Memória útil não é transcrição infinita

Salvar tudo também salva ruído, hipóteses erradas e instruções que talvez nunca devessem atravessar sessões. O próprio ECC trata memória recuperada como contexto não revisado, não como política executável.

1Objetivo: adicionar autenticação às rotas administrativas2Decisão: reutilizar o middleware existente3Evidência: testes de integração passaram localmente4Tentativa descartada: sessão mantida apenas em memória5Risco pendente: revisar autorização por perfil6Próximo passo: validar as rotas no ambiente de teste

Memória boa não é lembrar de tudo. É manter visível o que foi decidido, o que foi verificado e o que ainda precisa acontecer.

Como essas peças podem formar um fluxo

1AGENTS.md curto e específico2  + rules comuns e da stack real3  + skill de planejamento ou TDD sob demanda4  + planner, implementador e reviewer5  + comando oficial de verificação6  + hook pequeno para um risco local7  + handoff quando a tarefa atravessar sessões

Em uma correção de bug, o planner registra hipótese, escopo e critérios de aceite. A skill de TDD orienta um teste que reproduz o problema. O implementador faz a menor alteração necessária. Um hook roda uma verificação rápida. O reviewer analisa o diff em contexto separado e o comando oficial executa build, tipos e testes.

O resultado não é apenas código. É uma trilha de evidências: plano, teste falhando, teste passando, revisão, validação e estado final. Essa é, para mim, a parte mais interessante do ECC.

Por que eu não instalaria tudo

O nome é Everything Claude Code, mas a pior conclusão possível seria pensar que o objetivo é usar tudo. Um catálogo grande pode ser útil como biblioteca e ainda criar problemas quando é adotado como pacote monolítico.

• Rules demais consomem contexto e podem entrar em conflito.
• Skills demais dificultam descoberta e manutenção.
• Agentes duplicados criam papéis sem diferença real.
• Hooks aumentam a superfície de execução local.
• MCPs ampliam ferramentas, permissões e consumo de contexto.
• Memória pode preservar informação errada ou contaminada.
• Instalações sobrepostas podem duplicar comandos e automações.

Eu vejo o ECC mais como uma biblioteca de decisões do que como um botão mágico. Vale estudar uma rule, o contrato de um reviewer, a relação entre hook e CI ou um modelo de handoff. Isso é diferente de entregar seu ambiente inteiro a centenas de arquivos que você ainda não leu.

Compatibilidade não significa paridade

O ECC começou muito associado ao Claude Code e continua tendo ali sua superfície mais completa. O projeto também oferece caminhos para Codex, Cursor, OpenCode, Gemini e outros harnesses, mas cada ambiente carrega instruções, descobre skills, executa hooks, configura agentes e pede aprovação de formas diferentes.

Por isso, qualquer tutorial precisa confirmar a versão do ECC, o harness de destino e quais capacidades realmente funcionam nessa combinação. Durante este levantamento, a release estável mais recente encontrada foi a v2.1.0, enquanto o main já documentava partes de um fluxo guiado associado à linha 2.2.

Para o segundo vídeo, mais técnico, vou validar os comandos contra a versão exibida antes de gravar qualquer instalação ou prévia.

Mais capacidade também significa mais responsabilidade

Tudo que torna um agente mais capaz também merece ser visto como parte da superfície de segurança. Rules carregam instruções, skills podem trazer scripts, hooks executam ações, MCPs conectam ferramentas, memória atravessa sessões e agentes recebem permissões.

O ECC inclui o AgentShield para analisar configurações de agentes, hooks, MCPs, permissões, segredos e possíveis riscos de injeção. O scanner é uma camada de apoio, não uma substituição para leitura, isolamento e revisão humana.

• Instale apenas de fontes oficiais.
• Escolha um único método de instalação por harness.
• Visualize o plano de alterações quando houver dry-run.
• Revise arquivos que executam código.
• Limite rules e skills ao projeto e à stack real.
• Trate memória como contexto não confiável até revisão.
• Mantenha validações obrigatórias no CI.
• Saiba como remover ou reverter o que foi instalado.

O que eu aprendi estudando o ECC

• O modelo não trabalha sozinho: contexto, ferramentas, permissões, testes e fluxo também moldam a qualidade.
• Processo repetível vale mais que prompt decorado.
• Contexto precisa ser tratado como orçamento.
• Especialização precisa mudar contrato, responsabilidade ou permissão.
• Verificação precisa produzir evidência em build, testes, diff e CI.

Esses aprendizados continuam úteis mesmo para quem nunca instalar o ECC. É por isso que o repositório vale ser estudado como referência de arquitetura.

O que vem na parte 2

A primeira parte do vídeo contou a história. Na segunda, quero abrir o repositório e mostrar quatro ideias de forma concreta, sem tentar ensinar uma instalação completa em cinco minutos.

1. Rules comuns e rules específicas da stack.
2. Uma skill de TDD ou verificação carregada sob demanda.
3. Planner, implementador e reviewer com responsabilidades diferentes.
4. Um hook local acompanhado por uma verificação equivalente no CI.

Conclusão

A história do hackathon é um bom gancho. Ela mostra Affaan Mustafa e David Rodriguez transformando uma ideia em um produto funcional sob pressão, com IA como parte do processo. Mas o aprendizado mais durável do ECC aparece depois.

Ele está na ideia de que o comportamento de um agente pode ser projetado com contexto, papéis, automações, memória e verificação. Isso não elimina a responsabilidade técnica; quanto mais capacidade colocamos ao redor do modelo, mais precisamos entender o que fica no contexto, o que executa código, quem altera arquivos e onde existe evidência.

Não é sobre instalar tudo. É sobre transformar bons hábitos em um sistema pequeno, explícito e verificável.