Plan mode: ela lê e planeja antes de tocar no seu código

Você pede uma mudança e ela já sai mexendo nos arquivos. Não perguntou nada, não mostrou o que ia fazer.

Aí você abre o projeto e vê seis arquivos mudados. Entender o que ela fez e desfazer o que não presta dá mais trabalho do que teria dado fazer na mão.

O que corrige isso não é prompt melhor. É ordem: primeiro ela lê, depois ela planeja, você aprova, e só então ela escreve. E existe um modo que impõe essa ordem em vez de pedir.

O atalho

Shift+Tab cicla entre os modos de permissão. Você aperta e o modo atual aparece na tela.

A ordem do ciclo:

O que você quer é o plan. Aperta Shift+Tab até ele aparecer.

No Windows, se o Shift+Tab não responder por causa do runtime do terminal, o atalho alternativo documentado é Alt+M. No aplicativo de desktop não tem atalho: é um seletor de modo ao lado do botão de enviar.

O bloqueio é real, não um pedido

Esta é a parte que muda o valor da coisa toda.

Você pode escrever "não edite nada ainda, só me mostre o plano" no prompt. Às vezes funciona. Às vezes ela entende que aquele arquivo é só um detalhe, mexe, e você descobre depois. Instrução em texto é sugestão — e sugestão se perde quando a conversa fica longa.

O plan mode não é isso. É um modo de permissão: a documentação descreve que nele ela lê arquivos e roda comandos para explorar, e propõe um plano sem editar o seu código. A restrição está na camada de permissão, não na boa vontade dela.

A diferença prática: com prompt, você torce. Com o modo, não tem como sair errado.

O ciclo completo, na ordem

1. Entre no plan mode com Shift+Tab antes de fazer o pedido. Depois é tarde — ela já mexeu.

2. Faça o pedido normalmente. Vale ser generoso aqui, porque nada vai ser escrito:

Quero trocar a autenticação por sessão em cookie por token JWT.
Lê como está hoje e me diz o que precisa mudar, arquivo por arquivo,
antes de escrever qualquer coisa.

3. Ela lê e explora. Abre os arquivos, roda comandos de leitura, entende como funciona hoje. Nada é escrito nessa fase.

4. Ela devolve o plano. E aqui está o momento que economiza a tarde: você lê o plano com o projeto ainda intacto. Se ela entendeu errado, corrigir custa uma frase — não um git reset.

5. Você aprova, corta ou corrige. Coisas úteis a dizer nesse ponto:

• "O passo 3 não: aquele arquivo é gerado, não edite na mão."
• "Faz só os passos 1 e 2 por enquanto."
• "Antes de aprovar: por que você escolheu mexer no middleware em vez do handler?"

6. Aprovado, ela sai do modo e executa.

Editar o plano no seu editor: Ctrl+G

Quando o plano está quase bom e você quer mexer no texto em vez de descrever a correção por conversa, Ctrl+G abre o campo de texto no seu editor padrão. (O Ctrl+X Ctrl+E, do readline, faz o mesmo.)

Você edita, salva, fecha — e o texto volta para a sessão como o seu prompt.

Serve para o caso em que explicar a correção por escrito daria mais trabalho do que fazer a correção: reordenar passos, apagar três itens, reescrever um trecho inteiro.

Quando não usar

Plan mode tem custo: são duas rodadas em vez de uma. Não vale para tudo.

Pula o plano quando:

• Você consegue explicar a mudança em uma frase ("renomeia essa função para X")
• É um arquivo só e você sabe qual
• É experimento descartável, que você vai jogar fora de qualquer jeito

Usa o plano quando:

• A mudança encosta em mais de um arquivo
• Você não sabe direito onde a coisa está implementada
• É código que outra pessoa escreveu
• Já deu errado uma vez nesse mesmo pedido
• É refatoração, migração, ou troca de biblioteca

A regra prática: se você não consegue prever quais arquivos vão mudar, você precisa do plano — porque a surpresa é exatamente o que sai caro.

Um hábito que economiza mais que o atalho

Mesmo fora do plan mode, a frase que muda a maior parte dos resultados é uma só, no fim do pedido:

"...antes de mexer em qualquer coisa."

Ela empurra o diagnóstico para antes da ação. O plan mode é a versão garantida disso — mas a frase já resolve boa parte dos casos em que você esqueceu de apertar Shift+Tab.