Como o Superpowers revisa o código entre as tarefas e impede o agente de empilhar erro em cima de erro?

Fala aí, beleza? Sabe aquela sessão em que você entrega um plano de seis tarefas pro agente e vai tomar um café?

Você volta e o negócio anda, mas a tarefa 3 se apoiou num erro que nasceu na tarefa 1, a 5 tentou consertar e quebrou outra coisa, e agora ninguém sabe mais onde exatamente a coisa desandou

É o clássico empilhamento de erro em cima de erro…

O Superpowers ataca justo esse ponto

Ele é um framework de skills agênticas e uma metodologia de desenvolvimento para o Claude Code, criado e mantido por Jesse Vincent (o usuário obra no GitHub), open source com licença MIT

O pacote tem várias skills, e aqui eu vou destrinchar as que seguram esse empilhamento: requesting-code-review, que confere o trabalho contra o plano ENTRE as tarefas, subagent-driven-development, que orquestra o plano com revisão em duas etapas, e systematic-debugging, o processo de causa raiz em quatro fases

Bora ver como funciona? 🙂

Por que o agente empilha erro em cima de erro?

O sintoma

Você provavelmente já viu essa sequência:

• a correção de um bug gera uma quebra nova em outro canto
• a tarefa seguinte é construída em cima de uma base que já estava errada
• a sessão fica longa e o contexto vira uma memória imprecisa do que foi feito

Isso aparece com força quando você deixa o agente rodando tarefas sozinho por um tempão, sem ninguém olhando no meio do caminho

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 116 aulas
• 4 projetos
• 9h 23min

Conhecer formação

A causa

Sem checkpoint entre as tarefas, a avaliação do trabalho depende do que o agente LEMBRA ter feito

E memória de sessão longa não é registro, é resumo

A segunda causa é irmã da primeira: correção proposta antes da investigação vira tentativa e erro, e cada tentativa deixa rastro no código

A solução

O Superpowers junta duas travas para isso

A primeira é uma revisão delimitada por um intervalo de commits do git, feita por um subagente que não herda o histórico da sessão principal. Ou seja: ele julga o que está no diff, não a narrativa da conversa

A segunda é a Iron Law do systematic-debugging, que bloqueia qualquer proposta de correção antes de a Fase 1 (investigação da causa raiz) estar completa

Como prevenir

Acionar a revisão depois de CADA tarefa, em vez de acumular tudo para o fim

E, quando três ou mais tentativas de correção falharem, parar e questionar a arquitetura fundamental, que é exatamente o freio que a skill impõe

Como funciona o requesting-code-review na prática

A mecânica é bem direta, e o pulo do gato está em QUEM revisa e no que essa pessoa (ou melhor, esse subagente) enxerga

1. A skill despacha um subagente revisor com contexto enxuto. Ele recebe apenas o contexto de avaliação, pelos placeholders DESCRIPTION, PLAN_OR_REQUIREMENTS, BASE_SHA e HEAD_SHA. Nada de histórico da sessão

2. O revisor levanta o escopo real pelo git. A revisão é delimitada por commits, não pelo que o agente acha que mexeu:

git diff --stat BASE_SHA..HEAD_SHA
git diff BASE_SHA..HEAD_SHA

O erro comum aqui é confiar no relato do implementador sobre os arquivos tocados. O diff não tem opinião, ele mostra o que foi alterado

3. Ele avalia o trabalho concluído contra o plano ou os requisitos. A função declarada do code-reviewer é exatamente essa: revisar o que ficou pronto contra o plano e identificar problemas ANTES que eles virem cascata

4. Devolve o relatório em três faixas de severidade. Isso padroniza a leitura e evita aquele relatório onde tudo parece igualmente urgente:

O erro comum de quem está começando é achar que a revisão precisa do histórico da sessão pra fazer sentido

É o contrário: ela roda em subagente justamente pra manter o diff e a avaliação FORA da janela de contexto da sessão principal, voltando só os achados

A sessão principal recebe o resultado, não o material bruto 😀

As instruções vivem no repositório, em skills/requesting-code-review/SKILL.md e skills/requesting-code-review/code-reviewer.md, então dá pra ler exatamente o que o revisor recebe

Quando acionar a revisão entre tarefas

A própria skill indica os momentos. Se liga no tipo de erro que cada um pega:

• Depois de cada tarefa no fluxo dirigido por subagentes: pega o defeito enquanto ele ainda pertence a uma tarefa só, antes de virar base da próxima
• Depois de features grandes: pega o problema de arquitetura que só aparece quando as peças da feature se encaixam
• Antes do merge na main: pega o que ninguém quer descobrir depois, com o código já integrado ao tronco

E tem os opcionais:

• Quando o trabalho travou: pega a premissa errada que está segurando o avanço, olhando o diff com outros olhos
• Antes de refatorações: pega o problema que a refatoração ia carregar junto (e disfarçar)
• Depois de correções de bug complexas: pega o efeito colateral que a correção introduziu longe do ponto do bug

A revisão em duas etapas do subagent-driven-development

Essa é a skill que orquestra o plano inteiro, e o princípio declarado dela é curtinho: subagente NOVO por tarefa, mais revisão em duas etapas

1. Etapa 1: conformidade com a spec. O revisor pergunta se o que foi feito atende ao que o plano pedia

2. Etapa 2: qualidade de código. Só depois que a conformidade passa é que entra a avaliação de qualidade

3. A ordem é obrigatória. E a justificativa é declarada: não gastar revisão de qualidade em código que ainda nem atende aos requisitos. Faz sentido, né? Polir algo que vai ser reescrito é desperdício puro

4. O loop roda até aprovar. O revisor aponta, o implementador corrige, o revisor revisa de novo, e isso se repete até o aval sair. Só então a próxima tarefa começa

5. Subagentes nunca herdam o histórico da sessão principal. Cada um recebe apenas o contexto necessário pra sua tarefa

Essa última regra é a que dá independência ao julgamento, e é também o que muda o jogo na hora de descobrir qual agente errou quando o resultado final sai torto

O erro comum aqui é assumir que subagente é obrigatório. Não é: existe a skill executing-plans, que executa o plano na sessão atual, tarefa a tarefa, com checkpoints humanos

Ela serve pra plataformas sem suporte a subagentes ou pra quem simplesmente prefere uma sessão linear

Os arquivos dessa metodologia ficam em skills/subagent-driven-development/SKILL.md e skills/subagent-driven-development/code-quality-reviewer-prompt.md

systematic-debugging: as quatro fases da causa raiz

Revisar entre tarefas evita que o erro se espalhe. Mas e quando o bug JÁ está lá?

Aí entra o systematic-debugging, com um processo em quatro fases:

1. Fase 1, Root Cause Investigation. É a fase mais exigente, e tem passos obrigatórios: ler as mensagens de erro e os stack traces, reproduzir o problema de forma confiável, checar commits, configuração e mudanças recentes de ambiente, e reunir evidência entre componentes

2. Fase 2, Pattern Analysis. Olhar o problema como padrão, não como ocorrência isolada

3. Fase 3, Hypothesis and Testing. Formular a hipótese e testar, em vez de aplicar o patch e torcer

4. Fase 4, Implementation. A correção em si, que só chega aqui no fim

Duas coisas seguram o processo no lugar

A primeira é a Iron Law: nenhuma correção pode ser proposta antes de a Fase 1 estar completa. Achar a causa raiz vem SEMPRE antes de tentar consertar

A segunda é o root-cause-tracing, a técnica de seguir o bug de trás para frente pela call stack até encontrar o disparo original. É a diferença entre tratar o sintoma onde ele apareceu e tratar onde ele nasceu

E tem o freio: se três ou mais tentativas de correção falharem, o agente DEVE parar e questionar a arquitetura fundamental

Sem esse freio, o agente entra naquele ciclo de tentativa e erro que só engorda o diff

O erro comum de todo mundo (humano incluído, haha) é pular direto pra Fase 4 porque a hipótese parece óbvia demais pra ser errada

As instruções estão em skills/systematic-debugging/SKILL.md

Revisar no meio do caminho é diferente de revisar só no fim?

É diferente sim, e a diferença não é de gosto, é estrutural

Quando a revisão acontece entre as tarefas, o revisor avalia um pedaço pequeno, o erro é atribuído à tarefa que o produziu e o loop de correção roda ANTES de outra tarefa se apoiar no defeito

Quando ela acontece só no fim, o diff chega grande, a origem do problema fica ambígua e a correção precisa mexer em código que já virou dependência de outra coisa

Agora o contrapeso honesto: revisar a cada tarefa custa mais rodadas de agente e trava o avanço até a aprovação sair

Então o valor aparece em planos com várias tarefas encadeadas, onde um erro cedo contamina o resto

Pra mudança isolada de uma linha, isso é cerimônia demais

Como instalar o Superpowers no Claude Code

O Superpowers está disponível no marketplace oficial de plugins da Anthropic, então o caminho mais curto é esse:

1. Instale pelo marketplace oficial, direto no Claude Code:

/plugin install superpowers@claude-plugins-official

2. Se preferir o marketplace do próprio autor, adicione ele antes e instale depois:

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

O erro comum deste passo é tentar instalar pelo segundo marketplace sem ter rodado o add antes. Sem adicionar a fonte, o install não tem de onde puxar

Vale registrar: é um projeto de terceiro, com licença MIT e sem custo de licença

Conclusão

O ganho do Superpowers aqui não é ter um revisor, isso qualquer um improvisa com um prompt

O ganho é ter revisão no PONTO certo do fluxo, delimitada por commits e feita por quem não herdou a narrativa da sessão, mais uma regra dura que proíbe consertar antes de entender

Se quiser experimentar, o caminho é: instalar pelo marketplace, aplicar o requesting-code-review logo depois da próxima tarefa de um plano (em vez de esperar o fim) e sentir a diferença no tamanho do diff que volta pra você

Depois vale explorar o resto do pacote, que traz brainstorming, test-driven-development com o ciclo red-green-refactor, using-git-worktrees, executing-plans e até a autoria de skills novas

E se você curte fuçar, o autor mantém repositórios complementares: obra/superpowers-skills, com skills editáveis pela comunidade, e obra/superpowers-lab, com as experimentais

Até o próximo post! =)