---
title: "6 princípios de prompts para elevar a qualidade dos resultados do Claude Code"
locale: pt
category: tutorial
category_name: "Tutorial"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/claude-code-prompt-six-principles-and-templates
published_at: 2026-08-23T02:30:01+09:00
---

# 6 princípios de prompts para elevar a qualidade dos resultados do Claude Code

> Explica como transmitir de forma estruturada o contexto, o contrato de saída, o tratamento de exceções e os critérios de validação, em vez de simplesmente pedir ao Claude Code que crie o código. Também oferece modelos de prompts que podem ser aplicados diretamente ao desenvolvimento de novos agentes, à adição de funcionalidades e à correção de erros.

## Key Points

- 1. Antes de iniciar o trabalho, reúna em um único documento o contexto do usuário, o problema a ser resolvido, os critérios de sucesso e as restrições técnicas.
- 2. Especifique a estrutura de arquivos, o formato dos dados, o escopo permitido e as condições de conclusão do resultado em um contrato de saída concreto.
- 3. Defina as exceções previsíveis, como falhas de APIs externas, resultados vazios, dados duplicados e erros de autenticação, bem como as políticas de resposta.
- 4. Divida o trabalho na ordem de revisão do plano, implementação da funcionalidade mínima, testes automatizados e expansão de funcionalidades, verificando os resultados em cada etapa.
- 5. Em vez de solicitar um retrabalho de forma vaga, apresente casos de falha e metas de melhoria mensuráveis e faça a validação com base nas condições finais de aceitação.

Agentes de programação como o Claude Code não são ferramentas que apenas geram um trecho de código, mas ambientes de trabalho capazes de explorar repositórios, modificar vários arquivos e executar testes e comandos. Portanto, a qualidade do resultado depende muito mais de **quão claramente o escopo do trabalho e os métodos de validação foram definidos** do que de quão plausível o texto parece.

Um bom prompt não é uma explicação longa, mas uma especificação de trabalho executável. Ele deve informar não apenas o que criar, mas também por que isso é necessário, quais condições devem ser respeitadas, como tratar falhas e quais critérios devem ser atendidos para que o trabalho seja considerado concluído.

## Primeiro, diferencie: prompt e ambiente de execução

Vibe coding é uma forma de colaboração na qual a intenção é transmitida em linguagem natural e o agente de AI fica responsável pela implementação. No entanto, o fato de uma solicitação ter sido feita em linguagem natural não garante a correção do código nem a estabilidade operacional.

Os seguintes elementos atuam em conjunto no trabalho com Claude Code.

| Elemento | Função | O que verificar no prompt |
|---|---|---|
| Solicitação do usuário | Comunicar o objetivo e o escopo da alteração | Finalidade, prioridades, proibições |
| Contexto do repositório | Fornecer a estrutura e as regras existentes | Framework, comandos de execução, arquivos relacionados |
| `CLAUDE.md` | Fornecer diretrizes de projeto aplicadas repetidamente | Regras de programação, método de teste, convenções de diretórios |
| Permissões de ferramentas | Controlar o escopo permitido para modificação de arquivos e execução de comandos | Comandos que podem ser executados e tarefas que exigem confirmação prévia |
| Conexões externas | Acessar APIs, bancos de dados, servidores MCP etc. | Método de autenticação, limites de confiança, política de falhas |
| Procedimento de validação | Determinar se o resultado atende aos requisitos | Testes, análise estática, itens de verificação manual |

Escrever bem apenas o prompt não resolve todos os problemas. Por exemplo, o Claude Code pode criar código de execução agendada, mas, para que a tarefa seja executada mesmo quando o computador estiver desligado, é necessário um servidor separado, um serviço de CI ou um agendador do sistema operacional. Da mesma forma, o envio de e-mails não pode ser concluído sem as credenciais de autenticação e a permissão de envio de um provedor real.

## Princípio 1. Explique primeiro o contexto, o objetivo e as restrições

Se apenas o nome do resultado for informado, como em `Crie um agente de coleta de notícias`, o agente terá de inferir o usuário, as fontes de dados, o ambiente de execução e os critérios de sucesso. Mesmo para um coletor de notícias semelhante, as fontes e os critérios de classificação necessários para um profissional de desenvolvimento de negócios, um investidor ou um editor de jornal universitário são diferentes.

### Solicitação insuficiente

```text
Crie um agente de coleta de notícias sobre AI.
```

### Solicitação aprimorada

```text
Sou responsável pelo desenvolvimento de negócios de uma startup de TI.
Antes de começar a trabalhar todos os dias, quero verificar rapidamente notícias
nas áreas de AI, computação em nuvem e fintech que possam afetar
parcerias comerciais ou a estratégia de produto.

Objetivos:
- Coletar notícias recentes candidatas para cada palavra-chave especificada.
- Remover notícias com a mesma URL e duplicatas com títulos semelhantes.
- Classificar o impacto como alto, médio ou baixo com base na necessidade
  de tomar uma decisão sobre produto ou parceria dentro de 3 meses.
- Criar um briefing por e-mail em coreano com o resultado.

Restrições:
- Manter a versão do Python e o método de gerenciamento de pacotes do repositório atual.
- Antes de adicionar uma nova biblioteca, explicar sua necessidade e as alternativas.
- Não registrar chaves de API nem senhas de e-mail no código ou nos logs.
- Antes de enviar um e-mail real, gerar apenas um arquivo de pré-visualização.

Primeiro, examine a estrutura do repositório e o método de execução e, depois,
proponha um plano de implementação.
Não presuma informações desconhecidas sobre o ambiente; organize-as como uma lista de perguntas.
```

Um bom contexto inclui os quatro itens a seguir.

1. **Usuário e situação de uso:** quem usa, quando usa e para qual decisão
2. **Objetivo:** qual problema deve ser resolvido, em vez da simples escrita do código
3. **Restrições:** quais tecnologias, regras de segurança e limites de custo ou prazo devem ser mantidos
4. **Não objetivos:** quais funcionalidades estão explicitamente excluídas desta alteração

Definir os não objetivos impede que o escopo cresça indefinidamente. Por exemplo, ao definir que `nesta etapa, a execução agendada e o envio real de e-mails estão excluídos`, é possível validar primeiro, de forma estável, a lógica de coleta e classificação.

## Princípio 2. Transforme o formato de saída em um contrato de saída

`Envie de forma agradável por e-mail` pode ser interpretado de maneira diferente por cada pessoa. Em vez de apenas mostrar um exemplo do formato de saída, é preciso definir também os campos obrigatórios, os valores permitidos, o tratamento de dados ausentes e a ordem de classificação.

```text
Assunto do e-mail:
[Briefing de notícias] {YYYY-MM-DD} Principais notícias de hoje

Formato das notícias no corpo:
1. {Título}
Resumo: {1 a 2 frases em coreano}
Impacto: {alto|médio|baixo}
Motivo da avaliação: {1 frase}
Fonte: {nome do veículo}
Link: {URL original}

Regras de classificação:
1. Em ordem decrescente de impacto
2. Em caso de mesmo impacto, da publicação mais recente para a mais antiga

Estatísticas no rodapé:
- Número total de notícias
- Número de notícias por impacto
- Palavras-chave sem resultados de pesquisa

Restrições:
- Não inventar no resumo números ou afirmações ausentes do texto original.
- Se a data não puder ser confirmada, não estimá-la e marcá-la como 'não foi possível confirmar'.
- Excluir do briefing final os itens sem link.
```

Se o resultado precisar ser transferido entre programas, é recomendável solicitar um esquema JSON ou uma definição de tipos junto com um exemplo legível por pessoas.

```json
{
  "title": "string",
  "summary": "string",
  "impact": "high | medium | low",
  "reason": "string",
  "source": "string",
  "url": "absolute URL",
  "published_at": "ISO 8601 string | null"
}
```

O contrato de saída inclui não apenas o formato, mas também o significado. Se não houver critérios de avaliação que definam o que significa `impact: high`, a sintaxe JSON poderá estar correta, mas os resultados da classificação poderão ser inconsistentes.

## Princípio 3. Especifique situações excepcionais e políticas de recuperação

A qualidade do código operacional se revela mais nos caminhos de falha do que no fluxo normal. O prompt deve especificar as falhas previsíveis, se é possível tentar novamente, as condições para notificar o usuário e quais informações não devem ser registradas.

| Situação excepcional | Exemplo de política recomendada |
|---|---|
| Nenhum resultado de pesquisa | Ignorar a palavra-chave e registrá-la nas estatísticas finais |
| Erro temporário de rede | Tentar novamente apenas um número limitado de vezes, em intervalos definidos |
| Falha de autenticação | Não tentar novamente; interromper imediatamente e orientar a verificação da configuração |
| Limite de uso da API | Respeitar as instruções de espera da resposta e proibir tentativas infinitas |
| Notícias duplicadas | Remover com base na URL normalizada e na similaridade dos títulos |
| Dados em formato incorreto | Preservar o original e isolar apenas o item correspondente |
| Falha no envio de e-mail | Se continuar falhando após novas tentativas, registrar uma notificação alternativa ou o estado de falha |
| Sucesso parcial | Informar separadamente os resultados bem-sucedidos e os itens com falha |

A política pode ser solicitada de forma concreta como a seguir.

```text
Trate o tempo limite da rede como um erro que permite nova tentativa.
Aguarde entre as tentativas e, ao exceder o número máximo,
marque como falha apenas a fonte correspondente.
Como erros de autenticação e solicitações inválidas não serão resolvidos
com repetição, interrompa imediatamente.

Todos os logs de erro devem registrar horário, etapa da tarefa, fonte e tipo de erro,
mas não devem registrar chaves de API, endereços de e-mail completos,
cabeçalhos de autenticação nem o texto integral das notícias.
Diferencie sucesso total, sucesso parcial e falha total pelo status de encerramento do processo.
```

Valores como `tentar novamente três vezes` ou `aguardar 5 segundos` não são respostas universalmente corretas. Eles devem ser definidos no projeto de acordo com os limites oficiais do serviço externo, a urgência da tarefa e o risco de execução duplicada. Tarefas com efeitos colaterais, como pagamentos ou envio de mensagens, podem ser processadas em duplicidade se forem repetidas automaticamente sem garantia de idempotência.

## Princípio 4. Desenvolva gradualmente na ordem: planejamento, implementação mínima e validação

Ao conectar vários serviços externos e a execução automática de uma só vez, fica difícil isolar a causa dos erros. Dividir a implementação em pequenas unidades de validação permite verificar as entradas e saídas de cada etapa.

### Ordem de execução recomendada

1. Examine a estrutura do repositório, os arquivos relacionados e os comandos de execução.
2. Antes de alterar o código, solicite um plano e a indicação dos arquivos que serão afetados.
3. Implemente a função de coleta usando uma única palavra-chave e dados de amostra fixos.
4. Teste separadamente a remoção de duplicatas e a classificação de impacto.
5. Valide o e-mail por meio de uma pré-visualização local, em vez de enviá-lo de fato.
6. Depois que os testes passarem, adicione a integração com o provedor real e a execução agendada.

A primeira solicitação pode ser limitada da seguinte forma.

```text
Execute apenas a etapa 1 agora.
Examine o repositório e informe:
- O ponto de entrada da aplicação atual
- Os módulos e arquivos de teste relacionados
- Os comandos usados para gerenciamento de pacotes e testes
- Os arquivos que provavelmente precisarão ser alterados
- As questões que devem ser decididas antes da implementação

Ainda não modifique os arquivos.
```

Depois de revisar o plano, implemente restringindo o escopo da alteração.

```text
Do plano aprovado, implemente apenas a coleta de notícias
e a remoção de duplicatas.
Não adicione classificação, envio de e-mail nem execução agendada.
Permita a execução com dados de teste fixos e, ao final,
resuma os arquivos modificados e os resultados dos testes executados.
```

Se for possível usar um modo exclusivo de planejamento no ambiente do Claude Code, ele poderá ser utilizado nas etapas de exploração e projeto. No entanto, o fato de um plano parecer plausível não significa que a implementação esteja correta, portanto testes reais e revisão de código devem ser realizados em seguida.

## Princípio 5. Forneça feedback com casos de falha e números

É difícil definir a direção da correção com comentários como `o resultado não está bom`, `o desempenho está lento` ou `a classificação está errada`. É preciso informar o estado atual, o estado esperado, a entrada de reprodução e o intervalo aceitável de alterações.

### Solicitação de ajuste de tamanho

```text
Atualmente, o corpo do e-mail é gerado com cerca de 3.000 caracteres.
Quero reduzi-lo para no máximo 500 caracteres para que possa ser lido rapidamente no celular.
Limite o resumo de cada notícia a 1 ou 2 frases e mantenha o motivo da avaliação.
Associe a URL original ao título e remova a linha separada do link.
Mantenha as estatísticas no rodapé.
```

### Solicitação de ajuste dos critérios de classificação

```text
Dos 10 itens dos dados de teste, 8 foram classificados como 'alto'.
Classifique perspectivas tecnológicas de longo prazo
ou apresentações gerais de produtos como 'baixo'.
Classifique como 'alto' somente quando houver evidências concretas
de que será necessário mudar, dentro de 3 meses, uma decisão sobre preços,
roadmap do produto, resposta regulatória ou parceria.

Nos casos anexados, A e B devem ser classificados como alto, e C como baixo.
Corrija as regras de classificação e adicione esses casos como testes de regressão.
```

### Solicitação de ajuste de desempenho

```text
O tempo médio atual de execução com a mesma entrada de amostra é de cerca de 45 segundos.
A meta é no máximo 30 segundos no mesmo ambiente.
Primeiro, meça o tempo de cada etapa e mostre o gargalo.
Não remova a precisão dos resultados nem o tratamento de erros;
compare os efeitos e os riscos das alternativas de melhoria
e aplique primeiro a menor alteração.
```

Os números de desempenho só podem ser comparados quando o ambiente de medição e os dados de entrada são os mesmos. Não considere que houve melhoria com base no resultado de uma única execução; fixe também o método de medição, a amostra e o estado do cache.

## Princípio 6. Use modelos de prompt por tipo de tarefa

### Modelo para criar um novo agente

```text
[Função e situação]
Sou {profissão/função} e quero resolver {situação problemática}.
Este resultado será usado por {usuário ou sistema posterior}.

[Objetivo]
{resultado a ser alcançado e critérios de sucesso}

[Gatilho de execução]
{execução manual, evento, horário agendado etc.}

[Entrada]
- Fonte de dados: {arquivo/API/banco de dados}
- Campos obrigatórios: {lista de campos}
- Método de autenticação: {variável de ambiente ou método de gerenciamento de segredos}

[Lógica de processamento]
1. {etapa 1}
2. {etapa 2}
3. {etapa 3}

[Contrato de saída]
{formato de arquivo, esquema, modelo, regras de classificação e dados ausentes}

[Tratamento de exceções]
{resultado vazio, tempo limite, erro de autenticação, política de falha parcial}

[Restrições e não objetivos]
- Tecnologias a manter: {itens}
- Proibições: {itens}
- Funcionalidades excluídas desta tarefa: {itens}

[Validação]
- Testes que devem passar: {itens}
- Conteúdo do relatório de conclusão: arquivos alterados, comandos executados,
  resultados dos testes, riscos restantes

Primeiro, examine o repositório e apresente um plano de implementação.
Não presuma informações desconhecidas; faça perguntas.
```

### Modelo para adicionar uma funcionalidade existente

```text
Adicione {nova funcionalidade} ao {nome do agente ou módulo} existente.
A nova funcionalidade deve ser executada depois de {etapa existente A}
e antes de {etapa existente B}.

Lógica detalhada:
- {condições e regras de processamento}
- {formato de entrada e saída}
- {comportamento em caso de falha}

Condições de manutenção:
- Não alterar a interface pública nem o formato de configuração existentes.
- Manter todos os testes existentes.
- Não modificar arquivos não relacionados.

Primeiro, explique o escopo do impacto e os riscos de regressão.
Em seguida, adicione testes que preservem o comportamento existente e implemente a funcionalidade.
```

### Modelo para correção de erros

```text
Reproduza o erro a seguir e corrija sua causa raiz.

Mensagem de erro completa:
{mensagem de erro e rastreamento de pilha após remover informações secretas e pessoais}

Condições de ocorrência:
- Comando de execução: {comando}
- Entrada: {entrada mínima para reprodução}
- Ambiente: {sistema operacional, runtime, versões relacionadas}
- Momento da ocorrência: {em qual etapa}

Comportamento esperado:
{resultado que deveria aparecer em condições normais}

Comportamento real:
{resultado observado atualmente}

Solicitação:
1. Primeiro, reproduza o erro.
2. Explique a causa com base em evidências.
3. Corrija-o com o menor escopo possível.
4. Adicione um teste de regressão que impeça o mesmo erro.
5. Informe os testes executados e os riscos restantes.
```

Ao colar uma mensagem de erro, é preciso remover informações sensíveis, como chaves de API, tokens de sessão, dados de clientes e endereços internos.

## Exemplo completo: solicitação de um agente de briefing de notícias

O exemplo a seguir combina os seis princípios em uma única solicitação.

```text
Sou responsável pelo desenvolvimento de negócios de uma startup de SaaS.
Quero verificar diariamente apenas as notícias sobre mudanças nos mercados
de AI, computação em nuvem e fintech que possam alterar, dentro de 3 meses,
decisões sobre produtos ou parcerias.

Examine o repositório atual e projete uma ferramenta de briefing de notícias.
Na primeira etapa, implemente apenas a funcionalidade que lê uma amostra JSON,
remove duplicatas, classifica o impacto e cria um arquivo HTML de pré-visualização.
Pesquisa na web, envio real de e-mail e execução agendada estão excluídos desta etapa.

Campos de entrada:
- title, url, source, published_at, body

Regras de processamento:
- Considere como duplicatas as URLs normalizadas que forem iguais.
- Mesmo que as URLs sejam diferentes, marque como candidatas a duplicatas
  as notícias com títulos semelhantes.
- Classifique como impacto 'alto' apenas notícias que exijam mudanças concretas,
  dentro de 3 meses, em preços, resposta regulatória, roadmap do produto
  ou decisões sobre parcerias.
- Se não houver evidências suficientes, não presuma uma classificação alta.

Saída:
- Exibir título, resumo de 1 a 2 frases, impacto, motivo da avaliação, fonte e URL.
- Ordenar em ordem decrescente de impacto.
- Exibir no rodapé o total de itens, o número de duplicatas removidas
  e a quantidade por classificação.

Tratamento de exceções:
- Não excluir itens sem campos obrigatórios; registrá-los em uma lista de erros separada.
- Não estimar datas inválidas; mantê-las como null.
- Não registrar nos logs o texto integral das notícias nem informações de autenticação.

Validação:
- Testar entrada normal, entrada vazia, URL duplicada, data inválida
  e ausência de campos obrigatórios.
- Se houver testes existentes, todos deverão passar.

Ordem de trabalho:
1. Examinar a estrutura do repositório e os arquivos relacionados.
2. Apresentar os arquivos a serem modificados e o plano de testes.
3. Não alterar o código antes que eu revise o plano.
4. Após a aprovação, implementar a funcionalidade mínima e informar os resultados dos testes.
```

Essa solicitação não exige que todas as funcionalidades necessárias sejam implantadas de uma só vez no ambiente operacional. O escopo é limitado, e o significado da saída, o tratamento de falhas e os itens de teste são definidos em conjunto, facilitando a avaliação do resultado.

## Critérios de qualidade fáceis de ignorar quando se depende apenas do prompt

Muitas orientações sobre vibe coding se concentram em escrever instruções mais detalhadas. No entanto, outros elementos que determinam a qualidade real são **capacidade de validação, controle de alterações, observabilidade e limites de segurança**.

### 1. Transforme critérios de aceitação em testes

Em vez de dizer `faça funcionar bem`, forneça pares de entrada e saída esperada. Mantenha casos importantes de classificação como testes de regressão para verificar se o resultado continua preservado nas alterações posteriores.

### 2. Não use a autoavaliação do agente como evidência final

O agente dizer que `concluiu` é diferente de os testes terem passado. Solicite que ele informe os comandos executados, os resultados dos testes, os arquivos alterados e os riscos não resolvidos, e uma pessoa deve revisar o diff.

### 3. Minimize permissões e informações secretas

Não forneça de uma só vez acesso a diretórios desnecessários, bancos de dados de produção e credenciais de implantação. Não insira chaves de API diretamente no prompt ou no repositório; use variáveis de ambiente ou um sistema aprovado de gerenciamento de segredos. Não conceda acesso a repositórios sensíveis para servidores MCP ou scripts de origem desconhecida.

### 4. Exija código observável

Em tarefas automatizadas, registre informações necessárias para identificar a causa das falhas, como o estado de cada etapa, erros estruturados, tempo de execução e número de itens processados. Por outro lado, remova dos logs informações de autenticação e dados pessoais.

### 5. Torne as alterações reversíveis

Não misture refatorações não relacionadas e adições de funcionalidades em uma mesma alteração. Revisar o diff em pequenas unidades e registrar as mudanças no controle de versão facilita isolar e reverter alterações incorretas.

## Dicas para operar projetos com Claude Code

- Registre regras recorrentes do projeto no `CLAUDE.md` de forma breve e concreta.
- Forneça comandos de build, teste e lint em uma forma que possa realmente ser executada.
- Não coloque informações secretas, logs de erros ocasionais nem documentos de referência longos no `CLAUDE.md`.
- Antes de grandes alterações, solicite primeiro uma análise dos arquivos relacionados e das dependências.
- Ao adicionar um novo pacote, revise sua necessidade, licença e riscos de manutenção.
- Não aprove automaticamente comandos perigosos de exclusão, implantação ou alteração de dados.
- Antes de conectar uma API externa ou MCP, verifique para onde os dados serão enviados.
- Ao concluir, solicite um resumo dos arquivos alterados, comandos executados, resultados dos testes e limitações restantes.

## Checklist antes do envio

- [ ] O usuário e a situação de uso estão explicados?
- [ ] Os objetivos e não objetivos estão separados?
- [ ] As tecnologias existentes e o escopo no qual alterações são proibidas estão especificados?
- [ ] Os dados de entrada e o formato de saída estão definidos?
- [ ] O significado dos valores de classificação e de status está explicado?
- [ ] Existem políticas para resultados vazios, falhas de autenticação, tempo limite e falhas parciais?
- [ ] O planejamento e a implementação estão separados por etapas?
- [ ] Existem testes para casos normais, extremos e de falha?
- [ ] Informações secretas e dados pessoais estão excluídos do prompt e dos logs?
- [ ] Foram solicitados um diff para revisão humana e evidências de execução?

O essencial de um bom prompt para Claude Code não é escrever comandos longos. É reduzir o que o agente precisa inferir e permitir que terceiros também reproduzam e avaliem se o resultado está correto.

## FAQ

### Quanto mais longo o prompt do Claude Code, melhor?
Mais importante do que o tamanho é se as informações necessárias para a tarefa estão estruturadas. O contexto, o objetivo, as restrições, o contrato de saída, o tratamento de exceções e os critérios de conclusão devem ser descritos de forma específica, mas é melhor remover explicações irrelevantes e instruções repetidas.

### Não posso pedir que ele crie o programa inteiro desde o início?
Isso é possível no caso de uma ferramenta pequena e independente, mas é mais seguro desenvolver por etapas quando a tarefa envolve API externa, banco de dados, e-mail e execução agendada. Analisar primeiro o repositório e o plano e depois expandir na ordem de funcionalidade mínima, testes e integrações externas facilita isolar as causas das falhas.

### Posso pular os testes se usar o Plan Mode?
Não. O modo de planejamento é útil para analisar a estrutura e a abordagem antes das alterações, mas não comprova a exatidão do código real. Após a implementação, é necessário realizar separadamente testes automatizados, análise estática, revisão das alterações e as verificações manuais necessárias.

### O que devo escrever no CLAUDE.md?
É apropriado incluir instruções recorrentes em várias tarefas, como a estrutura do projeto, regras de codificação, comandos de compilação e teste e áreas que não devem ser modificadas. É melhor não incluir chaves de API, senhas, dados pessoais, descrições de tarefas pontuais nem materiais de referência excessivamente longos.

### Quais informações devo fornecer em uma solicitação de correção de erro?
É necessário fornecer em conjunto a mensagem de erro e o rastreamento de pilha sem informações confidenciais, o comando de execução, a entrada mínima para reprodução, o ambiente relevante, o comportamento real e o comportamento esperado. Também é recomendável solicitar uma explicação da causa, uma correção de escopo mínimo, testes de regressão e os resultados da execução.

### Posso fornecer uma chave de API ao Claude Code no prompt?
Como regra, não se deve registrar uma chave de API real diretamente no prompt nem no código-fonte. Use variáveis de ambiente aprovadas ou um sistema de gerenciamento de segredos e garanta que as informações de autenticação também não sejam expostas nos logs nem nos resultados dos testes.

### É obrigatório especificar no prompt o número de tentativas e o tempo de espera?
No caso de automação operacional, é importante distinguir entre erros que permitem nova tentativa e erros que exigem interrupção imediata. No entanto, o número específico de tentativas e o tempo de espera devem ser definidos após verificar os limites do serviço externo, a urgência da tarefa e o risco de processamento duplicado, e não se deve tentar novamente de forma indiscriminada em todos os erros.

### Como posso determinar se o código gerado está concluído?
Isso é determinado com base nos critérios de aceitação definidos previamente. É necessário verificar se os testes das funcionalidades obrigatórias e dos casos excepcionais foram aprovados, os comandos executados, os arquivos alterados e se as restrições de desempenho ou segurança foram atendidas, além de uma pessoa revisar as alterações no código.

## Sources

- [Visão geral do Claude Code](https://docs.anthropic.com/en/docs/claude-code/overview)
- [Claude Code: melhores práticas para programação agêntica](https://www.anthropic.com/engineering/claude-code-best-practices)
- [Repositório do Anthropic Claude Code no GitHub](https://github.com/anthropics/claude-code)

## Images

![Desenvolvedor trabalhando diante de um monitor grande com código e diagrama de fluxo](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTExNTQsInB1ciI6ImJsb2JfaWQifX0=--9f2d2e2c8a61fc294a6019e4807ece297f36e85a/ai-4caeb237.webp)
![Notebook com editor de código ligado a requisitos, tabelas, erros, controle de versão e gráficos de desempenho](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTExNjAsInB1ciI6ImJsb2JfaWQifX0=--285d7ecdc8209e07e0fc4eb68085cd8a304b9a81/ai-062b34c5.webp)