103kaz/claude-code-loops

review-loop

Execute o ciclo de desenvolvimento sobre a branch atual: verifique, revise o diff, corrija e repita até que uma rodada não encontre nada. O escopo é apenas o diff, não todo o código. Esta skill não faz push ou abre um pull request; essas ações ficam com o usuário.

Passos

1. Execute .claude/verify.sh. Se falhar, corrija isso primeiro. Se o arquivo não existir, informe o usuário e aponte para /code-loops:init-verify, depois continue sem a verificação e informe isso no relatório.
2. Decida o diff. Primeira rodada: a branch contra sua base (git diff origin/HEAD...HEAD, mais git diff HEAD para alterações não commitadas, mais os arquivos não rastreados de git status --short, que você lê diretamente). Se origin/HEAD não estiver definido, tente origin/main ou origin/master; se nenhum existir, pergunte ao usuário pela base. Se o diff estiver vazio (por exemplo, você está na própria branch base), informe que não há nada para revisar e pare. Se alterações não commitadas parecerem não relacionadas ao trabalho da branch, não as corrija; mencione-as no relatório. Rodadas seguintes: apenas o que você alterou na rodada anterior.
3. Revise o diff.
   • Se alterar código, use a skill code-review com esforço médio. Se essa skill não estiver disponível, leia o diff você mesmo em busca de bugs: resultados errados, caminhos de erro ausentes e chamadores que a alteração quebra.
   • Se alterar apenas documentação (.md e similares), use /code-loops:doc-code-consistency no diff.
4. Corrija os achados. Não faça commit; deixe isso para o usuário. Após cada correção, volte ao passo 1. Repita até que uma rodada não encontre nada. Um achado que você decida não corrigir recebe um motivo de uma linha. Se três rodadas seguidas ainda apresentarem achados (uma falha de verify.sh conta), pare e relate o que restou em vez de continuar.
5. Se o diff alterou código que a documentação descreve, execute /code-loops:doc-code-consistency no diff uma vez ao final e corrija o que encontrar.
6. Ofereça uma revisão independente, uma vez, a menos que o diff seja apenas documentação. Pergunte ao usuário (AskUserQuestion) se deseja executá-la, com uma nota de uma linha sobre se este diff parece valer a pena (tamanho, áreas arriscadas); o padrão é não. Se sim, inicie um subagente que veja apenas o diff, não como foi construído. Use um tipo de agente somente leitura se existir (por exemplo Explore); caso contrário, instrua-o a não editar arquivos. Peça que procure por entradas, estados e ordenações que quebram a alteração, e relate cada um com evidência de arquivo:linha; se .claude/review/checklist.md existir, peça que verifique também contra ele. Corrija o que encontrar, depois execute os passos 1 e 3 apenas nessas correções. Se subagentes não estiverem disponíveis, pule esta etapa e informe isso no relatório.
7. Relate em algumas linhas: "Resultado: nenhum achado", ou "Resultado: achados mantidos" com cada achado e seu motivo. Adicione se verify.sh passou, quantas rodadas levou e se uma revisão independente foi executada.

Mantenha cada rodada discreta: leia o diff, não o repositório, e não repita os achados de uma rodada anterior.