Revise uma alteração de código com outro modelo em até 3 rodadas: um revisor lê a alteração, e um 'breaker' tenta quebrá-la com testes. Mantenha cada correção a menor que resolva sua descoberta, e conteste com evidências quando uma descoberta estiver errada.
1. Informe o revisor e o breaker
O revisor e o breaker são o modelo mais novo, em orchestrator_capabilities, da família que o usuário nomeou (sol, opus, …), no esforço que ele nomeou; não defina nenhuma outra opção de modelo. Um provedor sozinho (gpt, claude) não nomeia uma família. Se a família ou esforço estiver faltando, peça e não faça mais nada até que respondam.
Fixe a base: a que quem chama passar, caso contrário git merge-base HEAD <remote>/<default-branch>, onde o remoto é aquele em que a alteração é mesclada (upstream em um fork), ou HEAD quando a alteração for apenas não commitada. Execute as verificações que cobrem a alteração, através da habilidade de verificação do repositório quando houver uma (.agents/skills/verify/), e corrija qualquer falha antes da rodada 1. Registre a revisão em que executou, incluindo alterações não commitadas.
Inicie cada rodada como um delegate_task fresco. O 'pushback' e as rodadas posteriores vão no novo briefing, nunca em uma mensagem de acompanhamento para um revisor finalizado. Um tempo limite ou erro não é aprovação: reinicie o agente que falhou, uma vez.
Quando o diff alterar apenas comentários, documentação ou formatação, não execute nenhum loop e diga isso na mensagem final. Na rodada 1, inicie o revisor e o breaker em paralelo, o breaker com isolation: "worktree". Pule o breaker quando o diff não alterar nenhum código executado. Em uma execução leve (o nível see-it-through passar), não inicie um breaker na rodada 1; assim que o revisor responder, inicie um com escopo nas condições da sua linha 'Não verificado' que um teste poderia resolver, se houver.
Ambos os briefings abrem com este cabeçalho:
Repositório: <caminho abs> Base: <sha> Fora do escopo: <escopo>
Padrões: <os arquivos de regras do repositório, como AGENTS.md ou CONTRIBUTING.md; ou nenhum>
Configuração: <o que todo shell deve executar primeiro, como um script de toolchain fixo, e o que um checkout novo precisa, como uma instalação; ou nenhum>
Verificações: <resultados> Executando agora: <verificações ainda em andamento; ou nenhum>
Solicitação: <a solicitação ou briefing do usuário, palavra por palavra, ou seu caminho absoluto>
Abordagem: <a abordagem aprovada, ou seu caminho absoluto; ou nenhum>. Suas alegações são do autor: verifique aquelas em que o diff se baseia.
Aceitação: <o commit ou patch que contém as verificações de aceitação escritas antes da alteração; ou nenhum>
Diff: git diff <base>; leia também arquivos não rastreados de git status --short.
Condições: antes de ler o diff, escreva condições de aceitação da Solicitação: o que o usuário deve ver ou receber de volta em sucesso, falha, cancelamento e repetição; após uma falha parcial (o que fica na memória, no disco e na tela); em uma repetição, ou uma tentativa anterior terminando após uma mais nova; quando uma espera retorna depois que o usuário seguiu em frente; em toda superfície que mostra o resultado, dados em cache incluídos; e uma saída de cada estado que a alteração pode deixar. Escreva apenas onde o código alterado atinge aquele caso: no caminho pretendido, através de cada outro chamador do código alterado, e através de cada outro escritor de estado que a alteração agora confia (pesquise por ambos).
Briefing do revisor, após o cabeçalho:
Apenas revise: leia e rastreie. Não edite, commite, faça push, comente, inicie subagentes, ou escreva ou execute testes ou builds.
Escreva as condições de aceitação como Condições diz, então como você faria a alteração dentro da Abordagem. Comece sua resposta final com ambos, palavra por palavra; a linha VEREDITO os segue.
Encontre problemas com a alteração, rastreando cada condição através do código até o que o usuário vê ou recebe de volta. Sua abordagem é uma descoberta apenas onde ela atende a uma condição que o diff falha, ou atende a todas as condições com menos código.
Para cada bug que você encontrar, nomeie sua classe e procure pelo mesmo erro no resto do diff e seus chamadores, incluindo um caso irmão que a alteração trata de forma diferente; relate uma descoberta por classe, listando cada local.
Verifique a alteração em relação aos arquivos de Padrões; marque essas descobertas [padrões], e pule o que linters e verificadores de tipo impõem.
Sinalize como nits código ou proteções que nenhuma condição precisa, código novo que o repositório ou plataforma já fornece, e código que se afasta dos Padrões ou das convenções do código circundante; não estilo que você meramente prefere.
Verifique se a alteração introduz propriedade concorrente de estado, uma decisão tomada em dois lugares, uma obrigação que os chamadores devem lembrar, ou um limite que os chamadores podem contornar; marque-os [estrutura], nomeando o código e sua consequência, e classifique-os pelas definições abaixo. Um design diferente sem tal consequência é um nit; um redesign maior é uma descoberta apenas com o motivo pelo qual a menor correção não pode consertá-lo.
Uma edição em uma verificação em Aceitação que a impede de provar o que prometia é um should.
bloqueador = o caso pretendido está errado. should = um problema que esta alteração causa e que uma ação ou entrada suportada pode alcançar: uma ação do usuário, arquivos no disco, uma falha de E/S, arquivos que o usuário fez, mostrado executando-o ou rastreado através do código, inclusive através de chamadores que o diff não tocou. Um teste que a alteração adiciona e que pode passar sem o comportamento que prova é um should.
nit = estilo, pequena perf, polimento. pré-existente = a mesma falha acontece na base, mostrada por um teste ou um rastreio, e a alteração não torna mais fácil de alcançar nem contradiz uma alegação que faz.
VEREDITO: APROVADO ou ALTERAÇÕES, então uma linha por descoberta:
S1 [bloqueador|should|nit|pré-existente] <arquivo>:<linha> <alegação>. Correção: <menor correção>
em seguida Verificado: uma linha por condição: <arquivo>:<linha> e o que aquela linha estabelece.
em seguida Não verificado: o que você não pôde confirmar, e por quê; ou nenhum.
Briefing do breaker, após o cabeçalho:
Quebre esta alteração. Não commite, faça push, comente, ou inicie subagentes.
Trabalhe apenas no seu próprio checkout, o diretório de trabalho em que você iniciou, que é uma cópia do HEAD de <repositório>. Primeiro, traga a parte não commitada da alteração: git -C <repositório> diff HEAD | git apply, então copie os arquivos não rastreados listados por git -C <repositório> status --short. Nunca altere arquivos em <repositório> ou na configuração do usuário, e não execute nada que faça push, publique ou notifique; caches de gerenciadores de pacotes são aceitáveis. Pule execuções E2E e qualquer coisa listada em Executando agora; compile apenas o que seus testes precisam.
Escreva as condições de aceitação como Condições diz. Para cada uma, escreva e execute o menor teste que falharia se a condição quebrasse, afirmando o que o usuário vê ou recebe de volta.
Para cada teste abaixo de E2E que a alteração adiciona como prova, desfaça a proteção que ele deve detectar, ou quebre sua pré-condição, execute-o, então restaure o código.
NÃO PUDE TESTAR é apenas para uma condição que este nível não pode alcançar, como uma que precisa de E2E. Uma fila lenta ou sua própria configuração quebrada não é uma: agrupe seus testes em um único job, espere sem cancelar, e corrija sua configuração.
Antes de responder, escreva um patch de seus testes que passam e que cobrem uma condição que nenhum teste existente cobre para <caminho_manter>, e apague todo o resto que você adicionou.
Responda, uma linha por condição: B1 MANTEVE <condição> — <comando>; B2 QUEBROU <condição> — <comando> e a saída com falha; ou B3 NÃO PUDE TESTAR <condição> — por quê. Em seguida, uma linha por teste de prova: P1 FALHA <teste> com <proteção> desfeita; ou P2 AINDA PASSA <teste> com <proteção> desfeita. Em seguida: Mantido: <caminho_manter> e a condição que cada teste cobre; ou nenhum.
Escolha <caminho_manter>: um caminho absoluto fora de ambos os checkouts.
2. Responda às descobertas
Classifique cada descoberta você mesmo pelas definições do briefing do revisor, qualquer que seja o rótulo com que veio. Trate cada linha QUEBROU e AINDA PASSA como uma descoberta.
- Concorde: reproduza-a primeiro, com um teste que falha no código atual quando um significativo for prático, caso contrário uma reprodução direta (comando e saída) com seus limites anotados; verifique uma alegação sobre fatos, como o que o CI executa ou o que a base faz, contra sua fonte. Em seguida, pesquise os casos irmãos e chamadores do código alterado por mais da classe da descoberta, e aplique a menor correção a cada instância que a alteração introduziu ou expôs; liste as pré-existentes não relacionadas como acompanhamentos. Mostre que o teste passa (para uma descoberta AINDA PASSA, que o teste corrigido falha com a proteção desfeita), e mantenha o teste. Prefira deletar ou estreitar código a um novo bloqueio, cache, auxiliar ou opção.
- Discorde: diga por quê, com evidência (um teste ou saída de comando). Uma razão lida apenas do código, como "isso não pode acontecer", deixa a descoberta disputada, não descartada ou rebaixada.
- Nit: em código que o diff adiciona, altera ou move, aplique-o quando sua correção deleta código, reutiliza o que o repositório ou plataforma fornece, ou traz o código em linha com os Padrões ou o código circundante, mantendo todas as verificações passando e sem trocar clareza por comprimento. Recuse em uma linha um nit que adiciona um caminho, caso, opção ou camada de compatibilidade, um cuja correção altera o que o usuário vê ou recebe de volta, e um que é apenas gosto.
- Pré-existente ou fora do escopo: recuse em uma linha.
Commite cada teste no patch do breaker, ou nomeie o teste existente que cobre sua condição.
Nunca concorde apenas para terminar o loop. Reexecute as verificações e git diff --shortstat <base>; remova o que a revisão adicionou fora de testes que nenhuma descoberta aceita precisa, mantendo a menor correção correta mesmo quando ela aumenta o código.
3. Próxima rodada
Inicie uma apenas quando um bloqueador ou should estiver aberto, ou código de comportamento mudou. Envie o cabeçalho com sua linha Condições substituída pelas condições do revisor da rodada 1, o briefing do revisor sem sua linha de condições-e-esboço, cada id anterior marcado como corrigido, disputado (com a evidência) ou recusado (com o motivo), e os hunks alterados desde a última rodada. Diga ao revisor para revisar apenas os ids abertos e aqueles hunks, escrever novas condições para o comportamento que aqueles hunks alteram e seus chamadores, marcar cada id anterior como resolvido ou ainda aberto, e numerar novas descobertas após o último id. Quando uma correção alterou comportamento, ordenação ou propriedade, como mover uma escrita após uma espera, também inicie um breaker com o mesmo cabeçalho, instruído a escrever e testar condições apenas para aqueles hunks e seus chamadores.
4. Finalizar
Feito quando nenhum bloqueador ou should estiver aberto e a última alteração fora de testes, comentários e formatação tiver passado por uma rodada; APROVADO encerra o loop antecipadamente no código que revisou. Envie um novo breaker em qualquer NÃO PUDE TESTAR cuja causa pode ser corrigida; liste um que precisa de E2E para o autor. Se um bloqueador ou should ainda estiver disputado após a rodada 3, execute a rodada de disputa em dispute-round.md; uma descoberta que ele deixar INCONCLUSIVO encerra o loop terminado com disputas não resolvidas, não aprovado. Nits recusados e descobertas pré-existentes permanecem recusados.
Mensagem final: rodadas executadas, os modelos, o que as descobertas mudaram, cada comportamento, teste, alegação ou polimento marcado, tamanho do diff antes e depois, qualquer descoberta descartada porque um teste ou saída mostrou estar errada, e cada nit recusado ou descoberta pré-existente com seu motivo. Adicione o que o breaker testou, o que quebrou, quais deles o revisor também encontrou, e cada condição que nenhum teste commitado cobre. Se uma rodada de disputa ocorreu, dê cada resultado. Liste cada risco não confirmado em palavras simples. Se evals/results.jsonl existir e o modelo revisor diferir do último nele, diga e ofereça uma execução da suíte de regressão (evals/README.md).