Promptis

Template de prompt

Um prompt para revisão de código com achados que você pode validar.

Este template entrega ao agente a alteração, o comportamento esperado, as restrições e as validações já realizadas antes de pedir uma revisão. Assim, a resposta tende a priorizar riscos reais em vez de apenas resumir o diff.

Usar o template de revisão de códigoLer o template

Revisado em 22 de setembro de 2026 · Os templates e exemplos usam dados fictícios.

Quando usar este prompt para revisão de código

Use-o quando uma alteração estiver pronta para inspeção, mas antes de considerá-la concluída. O escopo pode ser um pull request, um diff local, um conjunto de arquivos ou uma implementação bem delimitada. O agente ainda precisa ter acesso ao código e aos testes relevantes; o prompt organiza a análise, mas não substitui essas evidências.

O template é especialmente útil quando a revisão precisa priorizar comportamento e risco. Ele orienta o agente a examinar os caminhos afetados, distinguir problemas confirmados de contexto ausente e não afirmar que testes não executados passaram.

Template reutilizável

Prompt para revisão de código

Abrir no Promptis →
# Revisar {{alteracao}}

## Objetivo

Revise {{alteracao}} no projeto {{projeto}} e identifique problemas que possam afetar usuários ou a manutenção.

## Contexto

- Comportamento esperado: {{comportamento_esperado}}
- Restrições relevantes: {{restricoes}}
- Validação já realizada: {{validacao}}

<instructions>
Inspecione o código alterado e os caminhos de execução afetados. Priorize defeitos, regressões, segurança, integridade de dados, acessibilidade, desempenho e testes ausentes.

Fundamente cada achado em evidências concretas. Não invente falhas nem afirme que um teste passou sem executá-lo. Se faltar contexto, registre a incerteza e a verificação exata necessária.
</instructions>

<output_format>
1. Achados ordenados por gravidade, cada um com evidência, impacto e correção prática
2. Perguntas em aberto ou premissas
3. Lacunas de validação e testes
4. Resumo curto caso nenhum problema bloqueante seja encontrado
</output_format>

O que preencher

{{alteracao}}

Branch, pull request, diff, funcionalidade ou arquivos que definem o limite da revisão.

{{projeto}}

Contexto do repositório ou produto, incluindo serviços relacionados apenas quando influenciarem a mudança.

{{comportamento_esperado}}

Resultado observável para usuários ou sistemas dependentes depois da alteração.

{{restricoes}}

Requisitos de compatibilidade, segurança, desempenho, acessibilidade ou migração.

{{validacao}}

Testes e verificações já executados, incluindo falhas e checagens que não foram possíveis.

Exemplo preenchido

Alteração: Substituir a consulta de sessão por uma leitura com cache.

Projeto: API TypeScript usada pelos aplicativos web e móvel.

Comportamento esperado: As decisões de autorização continuam iguais, evitando consultas repetidas na mesma requisição.

Restrições: Sessões revogadas devem parar de funcionar imediatamente; logs não podem conter tokens; códigos públicos de erro permanecem estáveis.

Validação: Testes unitários passaram. Revogação e requisições concorrentes ainda não foram testadas.

Uma resposta útil deve concentrar-se em invalidação, limite da requisição, autorização, logs sensíveis, concorrência e no teste de revogação ausente. Sem esse contexto, a revisão pode gastar a maior parte da resposta descrevendo o cache.

Como avaliar o resultado

  • Cada achado aponta um comportamento ou uma evidência específica.
  • A gravidade reflete o impacto para o usuário, não preferência de estilo.
  • Incertezas são identificadas em vez de apresentadas como defeitos.
  • Os testes sugeridos descrevem cenário e resultado esperado.
  • A correção proposta preserva as restrições informadas.

Se a resposta ainda estiver genérica, reduza o escopo de {{alteracao}}, forneça os arquivos ou o diff relevante e torne o comportamento esperado mais concreto. Evidência relevante importa mais do que um prompt longo.

Limites

Um prompt não dá ao agente acesso a código, logs ou resultados de testes que a ferramenta não possua. Também não comprova correção. Trate a resposta como um conjunto de achados a verificar, não como uma aprovação automática.