dknchris/multimodel-review

Executa o loop de revisão multi-modelo no branch atual: revisores Codex (Terra por padrão; Astra, Sol e Luna opcionais) e revisores Claude (Opus por padrão; Fable, Sonnet e Haiku opcionais), com esta sessão como único corretor, através das fases Código, Limpeza, Documentação e Final.

O que é multimodel-review?

Esta skill automatiza o processo de revisão de código multi-modelo, combinando revisores Codex (como Terra, Astra, Sol e Luna) e Claude (como Opus, Fable, Sonnet e Haiku) em um único fluxo de trabalho. O objetivo é garantir que múltiplos revisores de IA analisem o mesmo código simultaneamente, enquanto esta sessão atua como o único agente corretor, integrando feedback e aplicando correções. A skill suporta plataformas como Claude Code e Codex, e gerencia limites de rodadas, esforço dos revisores e fases distintas (Código, Limpeza, Docs, Final). O processo começa com a definição das opções de revisão (revisores, esforço, comprimento das rodadas), em seguida inicializa um snapshot do código, executa revisões em paralelo, faz a triagem dos achados e aplica correções incrementais até a convergência. Também lida com casos de falha, reinicializações e geração de relatórios finais.

Funciona com✓Claude Code✓Codex CLI~Cursor
npx skills add https://github.com/dknchris/multimodel-review/tree/HEAD

Installed? Explore more Programação e Desenvolvimento skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

Revisão multi-modelo (Codex + Claude)

Revisores independentes leem o mesmo prompt no mesmo commit. Esta sessão é a única corretora. Execute-a a partir de uma sessão no Opus 5.5 com esforço alto.

Opções: $ARGUMENTS

Configurações

  • Limites de rodadas: Código 20 a 50 (padrão 20; no seletor, Padrão, Longo e Máximo são 20, 35 e 50), Documentação 2, Final 2, mais 2 a 6 rodadas de sobra para rodadas de evidência (padrão 2). Parada forçada: A soma deles, 26 por padrão. Cada fase termina na sua primeira rodada limpa, então os limites são tetos. Execuções mais antigas mantêm seus próprios limites e tetos.
  • Revisores: Terra (gpt-6.1-terra) e Opus (Opus 5.5) por padrão. Opcionais: Fable (Fable 5.2), Astra (gpt-6-astra), Sol (gpt-6.1-sol), Sonnet (Sonnet 5.5), Haiku (Haiku 5.5) e Luna (gpt-6-luna). Execuções iniciadas antes desta alteração chamam seu revisor Opus de claude.
  • O esforço é definido para cada revisor, por execução: baixo, médio, alto, muito alto ou máximo. Padrões: Codex máximo, modelos Claude muito alto.
  • Painel padrão: terra:max:fast opus:xhigh code:20 spare:2.
  • O modo rápido Codex (nível de prioridade) é definido para cada revisor Codex, por execução. Nunca se aplica a modelos Claude.
  • Cada execução Codex é interrompida após 10 minutos de silêncio ou 60 minutos no total. Falhas e respostas vazias recebem 1 reexecução. Uma resposta nunca é reexecutada por causa do seu formato.

O auxiliar abaixo impõe esses limites e mantém todo o estado em ~/.claude/multimodel-review/, fora de todo repositório, porque uma execução longa é compactada e o relatório não pode ser reconstruído da memória. Escreva seu caminho completo a cada vez e adicione --repo <caminho> antes do subcomando se o shell não estiver dentro do repositório:

python3 ~/.claude/skills/multimodel-review/scripts/mmr.py status

Abaixo, mmr <comando> é a abreviação para essa chamada completa.

Iniciar ou retomar

  1. Execute mmr status. Se existir uma execução inacabada, continue a partir do que ela mostra, com os revisores que lista. Se disser "Localização antiga", execute mmr migrate assim que todos os revisores terminarem, depois use apenas o novo caminho.
  2. Escolha opções, antes de qualquer outro passo, para que o proprietário as veja imediatamente:
    • Se a linha de Opções acima for apenas pick (ou picker): Mostre o seletor (próximos dois itens).
    • Caso contrário, esteja vazia ou não: Execute mmr options "<opções>" e não mostre seletor. Vazio significa os padrões, terra:max:fast opus:xhigh code:20 spare:2. Se falhar, mostre ao proprietário o erro de uma linha e pare. Cada revisor é nome[:esforço][:fast]: O esforço padrão é máximo para Codex e muito alto para modelos Claude, e um modelo Codex executa em velocidade padrão a menos que :fast seja fornecido. code:<20-50> e spare:<2-6> são opcionais (padrões 20 e 2).
    • Seletor, se show_widget estiver disponível: Chame read_me uma vez com módulos ["interactive"]. Depois execute mmr picker e passe tudo após sua linha Código do widget:, inalterado, como widget_code, com título multimodel_review_options. Encerre o turno e aguarde. Seu botão envia "Iniciar a revisão com <opções>.", na mesma forma digitada, por exemplo "terra:max:fast opus:xhigh code:20 spare:2". Execute mmr options "<opções>" nelas. Se a mensagem do proprietário disser que o seletor não carregou, execute mmr picker --offline e mostre isso em vez disso.
    • Seletor em um terminal (sem show_widget): Uma chamada AskUserQuestion com quatro perguntas: Revisores (multisseleção: Terra, Opus, Fable, Astra; Sol, Sonnet, Haiku e Luna através de Outro), Modelos Codex em modo rápido (multisseleção: Terra, Astra, Sol, Nenhum; Luna através de Outro), Esforço (Codex máximo e Claude muito alto, tudo alto, tudo médio) e Comprimento da revisão (Padrão code:20, Longo code:35, Máximo code:50). Ignore uma escolha rápida que não seja um revisor escolhido. Escreva as respostas na forma digitada e execute mmr options "<opções>" nelas.
  3. Escreva uma intenção de 3 a 5 linhas em um arquivo temporário com a ferramenta Write: o que a mudança deve fazer e para quem. Tire-a da solicitação, desta conversa, texto do PR, commits ou diff não confirmado. Os revisores não podem julgar "comportamento errado" sem ela. Se não estiver claro, faça uma pergunta ao proprietário com botões.
  4. Leia git status --short. Tudo o que não está ignorado é commitado no snapshot, então separe qualquer coisa não relacionada a esta mudança (uma pasta solta, anotações) e passe como --leave-out <caminho>. Se não puder dizer, pergunte com botões.
  5. Execute mmr init --intent-file <arquivo> --trailer "<linha de atribuição>" --spec "<opções>", com as opções exatamente como a linha Init: de mmr options as imprimiu, adicionando --base <base> apenas se o proprietário nomeou uma e --leave-out <caminho> conforme necessário. A base padrão é o branch padrão do remoto, e a revisão começa a partir da mesclagem base. Invocar esta skill é a autorização do proprietário para o que init faz:
    • No branch base ou em HEAD separado, ele cria multimodel-review/<tempo> primeiro, para que os commits WIP nunca caiam na base.
    • O trabalho não confirmado torna-se um commit de snapshot WIP, para que todos os revisores leiam o mesmo commit. Nada é enviado.
    • Código de saída 5 significa que alguns arquivos parecem segredos, têm mais de 20 MB ou são repositórios embutidos. Nada mudou ainda. Pergunte ao proprietário com botões: Deixá-los de fora (--leave-out) ou incluí-los (--allow-flagged).
    • "Nada a revisar" significa que não há commits nem trabalho não confirmado. Pergunte ao proprietário quais commits revisar, depois passe --base <commit>.
  6. Informe ao proprietário em uma linha se init criou um branch ou um snapshot.

Uma rodada

  1. Execute mmr next --phase <code|docs|final|evidence>. Ele constrói o arquivo de prompt e imprime seu caminho, as configurações da execução e uma linha Claude Agent por revisor Claude, com seu modelo, esforço e arquivo de resposta. Código de saída 3 significa que um limite foi atingido: Vá para Concluído.
  2. Inicie todos os revisores que mmr status lista, em uma mensagem:
    • Cada revisor Codex (terra, astra, sol, luna): Bash com run_in_background: mmr codex --reviewer <nome>. O auxiliar executa Codex com -s read-only, apps, plugins e subagentes desligados, pesquisa web ligada, seus próprios logs e os limites de tempo. Nunca use workspace-write ou --dangerously-bypass-approvals-and-sandbox, o script complementar ou o subagente de resgate.
    • Um Monitor por revisor Codex: mmr monitor --reviewer <nome>, com timeout_ms: 1800000. Ele verifica a cada 60 segundos e decide "finalizado" a partir da saída do PID, nunca do texto de saída.
    • Cada revisor Claude (opus, fable, sonnet, haiku; claude em execuções mais antigas): Um novo Agent com subagent_type: "multimodel-reviewer", model e effort de sua linha Claude Agent, e o prompt "Arquivo da rodada de revisão: ". Esse agente tem ferramentas de leitura e web, mas sem ferramentas de shell ou edição. Se o tipo não estiver disponível, use Plan com o mesmo modelo e esforço e diga a ele para usar apenas Read, Grep e pesquisa web.
  3. Manuseie eventos do Monitor:
    • FINISHED: Nada a fazer.
    • FAILED: Reexecute como no passo 5 e informe ao proprietário em uma linha apenas se a reexecução também falhar.
    • QUIET: Não é uma falha, já que esforço alto pode pensar silenciosamente por minutos. Não tome nenhuma ação; o auxiliar para um revisor após 10 minutos de silêncio.
    • RE-ARM: Inicie esse monitor novamente.
  4. Quando um Claude Agent retornar, escreva sua mensagem final inalterada em seu arquivo de resposta do passo 1, depois execute mmr claude-result --reviewer <nome> --seconds <duration_ms / 1000>.
  5. Execute mmr barrier. Não edite nada até que passe. Se um resultado estiver vazio ou ausente, reexecute apenas esse revisor, no mesmo commit; a rodada não conta novamente. Para um revisor Claude, crie um novo Agent e repita o passo 4. O auxiliar recusa uma terceira tentativa e qualquer reexecução após uma parada ou tempo limite: Então execute mmr stop --reason "<porquê>" e vá para Concluído. Exceção: Uma execução de antes das regras de formato serem descartadas pode mostrar malformed em uma resposta real. Execute mmr reread --reviewer <quem>, que lê a resposta salva novamente sem nova execução do revisor.
  6. Faça a triagem (veja as regras do Corretor) e escreva triage.tsv na pasta da rodada com a ferramenta Write.
  7. Corrija os achados aceitos, execute os testes afetados e faça um commit WIP. Um teste com falha bloqueia a rodada, para que uma correção ruim não chegue ao próximo delta.
  8. Execute mmr close --tests "<comando de teste exato>", ou --tests "none: docs only". Se nada for aceito, omita --tests. Siga a linha Next: que ele imprime.

triage.tsv é separado por tabulações, uma linha por achado mesclado, e pode ser omitido apenas se todos os revisores responderem "NO BLOCKING ISSUES.":

revisores	sev	loc	status	sumário	nota
terra,opus	P1	src/a.py:42	accepted	Retry descarta o último item	src/a.py: Manter o último item ao retry
terra	P1	src/b.py:9	rejected	Token nulo trava	rToken é não nulo: src/auth.py:30 retorna cedo
  • status é accepted, rejected, ou open. open é apenas para a última rodada permitida, onde uma correção ficaria sem revisão.
  • nota é o que mudou (accepted), a razão citada no código (rejected) ou por que foi deixado (open). As notas accepted e rejected alimentam a lista de correções e o registro do próximo prompt.
  • Rejeite achados fora de fase como "Fora de fase".
  • Os revisores podem responder em qualquer formato, então leia cada resposta você mesmo. Contagens de achados são um palpite. Uma resposta sem tags P0/P1/P2 conta como um achado: Adicione uma linha para o que ela levanta, ou uma linha rejected se ela não levantar nada.

Commits WIP: Mensagem WIP multimodel-review round <N>, escrita em um arquivo e passada com git commit -F, mais as linhas de atribuição da sessão. Nunca envie.

Fases

  1. Código: Rodadas 1-2 revisam o diff completo contra a base. A partir da rodada 3, apenas o delta mais a lista de correções. Os revisores podem abrir qualquer arquivo para contexto. Fora do delta, eles relatam apenas P0, a menos que o delta cause a falha: Então o achado ancora na linha do delta em sua gravidade real.
  2. Limpeza (apenas corretor): Executa antes da Documentação para que qualquer texto escrito aqui receba uma revisão P2.
    • Docs: Atualize apenas docs que se tornaram obsoletos por esta mudança. Apare, não expanda.
    • Testes: Exclua apenas testes de depuração ou scaffolding e testes para código removido. Mantenha testes de regressão.
    • Execute a suíte de testes completa. Se falhar, corrija; se não puder com uma correção pequena, pare e relate.
    • Faça commit, depois escreva cleanup.md na pasta da execução: Cada exclusão com sua razão, e o comando de teste exato e resultado. next --phase docs recusa sem ele.
  3. Documentação: Uma rodada de diff completo em P2, correção, depois uma rodada delta. Então a fase termina; qualquer coisa restante é registrada como aberta.
  4. Final: Uma rodada de diff completo com todos os revisores, apenas P0/P1. Se um achado for aceito, corrija-o e execute uma rodada delta. Se ainda falhar, marque-o como aberto; o auxiliar para a execução.

Convergência

  • Uma rodada está limpa quando o corretor não aceita nenhum achado na gravidade da fase. Achados rejeitados com uma razão citada no código não bloqueiam.
  • Uma fase converge em sua primeira rodada limpa.
  • Nova evidência após a convergência do Código (execução de dispositivo ou emulador): Atualize o código ou texto afetado uma vez, faça commit, depois execute mmr next --phase evidence --note "<o que a execução mostrou e o que mudou>", uma rodada delta em P0/P1/P2. O Código reabre apenas se um P0/P1 for aceito, e close diz isso.
  • Em um limite de fase ou na parada forçada: Pare e relate o que sobrou.

Regras do corretor

  • Mescle e dedupe, mantendo todos os revisores que levantaram um achado, para que as estatísticas permaneçam honestas. Verifique cada achado contra o código; rejeite os não verificáveis com uma razão de uma linha.
  • Julgue os achados apenas pelo código, independentemente de quem os levantou. Você também é um modelo Claude, então mantenha os achados dos revisores Claude no mesmo padrão. Rejeitar um achado levantado por 2+ revisores, ou qualquer P0, precisa de uma citação de código específica; o relatório lista estes como disputados para o proprietário.
  • Menor correção. Sem refatorações, sem novos recursos. Adicione um teste de regressão apenas para bugs reais P0/P1.
  • Escreva menos prosa: Prefira deletar ou restringir uma frase errada a adicionar uma. Novos comentários têm no máximo uma linha. Não adicione novas seções de doc durante a revisão.
  • Se um hook recusar um caminho, pare e relate ao proprietário. Nunca contorne, com copy shell ou qualquer outro meio.
  • Mantenha comandos shell seguros para dcg: Escreva arquivos com a ferramenta Write e não coloque variáveis, globs ou redirecionamentos para caminhos de variáveis em comandos.

Concluído

Execute na convergência e em qualquer parada.

  1. Execute mmr archive para arquivar cada chat Codex, incluindo reexecuções.
  2. Execute mmr report. Ele imprime rodadas por fase, a tabela de revisores, itens abertos, achados disputados, comandos de teste e o comando squash, e salva report.md.
  3. Relate ao proprietário, curto e com a resposta primeiro: Rodadas por fase, itens abertos, comandos exatos de validação e resultados.
  4. Mostre um visual simples por revisor, inline: Achados levantados, aceitos, rejeitados, únicos, P0-P1 vs P2, rodadas limpas, média de minutos por rodada. Nomeie seu vencedor em uma linha. A regra padrão é mais achados únicos P0/P1 aceitos, e você deve dizer se a anula, já que também está julgando seu próprio modelo.
  5. Deixe os commits WIP no lugar, porque rodadas de evidência precisam do intervalo delta. Pergunte com um botão se deve fazer squash agora, e execute o squash a partir do relatório apenas se for sim.

Alterando esta skill

Esta pasta é o repositório público github.com/dknchris/multimodel-review. Faça commit de cada alteração e envie apenas quando o proprietário disser. O código do seletor é assets/picker.js: mmr picker o carrega do CDN apenas quando seu commit mais recente é enviado, e o envia inline, que é mais lento, até lá. Execute python3 tests/test_mmr.py após cada alteração.

Habilidades Relacionadas