Como usar
O que é. Três partes: o problema, uma skill grátis que junta o Claude e o Codex para uma IA revisar a outra, e o roteiro do revisor que uso na minha empresa.
O que não é. Não é um teste nosso da skill. Nós não rodamos o Claudex Loop. Tudo o que está na parte 2 saiu do README oficial do projeto, lido em 15/09/2026. O que é nosso está na parte 3.
Por onde começar. Se você não usa Claude Code nem Codex, vá direto para a parte 3. O roteiro serve para qualquer entrega, feita por IA ou por gente.
Três palavras antes. Codex é a IA da OpenAI que programa. Claude Code é o Claude trabalhando direto nos arquivos do seu computador. Skill é um manual de tarefa: você instala e a IA passa a seguir aquele passo a passo.
Parte 1. O problema: a IA corrigindo a própria prova
Pergunta para a IA se o plano que ela acabou de escrever está bom. Ela vai dizer que sim. Quem escreveu confere com os mesmos olhos que escreveram, e o erro que passou na hora de escrever passa de novo na hora de conferir.
Com gente é igual: ninguém corrige a própria prova. A regra que resolve cabe numa frase: quem faz não aprova. A segunda revisão vem de quem não construiu, com a obrigação de mostrar a evidência de cada erro.
Libere as partes 2 e 3
Deixe seu e-mail e abra agora a instalação da skill grátis e o roteiro do nosso revisor em passos, com o texto pronto para colar. Sem spam: só os próximos guias.
Parte 2. A skill grátis: Claudex Loop
O que é. Um conjunto de skills gratuito, com licença aberta (MIT), criado pelo Chase AI. Endereço: github.com/chaseai-yt/claudex-loop
Como funciona, em 4 fases.
- Reconhecer. A IA com quem você está conversando lê o que já existe no projeto, ou pesquisa o assunto quando o projeto começa do zero, e entrega a lista do que está supondo, cada item com a fonte.
- Perguntar. Ela resolve com você só as decisões que mudam o resultado, junta as perguntas que não dependem uma da outra e escreve o plano com critérios de pronto que dá para observar e o comando que prova cada um.
- Revisar o plano. A outra IA lê o plano e o projeto e devolve os erros com evidência. Quem coordena decide o que aceita, corrige e devolve na mesma conversa. Para quando chega ao limite de rodadas (5 no padrão) ou quando o revisor dá o veredito: aprovado, revisar ou travado.
- Construir e inspecionar. Você escolhe quem constrói, Claude ou Codex. Quem inspeciona o resultado é sempre a outra, numa conversa nova.
Começando no Claude Code: o plano é do Claude, a revisão do plano é do Codex, a construção é do Claude (padrão) e a inspeção final é de um Codex novo. Começando no Codex, os papéis se invertem.
As regras que valem copiar mesmo sem instalar nada.
- Na revisão, o Codex só lê. Não mexe em arquivo.
- A aprovação fica presa àquela versão do plano. Mudou o plano, a aprovação cai.
- Mudou o código depois da inspeção, precisa de nova inspeção.
- Travado, erro de execução e fim das rodadas aparecem como são. Nunca viram aprovação.
- Resposta vazia não conta como aprovação.
- Pedir revisão do plano não autoriza construir. As decisões que pesam continuam com você.
- O próprio autor avisa: zero achado é um resultado válido, e muito achado não é nota de qualidade.
O que você precisa ter antes.
- Claude Code e Codex instalados, com login feito nos dois.
- Python 3.10 ou mais novo.
- Nenhuma chave de API separada e nenhum pacote extra do Python.
Para conferir, no terminal:
claude --version claude auth status codex --version codex login status
Como instalar no Claude Code. Dentro do Claude Code, um comando de cada vez:
/plugin marketplace add chaseai-yt/claudex-loop
/plugin install claudex-loop@claudex-loop
Como usar. No Claude Code, o fluxo completo sai com /claudex-loop:claudex-loop e só a revisão do Codex com /claudex-loop:codex-review. Também aceita o pedido escrito, por exemplo:
claudex this plan, mode=review, plan=PLAN.md, rounds=3
Onde ver a discussão. O plano fica em PLAN.md. O registro de cada achado, do que foi decidido, dos modelos usados e das provas fica em PLAN-REVIEW-LOG.md.
No Codex ou sem o plugin. Clone o repositório e copie todas as pastas de skills juntas (copiar só uma não funciona). No macOS ou no Linux, de dentro da pasta do repositório:
mkdir -p ~/.agents/skills ~/.claude/skills cp -R skills/. ~/.agents/skills/ cp -R skills/. ~/.claude/skills/
Depois abra uma sessão nova. Atualizar é git pull e copiar de novo.
O número que o autor divulga, com a ressalva dele. A primeira execução completa relatada somou 55 achados em 5 rodadas no plano de um CRM. O próprio README diz que é um exemplo ilustrativo, sem comparação controlada.
Parte 3. O roteiro do nosso revisor, em passos
Na minha empresa quem faz não aprova. Entrega grande passa por um revisor de IA separado, que não participou do trabalho e tem uma função só: tentar provar que a entrega está quebrada. E o Codex, que é de outra empresa, tem na mesma pasta em que o Claude trabalha uma lista própria do que conferir quando revisa.
O roteiro:
- Separe quem faz de quem confere. O revisor só lê. Ele aponta, e quem fez corrige.
- Liste tudo o que a entrega afirma. Documento, relatório, mensagem de "pronto". Cada frase vira um item para testar.
- Parta do princípio de que está quebrado. Para cada item: o arquivo existe? O comando roda? O número bate? Dois documentos dizem a mesma coisa?
- Recuse o relatório de quem fez como prova. Confira na origem, sempre.
- Procure o silêncio. O que foi prometido e não aparece em lugar nenhum da entrega.
- Todo achado com evidência que qualquer pessoa reproduz. Sem evidência, não entra.
- Dê o veredito por regra fixa. Um problema crítico ou mais: reprovado. Nenhum crítico e algum alerta: aprovado com alertas. Nada: aprovado. Crítico bloqueia, sem "talvez".
- Marque o que não deu para checar. Com o motivo. Isso nunca vira aprovado em silêncio.
- Desconfie de aprovação que não olhou nada. Checagem que leu zero arquivo só prova que está ligada.
- Depois da correção, confira de novo na fonte. Quem fez diz que corrigiu; o revisor testa item por item.
O que ele pegou numa entrega real de 10/08
- Rodada 1: 3 achados (1 bloqueio, 1 alerta e 1 ajuste pequeno), 14 conferências aprovadas e 4 itens marcados como não conferidos, com o motivo: o revisor não tinha acesso ao sistema ao vivo.
- O bloqueio: quem pedia para sair ia seguir recebendo mensagem automática. A conferência de quem fez tinha 30 itens, e nenhum olhava isso.
- Rodada 2: as 12 correções pedidas foram conferidas na fonte, uma a uma, e as 12 estavam certas. Apareceu 1 ajuste pequeno novo: um documento tinha ficado para trás do que já estava feito.
- Resultado: 4 achados no total. O que impedia de ir ao ar foi resolvido antes de ir ao ar. Veredito final: aprovado com alertas.
Outro recibo, de 12/09
Numa entrega de 12/09, o verificador automático reprovou 59 itens na primeira execução e terminou em 0 depois das correções. No mesmo dia, uma checagem de senhas e chaves vazadas passou limpa tendo lido 0 bytes: estava ligada e não tinha olhado nada. O passo 9 existe por causa disso.
Texto para colar numa conversa nova
Use numa conversa que não participou do trabalho. Troque o que está entre colchetes.
Você é o revisor desta entrega. Você não fez o trabalho e não vai consertar nada: só lê e aponta. Seu objetivo é tentar provar que a entrega está quebrada. 1. Liste tudo o que a entrega afirma: o que diz que faz, números, arquivos, o que diz estar pronto. 2. Confira cada afirmação nas fontes abaixo. O relatório de quem fez não conta como prova. 3. Procure o que foi prometido e não aparece. 4. Cada problema vem com a evidência: onde está e como qualquer pessoa confere. 5. Classifique cada problema: crítico (impede de usar), alerta ou ajuste. Sem evidência, não entra. 6. O que você não conseguiu conferir, marque como "não conferido" e diga o motivo. 7. Veredito: um crítico ou mais = reprovado; nenhum crítico e algum alerta = aprovado com alertas; nada = aprovado. A entrega: [descreva ou cole aqui] As fontes para conferir: [cole os arquivos, links ou dados]