m_review — Revisão Cruzada e Melhoria

O que m_review — Revisão Cruzada e Melhoria faz?

O revisor não modifica o código, apenas deixa notas de revisão. A correção é feita pelo agente que executou esta skill, após verificar diretamente as críticas.

Entrada

• <ID>: ID do plano a ser revisado. Devem existir plan/<ID>_plan_*.md e impl/<ID>_impl_*.md.
• <Agente>: claude | codex | agy. Como o objetivo é a revisão cruzada, use, se possível, um agente diferente do que está sendo executado atualmente.
• [Modelo]: Se omitido, usa o modelo padrão de cada CLI.

Procedimento

1. Fixar o alvo da revisão: Se houver alterações não commitadas, pergunte primeiro se deseja commitar. Verifique o hash do commit de implementação nas notas de implementação.
2. Identificar o nome do modelo (para usar no nome do arquivo):
   • codex: modelo especificado; se não, o model em ~/.codex/config.toml
   • claude: chave modelUsage da saída JSON
   • agy: modelo especificado; se não, o model em ~/.gemini/settings.json; se também não existir, default
3. Executar o revisor: Preencha os placeholders {ID}, {PLAN}, {IMPL} (caminhos reais dos arquivos), {COMMIT} e {REVIEWER} no prompt localizado em review_prompt.md (pasta desta skill), crie um arquivo temporário (prompt.txt) e salve o resultado como review/<ID>_review_<Agente>-<Modelo>.md.
   • codex: codex exec --sandbox read-only --ephemeral [-m <Modelo>] -o review/<Arquivo> - < prompt.txt
   • claude: claude -p --tools "Read,Grep,Glob" --output-format json [--model <Modelo>] < prompt.txt → salva o campo result do JSON
   • agy: agy --sandbox --mode plan --output-format json [--model <Modelo>] -p "$(cat prompt.txt)" < /dev/null → salva o campo response do JSON
   • A revisão leva de 5 a 15 minutos. Execute em segundo plano ou com um timeout longo. O stdin deve ser redirecionado para um arquivo ou /dev/null (caso contrário, o codex pode travar aguardando entrada).
   • Ao final, use git status para verificar se o revisor não modificou nenhum arquivo.
4. Verificar as críticas: Para cada item, confirme diretamente no código e, se possível, reproduza o problema. Classifique como Válida / Parcialmente válida / Rejeitada (motivo).
5. Melhoria:
   • Problemas claros: corrija imediatamente e adicione testes de regressão em test_*.py para evitar recorrência.
   • Problemas que exigem decisão: numere como D1, D2… e pergunte ao usuário um de cada vez. Ofereça 2 a 3 opções, indicando a recomendação com (recomendado) e o motivo. Se necessário, verifique as opções com experimentos primeiro.
6. Registro: Crie review/<ID>_refine_<Agente>-<Modelo>.md com o modelo abaixo (com base no agente que executou esta skill). Se o mesmo ID for revisado novamente, adicione uma seção ## <Data> <Nome do arquivo de revisão> ao arquivo de refinamento existente. Reflita as alterações também nos documentos do plano e nas notas de implementação (marcações de pendência, mudanças em relação ao plano, etc.). Para arquivos modificados por agentes diferentes do que está na execução, registre as alterações conforme as regras de AGENTS.md.
7. Finalização: Reexecute a validação automática e as execuções reais necessárias, depois reporte os resultados e faça o commit (regras de mensagem em AGENTS.md).

Modelo (review/<ID>_refine_<Agente>-<Modelo>.md)

# [<ID>] Aplicação da Revisão

## <Data> review/<ID>_review_<Agente>-<Modelo>.md

| ID | Julgamento | Tratamento |
| :--- | :--- | :--- |
| <ID>-R1 | Válida (<método de verificação>) | ✅ <correção> / ⏸ Decisão D1 / ✖ Rejeitada: <motivo> |

### Decisão
- ✅ **D1 (<ID>-R?)** <pergunta> → Decisão: <escolha> (<motivo>)

### Verificação
<testes e resultados após a correção>