Como pedir no prompt os casos de borda que você esqueceu de listar

Fala aí, beleza? O modo de erro mais chato de agente de código não é o código quebrado

é o código plausível

Aquele que roda, passa no olhômetro, e ignora justamente o cenário limite que ninguém escreveu no prompt

Isso nem é achismo meu: a documentação de boas práticas do Claude Code lista essa falha com todas as letras (o Claude produz uma implementação plausível que não trata os casos de borda) e dá a correção junto: sempre forneça verificação (testes, scripts, screenshots), e se você não consegue verificar, não faz deploy

O problema é que a lista de casos de borda que falta é exatamente a que você não sabia que faltava

A boa notícia? Dá pra fazer o modelo levantar essa lista ANTES de encostar em qualquer arquivo 🙂

O que você precisa antes de começar

Nada de exótico aqui, é setup de gente normal:

• Claude Code instalado e um projeto aberto, de preferência um projeto real com histórico, não um hello world
• Entender os modos de permissão, porque o passo a passo inteiro depende disso
• Saber que a ferramenta de perguntas de esclarecimento já vem disponível por padrão
• Ter em mãos os arquivos que você espera que mudem, pra citar no prompt

Que modos de permissão? São estes: default (manual, só leitura), acceptEdits (leitura, edições de arquivo e comandos comuns de filesystem), plan (só leitura), auto (tudo, com checagens de segurança em segundo plano) e dontAsk (só ferramentas pré-aprovadas)

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

O que interessa pra gente é o plan

Ele é um modo de permissão somente leitura: o Claude lê arquivos, explora o repositório, entende o terreno, e não edita o código-fonte até você aprovar o plano

Repara na palavra que faz a diferença: até

O plan mode amarra a edição a um evento, a aprovação do plano, e é a própria aprovação que encerra o modo e troca a sessão pro modo de permissão da opção que você escolheu

Se liga que isso muda o jogo: você pode fazer pergunta idiota, mudar de ideia, pedir de novo, e nada é escrito no disco enquanto você não bater o martelo

E sobre as perguntas de esclarecimento: existe uma ferramenta própria pra isso no Claude Code, a AskUserQuestion, acionada quando o Claude precisa de mais direção numa tarefa com múltiplas abordagens válidas

Ela gera perguntas de múltipla escolha e é especialmente comum no plan mode

Detalhe que já ferrou muita gente: ela está disponível por padrão, mas se você restringir o array de tools, precisa incluir ela na lista, senão o Claude simplesmente não te pergunta nada e chuta

Passo a passo: fazer o Claude levantar os casos de borda no prompt

1. Entre no plan mode antes de qualquer coisa

Shift+Tab                        (aperta até a barra de status mostrar o plan mode ativo)
/plan                            (prefixando um único prompt)
claude --permission-mode plan    (já abrindo a sessão direto no modo)

O erro comum deste passo: mandar o pedido sem conferir que o plan mode está mesmo ativo na barra de status

Fora dele a sessão pode estar num modo que já libera escrita, tipo acceptEdits ou auto, e aí não tem entrevista nenhuma, tem código no disco e você correndo atrás

2. Escreva a tarefa citando os arquivos que devem mudar

Nomear no prompt os arquivos que você espera que mudem foca o plano nos arquivos certos

Preciso adicionar um filtro por status na listagem de pedidos.
Os arquivos que eu espero que mudem: app/pedidos/page.tsx,
lib/queries/pedidos.ts e os testes em tests/pedidos.spec.ts.
Se você achar que precisa mexer em outro arquivo, me diga qual e por quê
antes de propor a solução.

O erro comum deste passo: prompt vago do tipo "melhora a listagem de pedidos"

Prompt vago produz plano vago, e plano vago não tem caso de borda nenhum, tem só boa vontade

3. Peça a entrevista antes da solução

Esse é o passo que faz o trabalho todo

A documentação de boas práticas recomenda, pra features maiores, fazer o Claude te entrevistar e escrever uma spec antes de implementar

Antes de propor qualquer solução, me entreviste sobre:
implementação técnica, UI/UX, casos de borda, preocupações e tradeoffs.
Cave as partes difíceis que eu posso não ter considerado.
Siga me entrevistando até cobrir tudo, e só então escreva a spec completa.

Repara na inversão: você não está pedindo código, está pedindo o pedido

É meta-prompting no GSD na veia, o modelo trabalhando pra montar o enunciado antes de tentar resolver

O erro comum deste passo: aceitar a primeira lista de perguntas e parar por ali

A primeira rodada quase sempre pega o óbvio (campo vazio, usuário sem permissão), a parte boa costuma vir na segunda ou terceira, quando ele já leu mais código

4. Use a palavra think no prompt

A palavra "think" aciona o modo de raciocínio estendido, dando ao Claude mais tempo de computação pra avaliar alternativas

Think about the failure modes here before writing the plan.

O erro comum deste passo: achar que raciocínio extra substitui contexto

Não substitui

Modelo pensando muito em cima de informação errada só produz confiança errada, e isso é pior que dúvida

5. Deixe ele explorar em leitura e responda as perguntas de múltipla escolha

O fluxo recomendado é bem direto: explorar o repositório em modo leitura, usar as perguntas de esclarecimento pras decisões abertas de produto ou API, e só depois escrever o plano de implementação

Quando aparecer aquela múltipla escolha, não passe batido

Aquilo ali é o momento em que o modelo está te dizendo "tem mais de um caminho válido e a escolha é sua", e cada escolha dessas mata ou cria uma família inteira de casos de borda

Se uma opção veio com um nome que você não entendeu, vale pedir explicação em vez de resposta antes de escolher no chute

6. Consolide tudo numa spec escrita

A doc de boas práticas sugere fechar a entrevista escrevendo a spec completa num arquivo, tipo um SPEC.md

Um detalhe honesto aqui: só o CLAUDE.md tem leitura automática confirmada

O arquivo de spec é organização sua, então cite ele no prompt quando entrar no plan mode

Leia SPEC.md e monte o plano de implementação seguindo o que está escrito lá.

O erro comum deste passo: manter tudo no chat

A conversa acaba, a sessão vira outra, e a lista de casos de borda que você levou 20 minutos pra extrair evapora junto

7. Revise o plano proposto de verdade

Pressionar Ctrl+G abre o plano proposto no seu editor de texto padrão, pra edição direta

É ali que você corta item inflado, reescreve passo mal descrito e apaga aquela "melhoria" que ninguém pediu

O erro comum deste passo: aprovar por inércia

O plan mode é conversacional, o primeiro plano não precisa ser aceito, beleza? Peça revisão quantas vezes quiser

8. Aprove só quando estiver certo

Aprovar o plano encerra o plan mode e coloca a sessão no modo de permissão descrito pela opção de aprovação que você escolheu

A partir dali ele começa a editar

Se você quer sair sem aprovar nada, Shift+Tab de novo te tira do plan mode

E se depois de aprovar você quiser planejar outra vez, precisa voltar pro plan mode: Shift+Tab ou prefixando o próximo prompt com /plan

9. Na implementação, exija verificação peça por peça

A recomendação é pedir ao Claude que verifique explicitamente a razoabilidade da própria solução enquanto implementa cada pedaço

Implemente item por item do plano.
A cada peça, verifique explicitamente se a solução é razoável e me mostre
como você verificou (teste, script ou saída de execução).

E fecha com a régua da doc: sempre forneça verificação (testes, scripts, screenshots)

Se você não consegue verificar, não faz o deploy

Simples assim

Quais casos de borda entram no escopo desta tarefa (e quais ficam de fora)

Agora vem a parte que quase ninguém faz: o Claude te devolveu uma lista comprida de cenários limite e você não vai tratar todos

Se tratar, a tarefa de 2 horas vira a tarefa da semana

A triagem que funciona bem é essa:

A linha do meio é a mais importante: o que dá pra verificar fica dentro, o que não dá pra verificar vira risco assumido

E risco assumido não pode virar silêncio

O que ficou de fora entra como item explícito no plano, escrito, do tipo "não vamos tratar upload acima do limite nesta tarefa, fica pro próximo ciclo"

Silêncio no plano vira surpresa em produção, e surpresa em produção sempre chega num sábado 😛

Os casos que se repetem sobem pro CLAUDE.md

Quando você percebe que está pedindo a mesma coisa em toda tarefa, para de pedir no prompt e escreve no arquivo

O CLAUDE.md fica na raiz do projeto e é lido pelo Claude Code no início de toda sessão

Só que tem um jeito certo de escrever ali: a recomendação é que as instruções sejam concretas o bastante pra serem verificadas

A própria doc dá o par de exemplos: escrever "Use 2-space indentation" no lugar de "Format code properly", e "Run npm test before committing" no lugar de "Test your changes"

Sacou o padrão? Instrução que você não consegue checar não é instrução, é desejo

Use headers e bullets pra agrupar as regras, e tome cuidado com o tamanho: o alvo recomendado é menos de 200 linhas por arquivo, porque arquivo longo consome mais contexto e reduz a aderência

Ou seja: CLAUDE.md gigante não deixa o Claude mais obediente, deixa menos

Na prática: o que muda quando a lista vem antes do código

No vídeo abaixo eu monto um projeto do zero com ferramenta agêntica, e o começo dele é um retrato bonitinho do problema deste post

Ao escrever o prompt da landing page, eu listei só as seções obrigatórias (hero, pricing, depoimentos, FAQ) e fechei a lista com um "e outras que achar necessário"

Ou seja: eu delegue pro modelo exatamente aquilo que eu não tinha listado

Eu chamo esse prompt de "o mínimo do mínimo" pra ter um projeto viável, assumindo de cara que eu não ia esgotar os requisitos na primeira mensagem

E olha que eu não fui totalmente vago: no mesmo prompt eu fixei as restrições que eu NÃO queria deixar em aberto, design clean, cores claras, cor principal definida, responsividade total e a stack (HTML, CSS e JS) pra acelerar a geração

Essa é a diferença entre delegar e abandonar

O que eu deixei em aberto foi de propósito, o resto ficou travado

Aí veio a lição visual: o resultado saiu sem a logo

E eu conclui na hora que isso era coisa que EU teria que fornecer, não algo que o modelo poderia adivinhar

Esse é o caso de borda clássico, o que só aparece quando você olha a tela

Se a entrevista tivesse rolado antes, a pergunta "você tem logo, ou eu uso placeholder?" teria vindo do modelo, não do prejuízo

Outras coisas que eu comento por lá e que casam direto com esse fluxo:

• Começar projeto novo no modo planejamento: demora mais pra executar, mas o resultado sai mais robusto
• Abrir um tópico novo a cada nova tarefa ou recurso, pra não misturar contexto e ajudar no consumo de tokens
• Anexar arquivo ao prompt em vez de descrever tudo por escrito, tipo um PDF de referência ou uma foto do layout que você quer imitar
• Desfazer trechos da conversa e voltar pra um ponto anterior quando o rumo não agrada

E teve uma que me pegou de surpresa: eu tinha skills genéricas instaladas na máquina e a ferramenta passou a usar elas sem eu ter pedido nada disso no prompt

Funcionou, mas o alerta fica: excesso de skill é prejudicial e pode aumentar o consumo

Outro incômodo real foi não ver os arquivos sendo construídos direto na tela, tendo que abrir a pasta, o editor ou a aba de diff pra conferir o que foi gerado

E é aí que a régua da verificação deixa de ser papo de documentação e vira necessidade prática: se você não está vendo, você precisa de teste, script ou screenshot pra saber o que aconteceu

Conclusão

O prompt que descobre casos de borda não é prompt mágico nem fórmula secreta (essas coisas toscas)

É um prompt com duas exigências dentro: entrevista antes de solução e verificação antes de deploy

O plan mode existe justamente pra isso, ele te dá uma janela somente leitura onde nada é editado até você aprovar o plano, e você pode gastar o tempo levantando o que faltava

A entrevista puxa os cenários que você não sabia que existiam, a triagem decide quais entram no escopo, o que sobra vira item explícito no plano e o que se repete sobe pro CLAUDE.md

Próximo passo prático? Pega a próxima tarefa REAL do seu projeto, aquela que você ia mandar de qualquer jeito

Aperta Shift+Tab, cita os arquivos que devem mudar e roda a entrevista antes de deixar qualquer arquivo ser tocado

Faça o teste e compara com o que você costuma receber, a diferença aparece já no primeiro plano =)

até o próximo post!