Dual-Brain — A skill que adiciona um ‘workflow de debate de hemisfério esquerdo e direito’ ao Codex/Claude Code

Olá. Recentemente, usando Codex e Claude Code em trabalho real, quero apresentar o Dual-Brain, um protocolo de skill em extensão desenvolvido como open source para reduzir problemas em que LLMs entram facilmente em sobrecarga ou revertem decisões anteriores ao escrever código complexo.

O Dual-Brain é menos uma forma de dividir cargos como “PM / desenvolvedor / QA” para a IA e mais uma abordagem de separar as funções de raciocínio com que ela observa o problema.

Em vez de um único agente dar a resposta imediatamente, ele força uma sequência em que primeiro passa pelo questionamento contextual do hemisfério direito e depois pela verificação lógica do hemisfério esquerdo, para então o orchestrator sintetizar o resultado final.

1. Três modos de falha da execução tradicional com agente único

Ao pedir de uma vez para um LLM, no terminal, fazer um design de arquitetura complexo ou um refactoring, normalmente aparecem com frequência os seguintes problemas.

• A armadilha de aceitar tudo ao pé da letra
  Ele aceita requisitos ambíguos como estão e acaba gerando com confiança um código totalmente fora do alvo.
• O inferno dos detalhes
  Fica preso em sintaxe de código microscópica e edge cases, deixando passar caminhos arquiteturais mais simples e melhores.
• Loop de amnésia
  Quando a sessão termina, o contexto anterior desaparece, e a direção arquitetural já decidida na semana passada é revertida novamente na sessão seguinte.

2. A solução: duas funções de raciocínio

Quando o Dual-Brain é carregado, o agente principal assume o papel de orchestrator e não responde de imediato. Em vez disso, ele executa duas etapas internas de revisão em uma ordem predefinida.

• Hemisfério direito, Right Brain: contexto / padrões / questionamento
  Em vez de implementar imediatamente o pedido do usuário, ele primeiro desconfia. Examina pontos como: “Qual é o ponto cego deste requisito?”, “Isso não entra em conflito com decisões anteriores?” e “A terminologia não está ambígua?”.
• Hemisfério esquerdo, Left Brain: lógica / validação / código
  Compara a definição do problema criada pelo hemisfério direito com o codebase real, a documentação oficial e a memória do projeto. Filtra APIs alucinadas, premissas desatualizadas e designs impossíveis de implementar, refinando tudo para uma forma executável.

No fim, o orchestrator sintetiza os dois resultados e segue até alterações no código, documentação e atualização de memória.

3. Sistema de memória em níveis

A skill salva a memória de longo prazo em .dual-brain/MEMORY.md na raiz do projeto.

Mas, à medida que o projeto cresce, pode surgir o problema de decisões antigas e restrições ativas da semana passada se misturarem com o mesmo peso. Para resolver isso, a memory não é tratada como um documento plano, mas como uma tiered memory.

• Hot Memory
• Warm Memory
• Cold Memory
• Archived Decisions

Hot Memory contém decisões ativas e restrições que influenciam fortemente o trabalho atual.

Warm Memory traz contexto útil que só é lido em tarefas relacionadas.

Cold Memory e Archived Decisions não são lidas por padrão; são consultadas apenas quando há necessidade de busca por palavras-chave ou verificação de conflitos.

refs não aumenta simplesmente porque algo foi lido; ele só aumenta quando aquilo realmente influenciou a pergunta, a validação, a síntese ou a implementação.

Memórias antigas ou duplicadas são compactadas automaticamente, e decisões contraditórias ou descartadas são enviadas para Archived.

Informações sensíveis, tokens, chaves e dados pessoais não são armazenados nem resumidos; são tratados como itens a remover ou não persistir.

O ponto importante é que a memory não é a fonte da verdade. No Dual-Brain, ela é um contexto consultivo, e o código atual e a documentação oficial têm prioridade sobre memory desatualizada.

4. Benchmark

O repositório inclui um pequeno benchmark harness, com base no Codex, para comparar a abordagem de agente único com a abordagem Dual-Brain.

O Dual-Brain não é uma abordagem rápida. Pelo contrário: o objetivo é fazê-lo pensar mais na etapa inicial para reduzir depois o ciclo em que uma pessoa precisa corrigir e explicar tudo novamente.

5. Instalação

Se você usa SkillsGate, pode instalar e gerenciar a skill nos ambientes Codex CLI e Claude Code.

npx skillsgate add sleeplesshan/dual-brain -g  
Instalação manual também é possível.  
 - Codex  
Bash  
git clone [https://github.com/sleeplesshan/dual-brain.git](https://github.com/sleeplesshan/dual-brain.git) ~/.codex/skills/dual-brain  
 - Claude Code  
Bash  
git clone [https://github.com/sleeplesshan/dual-brain.git](https://github.com/sleeplesshan/dual-brain.git) ~/.claude/skills/dual-brain  
Após a instalação, basta chamar em linguagem natural como de costume.  
  
6. Quando faz sentido usar  
O Dual-Brain é exagerado para ajustes simples. Não há necessidade de usá-lo para renomear variáveis, corrigir um bug de uma linha ou gerar boilerplate claro.  
Em vez disso, ele se encaixa bem nas seguintes situações.  
- refactoring com requisitos ambíguos  
- decisões de arquitetura  
- integração com APIs ou SDKs desconhecidos  
- mudanças que podem entrar em conflito com decisões passadas  
- tarefas em que uma API alucinada pode levar a incidentes reais  
- trabalhos em que você pensa “nem sei se estou fazendo a pergunta certa agora”  
  
Todo o `SKILL.md` e o benchmark harness foram disponibilizados como open source (licença MIT).  
 Gostaria de receber feedback de quem tem interesse em LLM orchestration, prompt engineering e design de agent memory.