O que Claudex Loop faz?
A conversa atual é responsável pelos requisitos, planejamento e coordenação. O outro provedor revisa o plano. Qualquer provedor pode construir; o provedor que não construiu inspeciona o código final em uma sessão nova.
Resolver papéis uma vez
Identifique o anfitrião real a partir do seu runtime, não do PATH, skills instalados, suposições de nome de modelo ou do repositório. Ambos os CLIs podem estar instalados. Use host=claude no Claude Code e host=codex no Codex. Se a identidade do runtime não estiver disponível, pergunte qual anfitrião o usuário está usando uma vez.
| Anfitrião | Requisitos e plano | Revisor do plano | Construtor padrão | Inspetor final |
|---|---|---|---|---|
| Claude Code | Sessão atual do Claude | Codex | Claude | Sessão nova do Codex |
| Codex | Sessão atual do Codex | Claude | Codex | Sessão nova do Claude |
Honre builder=claude|codex. O inspetor é sempre o outro provedor. O anfitrião permanece coordenador mesmo quando o outro provedor constrói. Para trocar o planejador, inicie a conversa no outro anfitrião; não finja que um revisor CLI é a conversa de planejamento do usuário.
A seleção do modelo é independente dos papéis do provedor. Preserve o modelo selecionado do anfitrião. As chamadas CLI de revisão/construção herdam sua própria configuração, a menos que reviewer_model, builder_model ou inspector_model seja fornecido; mapeie estes para --model do executor naquela invocação. Aplique um *_effort explícito de forma similar. Fable 5.1 e GPT-6 Astra são escolhas explícitas adequadas, não pins obrigatórios. Um modelo na interface do anfitrião não prova qual modelo um CLI separado usará. Relate informações de modelo solicitadas e observadas separadamente; relate um padrão não resolvido do CLI honestamente. Nunca recorra silenciosamente a outro modelo/provedor em caso de falha.
Leia a referência do runtime antes de iniciar um CLI. Resolva seu executor relativo a este SKILL.md instalado, nunca relativo ao projeto sendo revisado. Use caminhos absolutos ao iniciá-lo.
Se o usuário fornecer codex_cli ou claude_cli, mapeie o caminho do executável do provedor selecionado para --cli. Um aplicativo anfitrião pode ter um binário funcional mais novo que o CLI no PATH; verifique o caminho e a versão sem alterar silenciosamente a instalação ou configuração global.
Parâmetros ajustáveis
| Argumento | Padrão | Significado |
|---|---|---|
PLAN_FILE / plan | PLAN.md | Caminho do plano usado em todo o processo, incluindo a transferência de construção |
LOG_FILE / log | PLAN-REVIEW-LOG.md | Transcrição somente de acréscimos |
rounds / MAX_ROUNDS | 5 | Número máximo de rodadas de plano-revisão concluídas |
builder | anfitrião | Provedor que implementa o plano |
research | proporcional à tarefa | none, web, ou aceitação explícita deep |
mode | full | full inclui reconhecimento/entrevista; review começa a partir de um plano existente |
inspect | on | off apenas quando o usuário explicitamente opta por não participar; registre isso |
MAX_FIX_ROUNDS | 2 | Número limitado de tentativas de correção antes de relatar ou assumir o controle |
MAX_INSPECTION_ROUNDS | 2 | Inspeção inicial mais uma após correções |
Eco dos papéis, caminhos, limites de rodadas, modelos solicitados e exclusão de inspeção antes de começar. Preserve a autorização existente: uma solicitação para planejar não autoriza construir; uma solicitação para planejar e implementar sim. Faça a preparação autorizada antes de buscar qualquer aprovação restante.
Fase 0 — Reconhecimento
Para projetos existentes, inspecione código relevante, dependências, chamadores e escritores de estado compartilhado. Leia CONTEXT.md / CONTEXT-MAP.md e ADRs relevantes existentes. Para trabalho verde, pesquise trabalhos anteriores, uma pilha razoável e modos de falha concretos quando útil. Respeite uma profundidade de pesquisa explícita. Pesquisa profunda multiagente requer aceitação explícita e uma ferramenta disponível; caso contrário, use pesquisa direcionada suportada e relate a limitação. Não exija uma ferramenta proprietária de Workflow ou codifique um modelo de agente de pesquisa.
Descubra skills relevantes através do catálogo disponível do anfitrião e dos locais documentados de skills do outro provedor quando acessível. Registre apenas dependências propostas relevantes. Não presuma que MCP, navegador, credenciais ou skills do anfitrião são transferidos para o outro CLI. Verifique as capacidades de construção necessárias antes de confiar nelas.
Apresente um registro de suposições com caminhos de origem ou links de pesquisa. Peça correções para incertezas materiais como um lote. Resolva escolhas rotineiras reversíveis você mesmo quando o usuário autorizou o trabalho; silêncio não é aprovação de uma ação que requer aprovação.
Fase 1 — Estabelecer requisitos
Mantenha um mapa de decisão curto e visível. Pergunte apenas sobre decisões não resolvidas que mudam o resultado. Para cada pergunta consequente, dê a recomendação, por que é importante e o custo de errar. Agrupe perguntas independentes; faça as dependentes sequencialmente. Se o código pode responder, inspecione-o. Ofereça "aceitar todas as recomendações restantes" quando uma longa lista de decisões atrasaria o usuário.
Respeite definições de glossário existentes; resolva linguagem de domínio ambígua. Mantenha contexto somente de glossário preguiçosamente usando CONTEXT-FORMAT.md. Registre um ADR apenas para trocas caras de reverter e não óbvias usando ADR-FORMAT.md.
Escreva o PLAN_FILE resolvido com:
- Objetivo e critérios de aceitação observáveis.
- Abordagem concreta, decisões chave, trocas e não-objetivos.
- Suposições confirmadas com fontes e riscos restantes.
- Requisitos de ferramentas relevantes por provedor, se houver.
- Verificação: comando(s) de prova exato(s), resultados esperados e verificações manuais/visuais quando necessário.
Derive comandos de prova do repositório quando possível. Pergunte apenas quando o que conta como sucesso permanece incerto. Inicie o LOG_FILE somente de acréscimos com papéis, solicitações de modelo, escopo, autorização e limites de rodadas. Mantenha diagnósticos de execução fora do checkout.
Com mode=review, carregue o plano fornecido, preencha apenas lacunas materiais com o usuário conforme necessário e prossiga diretamente para a revisão; não reinicie uma entrevista de requisitos.
Fase 2 — Revisão independente do plano
Use o executor compartilhado no modo review com o --host real, --plan resolvido e modelo/esforço opcionais. A primeira rodada cria uma sessão. Rodadas subsequentes usam --resume <previous-successful-result.json> com o mesmo provedor/modelo/esforço e um arquivo --feedback de autoria do anfitrião contendo disposições. Nunca use um ID de sessão adivinhado, --last ou uma sessão de construção como revisor.
Cada resposta bem-sucedida contém um veredito, descobertas baseadas em evidências, cobertura real e limitações. Preserve a resposta inteira e o caminho do resultado do executor no LOG_FILE.
- APROVADO: nenhum defeito material não resolvido. A aprovação está vinculada ao caminho exato do plano e SHA256. Apresente conselhos e limitações restantes de baixa prioridade; zero descobertas é válido e não é prova de correção exaustiva.
- REVISAR: o anfitrião arbitra cada descoberta. Implemente mudanças de plano justificadas; rejeite sugestões não suportadas com razões. Registre disposições e envie o plano revisado para o mesmo revisor. Evite rediscutir pontos resolvidos sem novas evidências.
- BLOQUEADO / processo falhou / resultado malformado: nunca conte isso como aprovação. Explique a evidência faltante real ou falha operacional. Não queime rodadas restantes em repetições cegas ou mude de provedor silenciosamente.
Pare em MAX_ROUNDS. Apresente descobertas não resolvidas e a posição do anfitrião em vez de fabricar convergência. Um plano alterado requer outra revisão. Antes de construir, execute a verificação de aprovação no plano final. Se o usuário explicitamente escolher prosseguir sem aprovação independente, registre essa substituição e use o caminho autônomo de especificação não revisada; nunca o rotule como aprovado.
Fase 3 — Construir e inspecionar
Apresente o plano revisado, melhorias e limites restantes. Se a implementação ainda não estiver autorizada, peça essa decisão final. Use o construtor selecionado, padronizando para o anfitrião. Leia a referência de construção.
O anfitrião pode implementar diretamente com suas ferramentas normais. Para um construtor diferente, use o modo build do executor compartilhado. Qualquer caminho deve capturar o commit pré-construção, preservar trabalho não relacionado do usuário e carregar o mesmo plano resolvido e contrato de verificação.
Execute as verificações de prova acordadas, inspecione todos os arquivos alterados e revise o resultado através do outro provedor em uma sessão nova de inspect. Forneça o commit pré-construção e a identidade do construtor. Reinspetar após correções aceitas também usa uma sessão nova. Registre descobertas e disposições; reexecute as verificações afetadas após correções.
Se o coordenador assumir a codificação, ele se tornou um construtor. Exija uma inspeção nova do outro provedor de suas alterações; nunca descreva a inspeção anterior como cobrindo edições posteriores. Se ambos os provedores contribuíram com código, registre a autoria e faça cada um inspecionar as alterações do outro; não afirme que nenhum modelo revisou independentemente o código que ele mesmo escreveu. Se o orçamento de inspeção estiver esgotado, relate as descobertas restantes e edições não revisadas explicitamente para a decisão do usuário.
Apresente o diff final, resultados de prova, cobertura de inspeção, descobertas não resolvidas, desvios e rodadas usadas. Honre a autorização existente de commit/push; caso contrário, deixe o diff concreto pronto para aprovação. Publicação externa nunca é implícita apenas por executar o loop.