Análise de Qualidade de Código

O que você leva

• Relatório de qualidade de código com score, achados por severidade, evidências, sugestões e itens de revisão humana.
• Transforme revisão técnica dispersa em um relatório objetivo de qualidade, risco e próximos passos.
• Problema: O time precisa revisar código com consistência antes de merge ou refatoração, mas falta tempo, padrão comum e priorização da dívida técnica.
• Fluxo: Analisar

Exemplo de pedido pronto

Analise a qualidade deste endpoint TypeScript de criação de cobrança Pix e gere um relatório com score, problemas, severidade e sugestões sem alterar arquivos.

Esta é uma das skills que a gente deixa aberta pra leitura. O arquivo abaixo é exatamente o que quem tem o catálogo completo recebe — entrada, passos, revisão e formato de saída. Use no seu assistente e adapte ao seu contexto.

---
name: "analise-qualidade-codigo"
description: "Análise somente leitura de qualidade, manutenibilidade, dívida técnica, testes e riscos básicos em código."
domain: "ENG"
function_verb: "ANALISAR"
difficulty: "plug"
cost_profile: "xs"
---

# Análise de Qualidade de Código

Skill para revisar código em modo somente leitura e transformar PRs, módulos legados ou trechos críticos em um relatório técnico priorizado. Não altera arquivos, não executa correções automáticas e não substitui revisão humana, testes ou auditoria de segurança.

## Quando Usar

- Antes do merge de PR pequeno ou médio em GitHub, GitLab, Bitbucket ou Azure DevOps.
- Para mapear dívida técnica em módulo legado de SaaS, e-commerce, ERP interno, fintech ou sistema operacional da empresa.
- Quando o time precisa decidir se refatora agora, cria testes, abre cards técnicos ou aceita o risco temporariamente.
- Para revisar endpoints que lidam com checkout, Pix, boleto, CPF/CNPJ, cadastro de clientes, autenticação ou integrações externas.
- Quando há revisão manual subjetiva e o time quer um checklist comum de qualidade.

Evite usar para: garantir segurança total, aprovar deploy sozinho, revisar diff gigante sem recorte, ou substituir análise arquitetural profunda.

## Resultado Esperado

Um relatório em PT-BR com:
- resumo executivo e score geral de 0 a 10;
- escopo analisado e limitações;
- achados por severidade: crítica, alta, média, baixa;
- evidência objetiva no código, sem inventar arquivos ou linhas;
- impacto provável em manutenção, bugs, testes, segurança ou performance;
- sugestões proporcionais e incrementais;
- pontos positivos do código;
- próximos passos e itens que exigem revisão humana.

## Entradas Necessarias

Peça ou confirme:
- objetivo da análise: PR, módulo, trecho isolado ou auditoria de dívida técnica;
- linguagem e stack: Node.js, TypeScript, Python, Java, Go, PHP, C#, Ruby etc.;
- arquivos, diff, pasta ou trechos a analisar;
- contexto de negócio: checkout, cobrança Pix, boleto, ERP, CRM, autenticação, relatório financeiro;
- restrições do time: prazo, padrão interno, framework, nível de risco aceitável;
- se há testes existentes e critérios de merge.

Não solicite dados reais de produção, senhas, tokens, chaves privadas, dumps de banco ou logs com dados pessoais.

## Processo

1. Delimite escopo. Se o diff for grande, peça recorte por módulo, endpoint ou risco.
2. Leia somente os arquivos necessários. Não edite, não rode comandos destrutivos e não faça refatoração automática.
3. Classifique o contexto: código comum, crítico, segurança, pagamentos, dados pessoais ou integração externa.
4. Analise legibilidade: nomes, fluxo, tamanho de funções, clareza de regras, comentários úteis.
5. Analise design: coesão, acoplamento, duplicação, responsabilidade única, dependências implícitas.
6. Analise robustez: validação de entrada, tratamento de erro, idempotência, concorrência, logs e observabilidade.
7. Analise testes: cenários cobertos, lacunas relevantes, testes frágeis, ausência de regressão.
8. Faça triagem de riscos básicos: segredos hardcoded, autorização fraca, exposição de dados, SQL/command injection evidente, uso inseguro de criptografia.
9. Separe fato de opinião. Preferência de estilo não deve virar severidade alta sem impacto claro.
10. Gere relatório com severidade, evidência, impacto, sugestão e esforço estimado: P, M ou G.
11. Inclua escalonamento humano para segurança, arquitetura crítica, pagamentos, LGPD ou decisão de merge.

## Ferramentas E Artefatos

Softwares comuns: GitHub, GitLab, Bitbucket, Azure DevOps, VS Code, IntelliJ IDEA, WebStorm, PyCharm, SonarQube, ESLint, Prettier, Jest, Pytest, JUnit, Docker, Jira e Linear.

Artefatos aceitos: PR, diff, branch, arquivos .js, .ts, .tsx, .py, .java, .go, .php, .rb, .cs, README, testes, logs sanitizados, relatório técnico e cards de backlog.

WebSearch é opcional e só para documentação pública. Nunca envie código proprietário, segredo ou dados pessoais para serviços externos sem autorização explícita.

## Exemplo Brasileiro

Cenário: API Node.js/TypeScript de uma fintech ou e-commerce que cria cobrança Pix. O endpoint recebe valor, CPF/CNPJ, descrição e ID do cliente.

Boa análise deve notar, por exemplo:
- validação de CPF/CNPJ duplicada em controller e service, com risco de inconsistência;
- método `createPixCharge` longo, misturando regra de negócio, chamada ao PSP e formatação de resposta;
- ausência de teste para valor zero, CPF inválido, timeout do provedor e idempotência;
- log com payload completo contendo dados pessoais;
- ponto positivo: uso de DTO e tratamento centralizado de erro.

Saída esperada: score, achados priorizados, sugestão de extrair validador único, mascarar logs, criar testes de regressão e escalar revisão humana por envolver dados pessoais e pagamento.

## Criterios De Qualidade

- Não altera arquivos, não cria commits e não recomenda deploy automático.
- Evidencia cada achado com arquivo, função, trecho ou comportamento observado.
- Severidade considera impacto, probabilidade e criticidade do domínio.
- Distingue bug provável, dívida técnica, risco de segurança, lacuna de teste e preferência de estilo.
- Sugestões são incrementais, compatíveis com a stack e viáveis para um time brasileiro de produto.
- Não reproduz segredos nem dados pessoais encontrados.
- Em caso de incerteza, declara limitação e pede contexto em vez de inventar.

## Cuidados, LGPD E Escalacao Humana

- Código-fonte é informação confidencial. Minimize trechos copiados para o prompt.
- Não inclua CPF, CNPJ, e-mail, telefone, endereço, cartão, token Pix, dados bancários, dados de saúde, senhas ou chaves reais.
- Se encontrar segredo hardcoded, escreva apenas algo como "segredo detectado em variável de ambiente/chave"; não copie o valor. Recomende rotação, revogação e remoção segura.
- Para autenticação, autorização, criptografia, pagamentos, Pix, boleto, antifraude, dados pessoais ou sistemas regulados, trate como triagem e escale para responsável técnico, segurança ou DPO quando aplicável.
- Não afirme conformidade com LGPD, PCI, BACEN ou segurança total. Use linguagem de indício, risco, checklist e revisão.
- Não use pesquisa externa com código proprietário sem autorização.

## Smoke Test

Prompt: "Analise a qualidade deste endpoint TypeScript de criação de cobrança Pix e gere um relatório com score, problemas, severidade e sugestões sem alterar arquivos."

Critério de aprovação: resposta em PT-BR com resumo, score, escopo, achados priorizados, evidências, riscos de LGPD/segurança, sugestões incrementais, pontos positivos, próximos passos e escalonamento humano. Deve permanecer em modo somente leitura e não reproduzir segredos.