Revisão Unslop

Quando Usar

Use esta habilidade quando precisar reescrever comentários de revisão de código para que soem como se um colega de equipe humano os tivesse escrito. Elimina rodeios corporativos de IA ("Notei...", "Estava me perguntando se talvez...", "Pode valer a pena considerar..."). Cada comentário é direto: localização, o problema, uma correção concreta. Use quando o usuário disser...

Propósito

Reescrever ou gerar comentários de revisão de PR que soem como um colega de equipe, não um motor de polidez. Direto no problema, concreto na correção, gentil com o humano.

Gatilho

/unslop-review, /review, "revisar este PR", "revisão de código", "humanizar revisão", "des-enrolar este comentário", "fazer este feedback soar humano". Gatilho automático ao revisar pull requests.

Formato

Forma padrão: L<line>: <severity prefix> <observation>. <fix>.

Prefixos de gravidade (opcional, mas use-os quando a gravidade importar):

• bug: — o código está quebrado ou vai quebrar
• risk: — funciona hoje, frágil amanhã (desempenho, race condition, teste faltando)
• nit: — estilo, nomenclatura, código morto, "enquanto você está aqui"
• q: — pergunta genuína, não uma reclamação velada

Multi-arquivo: <file>:L<line>: <severity> <observation>. <fix>.

Intervalo: L88-140: ... quando o problema abrange várias linhas.

Regras

Remover

• Rodeios: "Notei que...", "Parece que...", "Para mim, parece que..."
• Empilhamento de hesitação: "Estava me perguntando se talvez poderíamos querer potencialmente..."
• Preenchimento polido: "Eu gentilmente sugeriria...", "apenas uma pequena sugestão..."
• Elogios por comentário: "Bom trabalho nesta função, mas...", "Ótimo padrão, no entanto..."
• Repetir o diff: "Aqui na linha 42 você tem uma função chamada getUser que retorna..."
• Opinião crua sem correção: "Isso é ruim" sem sugestão

Manter

• Números de linha e intervalos exatos
• Identificadores entre crases: findUser, req.body.id
• Correção concreta ou pergunta concreta
• "Por quê" apenas quando a correção não for óbvia

Tom

Humano, não corporativo. "Isso lança uma exceção se X" em vez de "Pode ser potencialmente digno de nota que isso possa lançar uma exceção sob certas condições." Incerteza calibrada é aceitável ("Eu acho", "provavelmente") — suavização performática não é.

Auto-clareza (use prosa completa, não frases curtas)

• Descobertas de segurança (classe CVE, autenticação, segredos)
• Discordâncias de arquitetura que precisam de uma discussão real
• Contexto de integração para um novo contribuidor
• Quando a resposta é genuinamente "está tudo bem"

Nesses casos, use um parágrafo curto e, em seguida, retorne à concisão para o restante.

Exemplos

Ruim → Bom

• Ruim: I would kindly suggest that we might want to potentially consider adding a null check here as it could maybe lead to issues in some scenarios.

• Bom: L42: bug: \findUser` returns undefined when no match. Guard before `user.email` or early-return 404.`

• Ruim: Great work on this implementation! However, I think we could potentially enhance readability by considering a refactor of this function.

• Bom: L88-140: nit: this function does validation, I/O, and mapping. Splitting them would make the happy path easier to follow. Happy to pair on a cut if helpful.

• Ruim: I noticed that there's no retry logic here which could be problematic.

• Bom: L23: risk: no retry on 429. Wrap the call in \withBackoff(3)` so we don't drop legitimate requests.`

• Ruim: This implementation leverages a robust caching strategy.

• Bom: (excluir — elogio vazio. Se o caching for genuinamente interessante, explique por quê especificamente.)

Aprovação

Se a mudança for sólida e você não tiver nada concreto: LGTM em sua própria linha. Sem boilerplate.

Limites

• Apenas comentários. Sem commits, sem git push, sem aprovação automática, sem execuções de linter.
• A saída está pronta para colar: um comentário por linha, ou uma lista claramente separada.
• A gravidade deve ser honesta. Não rebaixe um bug para um nit para suavizar a mensagem.

Limitações

• Use esta habilidade apenas quando a tarefa corresponder claramente à sua origem e ao contexto do projeto local.
• Verifique comandos, código gerado, dependências, credenciais e comportamento de serviços externos antes de aplicar alterações.
• Não trate exemplos como substitutos para testes específicos do ambiente, revisão de segurança ou aprovação do usuário para ações destrutivas ou custosas.