O que Revisão em Ciclo faz?

Ciclo iterativo de trabalhador-revisor dentro de uma única sessão. Você faz o trabalho, gera um subagente revisor para criticá-lo, revisa com base no feedback e repete até que o nível de qualidade seja atingido.

Princípio central: Primeiros rascunhos nunca são finais. A crítica iterativa produz melhores resultados do que uma única passagem.

Nota sobre a plataforma: Este skill funciona melhor com agentes que suportam criação de subagentes. Em plataformas sem essa capacidade, simule a etapa de revisor abrindo um novo contexto de chat, colando apenas o produto do trabalho (sem raciocínio anterior) e pedindo que ele atribua uma nota de 1 a 10 com feedback específico.

Início Rápido

Diga: "implementar X, usar review-loop" ou "executar review-loop no arquivo que acabei de escrever"
O agente faz o trabalho (ou lê o trabalho existente)
Um subagente crítico separado avalia o trabalho com nota de 1 a 10 e feedback específico
O agente revisa e repete até que a nota seja >= 8 (nível de qualidade padrão)
Um resumo do ciclo é entregue com o resultado final

Quando Usar

O usuário diz "use review-loop", "polir isso", "iterar sobre isso", "/review-loop"
Implementações complexas onde a qualidade importa mais que a velocidade
Documentos de design, especificações ou escrita técnica
Código que precisa ser robusto (segurança, pipelines de dados, lógica financeira)
Quando o usuário deseja uma crítica adversarial incorporada ao processo

Quando NÃO Usar

Correções simples, edições rápidas, alterações de uma linha
Tarefas onde os testes são o critério de qualidade (use TDD + CI)
Quando o usuário quer apenas que seja feito rapidamente
Trabalho exploratório/experimental onde o objetivo é aprender, não entregar
Tarefas sem critérios de aceitação claros — defina-os primeiro, depois use review-loop

Padrões

Configuração	Padrão
Mínimo de loops	2
Máximo de loops	4
Nível de qualidade	8/10
Modelo do trabalhador	(seu modelo atual)
Modelo do revisor	(seu modelo atual ou alternativa rápida/equilibrada)

Seleção de Modelo

A tarefa do revisor avalia lógica e restrições. A tarefa do trabalhador escreve e modifica código. Escolha as capacidades do subagente de acordo.

REGRRA CRÍTICA: O Revisor deve ser SEMPRE IGUAL ou MAIS PODEROSO que o Trabalhador. Se o revisor for mais fraco que o trabalhador, ele não conseguirá criticar adequadamente lógica complexa ou detectar regressões sutis.

Complexidade da Tarefa	Capacidade do Trabalhador	Capacidade do Revisor	Justificativa
Simples/mecânica (CRUD, formatação, boilerplate)	Rápido / Leve	Equilibrado	Trabalhador leve é rápido, revisor equilibrado detecta problemas facilmente
Padrão (funcionalidades, refatorações, docs)	Equilibrado	Equilibrado	Bom equilíbrio entre custo, velocidade e qualidade
Complexa (multi-arquivo, integração, design)	Equilibrado	Avançado / Raciocínio	Revisor avançado detecta problemas sutis de arquitetura, trabalhador equilibrado consegue implementá-los
Muito complexa (segurança, quant, sistemas distribuídos)	Avançado / Raciocínio	Avançado / Raciocínio	Ambos precisam de contexto completo e poder de raciocínio. O revisor DEVE igualar o poder do trabalhador.

A regra de ouro: O trabalhador deve ser inteligente o suficiente para AGIR com base no feedback do revisor. Se o revisor disser "corrija a condição de corrida com um semáforo baseado em canal" e o trabalhador não conseguir raciocinar sobre concorrência, o loop não convergirá.

Sinal de escalada: Se a nota não melhorar após 2 loops consecutivos com o mesmo feedback, o modelo do trabalhador é fraco demais. Escale:

Opção A: Peça ao usuário para mudar para um modelo mais capaz
Opção B: Reduza temporariamente o nível de qualidade e comunique a lacuna ao usuário
Opção C: Divida a tarefa em subtarefas menores e execute review-loop em cada uma

Comportamento padrão: Como você (o agente principal) É o trabalhador, gere um subagente revisor que corresponda ou exceda sua capacidade atual com base na tarefa:

Maioria das tarefas → Revisor Padrão/Equilibrado
Tarefas especializadas/difíceis → Revisor Avançado/Raciocínio
Verificações rápidas → Revisor Rápido/Leve (apenas se você também estiver atuando como trabalhador leve)

Substituições pelo Usuário

Os usuários podem substituir qualquer padrão diretamente no pedido. Analise naturalmente:

"implementar X com review-loop, nível de qualidade 9, usar modelo avançado para revisão, máximo 5 loops"
"polir isso, mínimo 2 loops, nível 8"
"executar review-loop com revisor rápido, máximo 2 loops"
"usar review-loop, revisor com raciocínio, nível de qualidade 9, mínimo 3 máximo 6"

Regras de análise:

"nível de qualidade N" ou "nível N" → quality_gate = N
"revisor [modelo]" ou "revisar com [modelo]" → substituição do modelo do revisor
"máximo N loops" → max_loops = N
"mínimo N loops" → min_loops = N
Se o usuário não especificar, use os padrões
Se o usuário disser "rigoroso" ou "estrito" → interprete como nível de qualidade 8, min_loops 2
Se o usuário disser "rápido" ou "breve" → interprete como max_loops 2, nível de qualidade 6

O Processo

flowchart TD
    A[Faça o trabalho] --> B[Gere subagente revisor]
    B --> C{Loops mínimos atingidos?}
    C -- não, sempre continue --> E[Revise com base no feedback]
    C -- sim --> D{Nota >= nível de qualidade?}
    D -- sim --> F[Passo de polimento final]
    D -- não --> G{Máximo de loops atingido?}
    G -- sim, pare mesmo assim --> F
    G -- não --> E
    E --> B
    F --> H([Concluído])

Passo a Passo

Passo 1: Faça o Trabalho

Complete a tarefa como faria normalmente. Escreva o código, crie a especificação, implemente a funcionalidade. Não se segure — produza sua melhor primeira tentativa.

Passo 2: Gere Subagente Revisor

Use a ferramenta Agente para despachar um revisor. O revisor deve:

Ser um subagente separado (contexto novo, sem ancoragem ao seu raciocínio)
Receber apenas o produto do trabalho (arquivos, diffs) — não seu processo de pensamento
Atribuir uma nota de 1 a 10 com feedback específico e acionável
Usar um modelo equilibrado/padrão por padrão (ou um modelo avançado de raciocínio para tarefas complexas/especializadas)

Modelo de prompt do revisor:

Você é um revisor crítico. Atribua uma nota de 1 a 10 ao seguinte trabalho e forneça feedback específico e acionável.

## O que foi feito
{breve descrição da tarefa}

## Critérios de revisão
{critérios específicos da tarefa — o que importa para ESTA tarefa}

Exemplos de critérios bem escritos:
  Para um endpoint de API REST:
    - Códigos de status HTTP corretos usados
    - Validação de entrada presente em todos os parâmetros
    - Autenticação aplicada; nenhum acesso não autenticado
    - Sem padrões de consulta N+1

  Para um documento de design:
    - O problema é inequívoco
    - Alternativas consideradas com trade-offs
    - Sem generalizações sobre complexidade de implementação
    - Métricas de sucesso são mensuráveis

  Para um pipeline de dados:
    - Idempotente — seguro para reexecutar
    - Mudanças de esquema tratadas de forma elegante
    - Modos de falha documentados
    - Tratamento de PII abordado

## Instruções
1. Leia o trabalho cuidadosamente
2. Atribua nota de 1 a 10 onde:
   - 1-3: Fundamentalmente quebrado ou faltando requisitos importantes
   - 4-6: Funciona, mas tem problemas significativos
   - 7-8: Bom, apenas problemas menores
   - 9-10: Excelente, pronto para entrega
3. Liste problemas específicos com referências de arquivo:linha quando aplicável
4. Para cada problema, explique POR QUE ele importa e O QUE corrigir
5. Não seja educado — seja honesto e direto
6. Declare sua nota claramente como "Nota: N/10"

## Arquivos para revisar
{cole o conteúdo dos arquivos ou liste os caminhos dos arquivos com trechos relevantes}

Passo 3: Analise o Feedback

Da resposta do revisor, extraia:

Nota (o número)
Problemas (categorizados como Crítico / Importante / Menor)
Correções específicas (o que mudar)

Relate ao usuário:

Loop {N}/{max}: Nota {X}/10
- {resumo dos principais pontos de feedback}

Passo 4: Verifique Condições de Parada

Nesta ordem:

Se loops concluídos < min_loops → continue (sempre)
Se nota >= nível_de_qualidade → pare, vá para o polimento final
Se loops concluídos >= max_loops → pare, vá para o polimento final
Caso contrário → revise e repita o loop

Passo 5: Revise

Aborde o feedback do revisor. Corrija problemas Críticos e Importantes. Problemas Menores são opcionais. Depois volte ao Passo 2.

Importante: Cada revisão deve ser direcionada. Não reescreva tudo — corrija o que o revisor apontou. Mantenha uma lista mental de TODO o feedback anterior para evitar regressões.

Passo 6: Polimento Final

Quando o loop sair (nível de qualidade atingido ou máximo de loops alcançado):

Aborde quaisquer problemas menores restantes se forem triviais
Verifique se o resultado final é coerente (sem artefatos dos ciclos de revisão)
Relate a nota final e o número de loops ao usuário

Adaptando Critérios do Revisor por Tipo de Tarefa

Tipo de Tarefa	O Revisor Deve Focar em
Código	Correção, casos limite, tratamento de erros, legibilidade, sem problemas de segurança
Especificação/Design	Completude, viabilidade, sem generalizações, implementabilidade
Refatoração	Nenhuma mudança de comportamento, sem regressões, mais limpo que antes
Escrita	Clareza, estrutura, adequado ao público, sem rodeios
Correção de bug	Causa raiz abordada, teste de regressão existe, sem efeitos colaterais
Infraestrutura/IaC	Idempotência, menor privilégio, sem segredos hardcoded, segurança de destruição
Migração de banco de dados	Reversibilidade, estratégia de índices, risco de perda de dados, desempenho em escala
Design de API	Compatibilidade reversa, autenticação, versionamento, contrato de erro
Suíte de testes	Cobertura de casos limite, sem interdependência de testes, asserções significativas

Dois Modos de Operação

Modo A: "Fazer e Revisar" (ciclo completo)

O usuário dá uma tarefa + diz para usar review-loop. Você faz o trabalho E executa o ciclo de revisão.

Usuário: "Implemente a camada de cache. Use review-loop, nível de qualidade 8."

Você:
1. Implementa camada de cache
2. Gera revisor → Nota 6, feedback: sem remoção, sem TTL
3. Revisa: adiciona remoção + TTL
4. Gera revisor → Nota 8, feedback: questão menor de nomenclatura
5. Polimento final, concluído

Modo B: "Revisar Existente" (apenas revisão)

O usuário já fez o trabalho ou você já fez o trabalho. Apenas execute o ciclo de revisão no que existe.

Usuário: "Execute review-loop no módulo de autenticação que acabei de escrever"

Você:
1. Lê o módulo de autenticação
2. Gera revisor → Nota 5, feedback: injeção SQL, sem limitação de taxa
3. Corrige: parametriza consultas, adiciona limitador de taxa
4. Gera revisor → Nota 8, aprovado
5. Concluído

Bandeiras Vermelhas

Nunca:

Auto-revisar em vez de gerar um subagente (viés de ancoragem)
Pular um ciclo de revisão porque "o feedback está errado" sem justificativa
Inflar sua própria nota ("Acho que isso é na verdade um 9")
Continuar além do max_loops sem consentimento do usuário
Gerar o revisor com todo o seu raciocínio/histórico (eles devem revisar o TRABALHO, não sua intenção)

Se o revisor estiver errado:

Contra-argumente com evidências (mostre código/testes que refutam o feedback)
Pule esse ponto específico na revisão
Anote isso em seu relatório ao usuário
NÃO reduza o nível de qualidade para compensar

Formato de Relatório de Exemplo

--- Revisão em Ciclo: {nome da tarefa} ---

Loop 1/4: Nota 6/10
  Revisor: Validação de entrada ausente, sem tratamento de erro para timeout de rede,
           função muito longa (80 linhas).
  Ação: Corrigindo todos os três problemas.

Loop 2/4: Nota 8/10
  Revisor: Limpo. Menor: o nome da variável `d` poderia ser mais descritivo.
  Ação: Nível de qualidade atingido (8 >= 8). Polimento final.

Resultado: 8/10 em 2 loops. Concluído.

Limitações Conhecidas

O subagente revisor não tem memória de loops anteriores — inclua explicitamente o contexto de feedback anterior em cada prompt do revisor para evitar repetir problemas resolvidos
A inflação de nota é possível se os critérios do prompt do revisor forem muito vagos — invista tempo em escrever critérios específicos e mensuráveis
Este skill não substitui a revisão humana de código para código crítico de segurança ou sensível a conformidade; trate o resultado como uma primeira passagem forte
A convergência do loop não é garantida se a tarefa for subespecificada — defina critérios de aceitação claros antes de começar

Custo e Velocidade

Cada loop = 1 chamada de subagente revisor
Preveja aproximadamente 1–2x o tempo de uma única passagem de implementação para um ciclo completo de 3 loops
Isso é barato comparado a enviar código com bugs, especificações vagas ou acionar um ciclo de revisão tardio
Use seu modelo padrão/equilibrado para a maioria das revisões; atualize apenas para modelos avançados de raciocínio para domínios especializados (auditorias de segurança, sistemas distribuídos, finanças quant)

Licença

MIT — livre para usar, adaptar e redistribuir com qualquer ferramenta ou plataforma de IA. Atribuição apreciada. Contribuições bem-vindas.

Revisão em Ciclo

O que é Revisão em Ciclo?

Perguntar na sua IA favorita

Documentação