Prompt
Você está me ajudando a escrever uma mensagem de commit e uma descrição de pull request claras a partir de um diff. Siga as convenções da minha equipe.

Convenção de commit (por exemplo, Conventional Commits) ou "nenhuma": {{convention}}
Por que fiz essa mudança — a intenção que um diff não consegue mostrar: {{intent}}
O diff:
{{diff}}

Produza duas coisas:
1. Uma mensagem de commit: uma linha de assunto concisa (modo imperativo, cerca de 50 caracteres, seguindo {{convention}} se informado), uma linha em branco, depois um corpo explicando o que mudou e por quê, quebrado em 72 caracteres. Referencie a issue como "[ISSUE]" para eu preencher.
2. Uma descrição de PR: um resumo de um parágrafo, uma lista com marcadores das mudanças notáveis, uma seção "Como testar" e uma nota de "Risco / rollback".

Regras:
- Descreva apenas o que está de fato no diff. Não afirme que testes foram adicionados, documentação foi atualizada ou um bug foi corrigido, a menos que o diff mostre isso. Marque qualquer coisa que você não consiga confirmar pelo diff como "[VERIFY]".
- O porquê deve vir das minhas anotações de intenção, não do seu palpite sobre minha motivação.
- Sem enrolação, sem repetir o código linha por linha, sem tom de marketing.

Preencha seus dados e o prompt se atualiza na hora — depois é só copiar.

O que você recebe (trecho)

feat(api): armazenar em cache as consultas de permissão do usuário As verificações de permissão acessavam o banco a cada requisição, adicionando latência. As permissões resolvidas são armazenadas em cache por usuário durante 60s para reduzir queries redundantes. Closes [ISSUE]. --- Resumo do PR: Adiciona um cache em memória de curta duração para consultas de permissão. Mudanças notáveis: - Novo PermissionCache com TTL de 60s - Cache invalidado na troca de role Como testar: chame /me duas vezes; a segunda chamada deve pular o banco (veja o log de debug). Risco / rollback: o cache está atrás da flag PERM_CACHE; desative para reverter. [VERIFY] invalidação em deploys multi-instância.

O fluxo de trabalho completo

  1. Coloque o diff final em stage e anote uma linha sobre por que a mudança existe
  2. Gere a mensagem e a descrição, depois corrija qualquer coisa que o diff não sustente de fato
  3. Preencha os números de issue e qualquer sinalização "[VERIFY]" manualmente
  4. Mantenha o raciocínio no corpo da mensagem — essa é a parte que os revisores e o seu eu do futuro realmente precisam

Fique de olho

Um modelo resumindo um diff vai afirmar tranquilamente que você adicionou testes ou corrigiu um problema de segurança que na verdade não corrigiu — o histórico de commits é um registro permanente no qual outras pessoas confiam, então verifique cada afirmação em relação ao diff antes de fazer o commit.

Diffs podem conter segredos, chaves ou identificadores internos. Não os cole em uma ferramenta de consumo; use uma integração aprovada ou remova-os antes.

O modelo vê o quê, mas não o porquê. Forneça a intenção você mesmo, ou você vai publicar mensagens que descrevem a mudança sem explicar a decisão por trás dela.

De onde isso vem

Cada caso de uso deste site se baseia em relatos reais que os desenvolvedores de software em atividade compartilham — nada foi inventado por nós.

Mais casos de uso de IA para os desenvolvedores de software

← Todos os 6 casos de uso: como os desenvolvedores de software usam a IA