Redija mensagens de commit e descrições de PR a partir do seu diff
Boas mensagens de commit e descrições de pull request são a forma como uma mudança se explica para os revisores agora e para quem for depurá-la daqui a dois anos. Mas, no fim de uma tarefa longa, escrever o porquê em vez do o quê é o atalho que quase todo mundo toma. Resumir mudanças recentes de código é uma das cinco principais tarefas de IA; alimentar o diff para um modelo gera um rascunho estruturado que você depois edita para incluir o raciocínio que ele não consegue enxergar.
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.
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
- Coloque o diff final em stage e anote uma linha sobre por que a mudança existe
- Gere a mensagem e a descrição, depois corrija qualquer coisa que o diff não sustente de fato
- Preencha os números de issue e qualquer sinalização "[VERIFY]" manualmente
- 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
Explique código desconhecido antes de alterá-lo
análiseUma primeira revisão do seu próprio diff antes que humanos o vejam
automaçãoGere testes unitários e depois verifique-os em relação à especificação
análiseDepuração "pato de borracha" para um problema que você não consegue resolver
redaçãoTransforme uma decisão em um ADR ou na documentação que você deixou de escrever
← Todos os 6 casos de uso: como os desenvolvedores de software usam a IA