Documentação e apresentação do `/claudex`, um comando slash que…

INEMA

tem este tambem que é como foi criado o conteudo

inema.club (curso iclaudex)

alidação do diretório correto.

Essas proteções existem para evitar que o usuário fique preso, que arquivos sejam lidos incompletos, que dois processos avancem o mesmo ciclo ao mesmo tempo ou que o hook dispare no projeto errado.

19. Principais falhas que o sistema tenta evitar⌗

O /claudex tenta prevenir problemas como:

usuário preso em um hook quebrado;
arquivo de estado escrito pela metade;
duas execuções competindo pelo mesmo ciclo;
loop morto mantendo um lock falso;
ciclos abandonados bloqueando novos ciclos;
execução no projeto errado;
encerramento sem feedback claro;
plano aprovado sem revisão suficiente.

A proposta é tornar o processo mais seguro e confiável.

20. Uso em projetos reais⌗

O exemplo mostrado envolve a criação de uma página mais complexa, com rastreamento de sessões e análise de comportamento do usuário.

Nesse tipo de projeto, um plano simples poderia deixar passar muitos detalhes.

Com o /claudex, o plano fica mais completo porque passa por revisões sucessivas e considera consequências de segunda e terceira ordem.

O resultado é um planejamento mais detalhado antes de começar a implementação.

21. Comparação com um plano feito apenas pelo Claude⌗

O conteúdo mostra que um plano feito apenas pelo Claude tende a ser mais frágil.

Já um plano revisado pelo /claudex fica mais detalhado, estruturado e robusto.

A diferença aparece principalmente na profundidade das fases, na antecipação de riscos e na clareza das etapas.

O objetivo não é garantir que tudo saia perfeito, mas aumentar a chance de executar com menos retrabalho.

22. Aplicações além de código⌗

Embora o foco seja desenvolvimento de software, a ideia pode ser aplicada a outros tipos de criação.

O mesmo fluxo de planejamento e revisão poderia ser usado para:

apresentações;
documentos;
planilhas;
projetos técnicos;
arquitetura de produto;
planejamento de features;
especificações de sistemas.

O ponto central é usar modelos diferentes para criticar e melhorar um plano antes da execução.

Conclusão⌗

O /claudex é uma automação para transformar planejamento em um processo mais rigoroso.

Ele usa Claude para criar e revisar o plano, Codex para criticar tecnicamente, hooks para controlar o ciclo, arquivos de estado para manter contexto e camadas de segurança para evitar falhas.

A grande ideia é: não comece construindo em cima de um plano fraco.

Primeiro, faça o plano ser testado, criticado e melhorado. Depois execute.

Resumo geral⌗

O conteúdo apresenta o /claudex, um comando criado para fazer Claude Code e Codex trabalharem juntos na fase de planejamento. A ideia central é simples: antes de construir qualquer coisa, o Claude cria um plano, o Codex revisa criticamente esse plano, o Claude corrige, e esse ciclo se repete até o plano ficar mais robusto.

O objetivo é evitar começar uma implementação com um plano fraco, vago ou cheio de riscos escondidos.

1. Por que planejar melhor antes de construir⌗

A ideia inicial é que muita gente prefere construir logo, mas quanto melhor for o planejamento, menos retrabalho acontece depois.

Quando o plano é mal feito, o desenvolvimento vira um ciclo de correções, idas e vindas, bugs conceituais e mudanças no meio do caminho. O /claudex tenta resolver isso antes da execução.

Ele transforma a etapa de planejamento em um processo mais rigoroso, onde o plano é testado, criticado e melhorado antes de virar código.

2. O que é o `/claudex`⌗

O /claudex é um comando slash que junta Claude Code e Codex.

O Claude Code atua como o criador e revisor do plano. O Codex atua como um avaliador crítico, analisando falhas, lacunas e riscos.

Em vez de o usuário precisar pedir manualmente “revise isso”, depois “corrija aquilo”, depois “revise de novo”, o comando automatiza esse ciclo.

3. Como o ciclo principal funciona⌗

O fluxo principal é:

O usuário descreve o que quer construir.
Claude Code cria um plano inicial em um arquivo PLAN.md.
Codex analisa esse plano e aponta problemas.
Claude Code lê os achados do Codex.
Claude atualiza o plano.
O sistema verifica se já chegou ao número desejado de rodadas.
Se ainda não chegou, repete.
Se chegou, o plano é finalizado.

O resultado esperado é um plano mais forte antes da execução começar.

4. Número de rodadas⌗

O comando permite escolher quantas rodadas de revisão serão feitas.

O padrão costuma ser 3 rodadas, porque isso já captura a maior parte dos problemas importantes sem gastar tokens demais.

Também é possível usar 1, 2, 5 ou mais rodadas, mas quanto mais rodadas, maior o custo em tokens e tempo.

A recomendação prática é usar 2 ou 3 rodadas para a maioria dos casos.

5. O papel do Claude Code⌗

O Claude Code é responsável por:

criar o plano inicial;
ler os achados do Codex;
revisar o PLAN.md;
integrar melhorias;
continuar o ciclo até o plano ser finalizado.

Ele é como o “construtor” ou “planejador principal”.

Mas, sozinho, ele pode deixar passar pontos importantes, especialmente quando o prompt inicial é vago.

6. O papel do Codex⌗

O Codex atua como um revisor adversarial.

Ele não precisa escrever código nesse fluxo. A função dele é criticar o plano.

Ele procura coisas como:

falhas de design;
premissas erradas;
requisitos ambíguos;
riscos de autenticação;
condições de corrida;
perda de dados;
problemas de rollback;
falhas de observabilidade;
desalinhamento de versões.

Ou seja, ele funciona como um engenheiro sênior revisando o plano antes da implementação.

7. Por que o Codex não precisa escrever código⌗

Um dos pontos importantes é que o Codex é usado para gerar insights, não necessariamente código.

Isso torna o fluxo mais barato e mais eficiente.

Em vez de pedir para o Codex construir a solução inteira, ele apenas avalia o plano do Claude e diz onde ele pode falhar.

Depois, o Claude usa essas críticas para melhorar o plano.

8. O comando `/claudex plan`⌗

O comando principal é o /claudex plan.

Ele recebe a descrição da funcionalidade ou projeto que o usuário quer construir.

Exemplo conceitual:

/claudex plan criar uma página com rastreamento de sessões

A partir disso, o Claude cria um plano e o ciclo de revisão começa.

Também é possível informar arquivos de escopo e arquitetura para o Claude ler antes de planejar.

9. Outros comandos disponíveis⌗

Além de plan, existem outros comandos úteis.

O /review serve para o Codex apenas auditar o que já existe e comentar, sem alterar automaticamente

corrida; * falta de estratégia de rollback; * problemas de versionamento; * pontos frágeis na execução.

Depois disso, o Claude Code usa esses achados para revisar o plano.

20. Resumo geral⌗

O /claudex é uma automação para melhorar planos de desenvolvimento antes de escrever código.

Ele faz o Claude Code gerar o plano e usa o Codex como revisor crítico.

O principal benefício é evitar começar uma feature com um plano raso, mal especificado ou perigoso.

Na prática, ele substitui um fluxo manual de revisão por um ciclo automatizado, com limite de rodadas, arquivo de estado, logs e comandos auxiliares.

A ideia central é: planeje melhor antes de construir.

er levar essa ideia para o mundo open source.

A visão dele é que, no futuro, você poderia usar modelos locais em vez de depender de Claude Code e Codex.

Talvez um modelo open source precise de mais ciclos, como 3, 4 ou 5 rodadas, para chegar a um plano bom. Mas o princípio seria o mesmo: usar várias rodadas de crítica e revisão para chegar a um plano mais sólido.

10. Pré-requisitos⌗

O autor diz que os pré-requisitos não são muito complicados.

O ponto mais importante é ter o plugin do Codex instalado.

No repositório, ele inclui instruções explicando como instalar esse plugin e como executar os comandos.

11. Problema que o `/claudex` tenta resolver⌗

Sem esse comando, o fluxo manual seria algo assim:

Claude Code gera um plano.
Você roda /codex para pedir uma revisão adversarial.
Codex aponta problemas.
Você pede ao Claude Code para atualizar o plano.
Talvez você rode o Codex de novo.
Depois repete tudo manualmente.

O /claudex automatiza esse vai e volta.

Ele transforma um processo manual e repetitivo em um único comando que coordena as revisões automaticamente.

12. Por que existe um limite rígido de rodadas⌗

O autor explica que, se você simplesmente disser para modelos de linguagem “conversem entre si até o plano ficar bom”, isso pode sair do controle.

Às vezes roda uma vez. Às vezes cinco. Às vezes o modelo “alucina” e continua por 10 rodadas ou mais.

Por isso, o /claudex tem um limite fixo de rodadas.

Esse limite evita desperdício de tokens e garante que o processo termine quando deve terminar.

13. O papel do stop hook⌗

O stop hook é um mecanismo que força uma parada rígida no processo.

O autor compara isso a apertar “Esc” quando o Claude Code está executando algo.

A diferença é que, nesse caso, a parada acontece automaticamente e de forma previsível quando o número máximo de rodadas é alcançado.

Isso impede que o processo continue indefinidamente.

14. O arquivo de estado em YAML⌗

O sistema usa um arquivo de estado em YAML.

Esse arquivo funciona como um “bloco de notas” interno do processo.

Ele registra informações como:

em qual modo o sistema está;
qual fase está acontecendo;
em qual rodada de revisão o processo está;
qual é o número máximo de rodadas;
qual é o tópico ou feature sendo planejada;
quais são os IDs das revisões anteriores.

Esse arquivo ajuda o sistema a saber exatamente onde está dentro do ciclo.

15. Exemplo de tópico revisado⌗

O autor cita como exemplo a feature:

“Adicionar expiração para links curtos.”

Nesse caso, o Claude Code criaria um plano para implementar essa funcionalidade.

Depois, o Codex revisaria o plano procurando problemas técnicos, riscos e melhorias antes da execução.

16. Logs das revisões⌗

Cada rodada gera algum tipo de registro.

O autor menciona que adicionou logging de sessão para permitir revisar o que aconteceu em cada ciclo.

Assim, você pode consultar os achados da rodada 1, da rodada 2, da rodada 3 e assim por diante.

Isso dá mais transparência ao processo.

17. O runner script⌗

O autor entra em uma parte mais técnica sobre o runner script.

Esse script é o que o hook entrega ao Claude quando chega a hora de executar a próxima etapa.

Ele contém o prompt que será usado para pedir a revisão adversarial do plan.md.

Esse prompt é relativamente fixo, mas o autor diz que poderia ser tornado mais dinâmico.

18. O que o script Bash faz⌗

O script Bash executa algumas etapas:

Escreve o prompt em um arquivo.
Chama o Codex com esse prompt.
Faz streaming da atividade no terminal.
Captura os achados de cada rodada.
Organiza os resultados como “findings round one”, “findings round two” etc.

Ou seja, ele coordena a comunicação entre os arquivos, o Codex e o terminal.

19. Resultado esperado de cada rodada⌗

A cada rodada, o Codex produz uma lista de achados.

Esses achados servem para melhorar o plano.

Por exemplo:

problemas de arquitetura;
requisitos ambíguos;
premissas erradas;
riscos de autenticação;
condições de

1. Ideia principal do `/claudex`⌗

O /claudex é um comando slash criado para fazer o Claude Code e o Codex trabalharem juntos antes de começar a construir uma funcionalidade.

A ideia é simples: em vez de aceitar o primeiro plano que o Claude Code gera, o Codex entra como uma espécie de revisor técnico crítico, analisando o plano antes da execução.

Em outras palavras, o objetivo é evitar que você comece a desenvolver algo em cima de um plano fraco, vago ou mal pensado.

2. Como funciona o ciclo de revisão⌗

O fluxo básico é:

O Claude Code cria rapidamente um arquivo de plano, geralmente em Markdown.
Esse plano pode ser bom, médio ou fraco, dependendo da clareza do prompt inicial.
O Codex analisa esse plano como se fosse um engenheiro sênior adversarial.
Ele aponta problemas, riscos, ambiguidades e falhas.
O Claude Code revisa o plano com base nesse feedback.
Esse ciclo se repete algumas vezes.
Quando o plano está maduro, ele é “travado”.
Só depois disso a execução começa.

O autor chama esse processo de grilling, algo como “colocar o plano na pressão” ou “interrogar o plano tecnicamente”.

3. Número de rodadas de revisão⌗

Por padrão, o /claudex roda 3 ciclos de revisão.

Você pode configurar para rodar mais, como 5 ou 10 rodadas, mas o autor não recomenda 10 porque isso gastaria muitos tokens.

A lógica é que 3 rodadas já costumam ser suficientes para melhorar bastante o plano inicial sem desperdiçar muitos recursos.

4. Por que isso funciona no plano de US$ 20⌗

Um ponto importante é que o Codex não está escrevendo código diretamente nesse fluxo.

Ele está apenas gerando insights, críticas e recomendações para que o Claude Code melhore o plano.

Isso torna o processo mais leve e viável dentro de um plano mais barato, porque o uso do Codex fica focado em revisão estratégica, não em produção completa de código.

5. Diferença entre gerar código e revisar plano⌗

O autor explica que sim, o Codex poderia escrever código.

Mas, nesse caso, ele não precisa fazer isso.

A função dele aqui é revisar o raciocínio do Claude Code antes da implementação. Isso é útil porque muitas falhas aparecem antes mesmo de escrever código: requisitos vagos, design ruim, falta de segurança, ausência de rollback, problemas de autenticação, concorrência etc.

Ou seja, o /claudex tenta resolver problemas na fase de planejamento, quando ainda é mais barato corrigir.

6. Comandos disponíveis⌗

O comando principal é:

/claudex plan

Esse é o mais importante. Ele recebe uma descrição em inglês comum, ou linguagem natural, explicando o que você quer construir.

Também existem outros comandos:

/claudex cancel Serve para cancelar uma execução em andamento.

/claudex restart Serve para reiniciar o processo.

/claudex rollback Serve para remover arquivos temporários ou desfazer resíduos deixados por um cancelamento ou execução anterior.

O autor menciona que existem flags adicionais disponíveis no repositório.

7. Parâmetros do comando `/claudex plan`⌗

Quando você digita /claudex plan, o comando aceita alguns parâmetros.

O principal é a descrição da feature, ou seja, aquilo que você quer construir.

Também existe um parâmetro para definir o número total de rodadas de revisão.

Por padrão, esse número é 3.

Exemplo conceitual:

/claudex plan "adicionar expiração para links curtos"

Nesse caso, o Claude Code criaria um plano para implementar expiração em short links, e o Codex revisaria esse plano em rodadas.

8. O repositório do projeto⌗

O autor mostra que existe um repositório público com o código do /claudex.

Ele diz que talvez não mantenha esse repositório para sempre, mas pretende continuar melhorando a ideia conforme as ferramentas evoluírem.

Ele também menciona que, no futuro, talvez Codex ou Claude Code deixem de ser as melhores opções. Por isso, a arquitetura foi pensada para poder ser adaptada a outros modelos.

9. Possibilidade de usar modelos locais no futuro⌗

Um ponto interessante é que o autor quer

github.com/inematds/iclaudex ↗

/claudex — Codex questiona os planos do Claude Code antes de você construir

Este é um comando slash que eu montei chamado /claudex, que une forças entre Claude Code e Codex para você parar de construir em cima de planos medianos.

O fluxo é este:

→ Claude Code rascunha um plano em Markdown com base no seu prompt
→ Codex testa o plano sob pressão, como um engenheiro sênior adversarial
→ Claude Code revisa o plano com base nos achados
→ Repete por 3 rodadas por padrão — dá para aumentar para 5 ou 10, mas você vai queimar tokens
→ O plano é travado → você executa

O grande diferencial é que isso roda no plano de US$ 20, porque o Codex não está escrevendo código — ele só está gerando insights para o Claude Code agir.

Cada rodada já vem com uma persona diferente embutida:

→ Rodada 1: questiona falhas de design, premissas quebradas e especificações ambíguas
→ Rodada 2: caça lacunas de autenticação e condições de corrida — aquelas coisas que o Claude Code sempre passa correndo
→ Rodada 3: pensa em segurança de rollback, versionamento e maleabilidade

Por baixo dos panos, ele usa um stop hook para impor um corte rígido no número máximo de rodadas, então ele não consegue alucinar e entrar em 10 ciclos. Também usa um arquivo de estado em YAML que funciona como um bloco de notas, acompanhando em qual fase e rodada você está.

Isso substitui o fluxo que eu vinha usando há meses — pagar uma assinatura do Cursor só para o Codex detonar os planos do Claude Code — por um único comando slash que internaliza todo esse vai e volta.

Comandos incluídos: /claudex plan, cancel, restart, rollback — com todas as flags no repositório.

Diagrama visual do fluxo: https://app.excalidraw.com/l/6djVV8pnCbO/61FndaBXWE4

Também incluí os prompts que usei para fazer engenharia reversa da própria construção, então, caso você queira fazer um fork disso ou criar sua própria versão conectada a modelos locais no futuro, você tem uma especificação funcional para começar.

Para qualquer pessoa cansada de fazer manualmente o ciclo /codex review → atualizar plano → /codex review de novo toda vez que começa uma nova feature.

O Claudex, um fluxo que combina Claude Code + Codex para melhorar planos antes de começar a construir.

O ponto central é: em vez de deixar o Claude Code criar um plano e já executar, o /claudex faz um ciclo de revisão. O Claude cria o PLAN.md, o Codex critica o plano, o Claude revisa, e isso se repete por algumas rodadas até o plano ficar mais robusto.

Também o fluxo usa um Stop Hook, que funciona como um “porteiro” no fim de cada turno do Claude. Ele decide se o Claude pode encerrar ou se precisa executar mais uma etapa, como chamar o Codex para revisar.

Outro ponto é arquivo de estado YAML, que guarda informações como modo, fase, rodada atual, número máximo de rodadas, tópico e decisão. Ele serve para o sistema não se perder durante o loop.

O Runner Script, que é o script que leva o prompt de revisão até o Codex, executa a crítica e salva os achados em arquivos como findings-round-1.md.

As revisões são divididas em perfis diferentes: uma rodada como engenheiro sênior, focada em design e premissas; outra como segurança, focada em autenticação, race conditions e perda de dados; e outra como Ops/SRE, focada em rollback, observabilidade e versões.

Também temos importância da fase de sumarização, que evita que o ciclo termine em silêncio. Ela mostra claramente que o plano foi concluído, quantos achados foram tratados e se o loop chegou ao fim.

Depois, as seis camadas de segurança, como tratamento de erro, escritas atômicas, lockfile, validação de diretório e limpeza de loops travados. Tudo isso existe para impedir que o usuário fique preso ou que o processo rode no projeto errado.

CLAUDEX

chatgpt.com ↗