Claude Code First PR Review Rubric: encontrar risco real antes de estilo

Sem rubrica, Claude Code pode dar o mesmo peso a uma regressão de produção e a uma sugestão de nome. Parece produtivo, mas não ajuda a decidir o que bloqueia o merge.

Este guia cria uma primeira rubrica de review. Defina P0 a P3, evidência, formato de comentário e regras de retry antes de ler o diff.

Leituras relacionadas: claude-code-code-review-checklist, claude-code-prompt-library-maintenance, claude-code-pull-request-quality. Base da documentação oficial: Anthropic Claude Code docs.

Por que decidir antes do primeiro comando

encontrar regressões, risco de permissão, perda de dados e falta de testes antes de estilo

O ponto principal é manter o primeiro pedido pequeno. Defina escopo de leitura, áreas protegidas, primeira ação e comando de prova antes de editar.

devs que começaram review com Claude Code e precisam de achados mais fortes

Fluxo prático

1. Colar objetivo e arquivos alterados antes do diff
2. Definir P0 a P3 antes do review
3. Proibir comentários especulativos sem evidência
4. Exigir prova de teste, build ou reprodução
5. Deixar notas P3 de estilo para o fim

Situação	O que o Claude Code faz	Prova que a pessoa confere
PR de auth	Tratar token e limites de permissão como P0	build, diff, URL
Correção UI	Checar cliques quebrados e mobile como P1	build, diff, URL
Refactor	Separar prova de comportamento e testes faltantes como P2	build, diff, URL

Com essa prova, o Claude Code é avaliado por trabalho observável, não por uma nota final confiante.

Prompt e código para copiar

Revise este PR diff com severidade P0/P1/P2/P3. P0 é segurança, perda de dados, pagamento, auth ou queda de produção. Cada achado deve incluir linha, cenário de falha, evidência necessária e correção. Estilo fica no fim.

const reviewRubric = {
  P0: "security, data loss, payment, auth, production outage",
  P1: "user-visible regression or broken release path",
  P2: "test gap, unclear edge case, maintainability risk",
  P3: "style, naming, or optional cleanup"
};

function classifyReviewFinding(finding) {
  const text = finding.toLowerCase();
  if (/auth|token|payment|delete|secret|production/.test(text)) return "P0";
  if (/regression|broken|crash|deploy/.test(text)) return "P1";
  if (/missing test|edge case|unclear/.test(text)) return "P2";
  return "P3";
}

console.log(classifyReviewFinding("missing test for failed payment retry"));

Exemplos reais e falhas

Situação	O que o Claude Code faz	Prova que a pessoa confere
PR de auth	Tratar token e limites de permissão como P0	build, diff, URL
Correção UI	Checar cliques quebrados e mobile como P1	build, diff, URL
Refactor	Separar prova de comportamento e testes faltantes como P2	build, diff, URL

• Se nome e formato vêm primeiro, Claude Code enche o review de notas de baixo risco.
• Sem severidade, bug de pagamento e pontuação ficam juntos.
• Sem prova, comentários plausíveis e não testados aumentam.

O ponto principal é manter o primeiro pedido pequeno. Defina escopo de leitura, áreas protegidas, primeira ação e comando de prova antes de editar.

O que guardar como pacote de prova

encontrar regressões, risco de permissão, perda de dados e falta de testes antes de estilo fica mais valioso quando vira pacote de prova, não apenas um chat isolado. Guarde o pedido original, arquivos lidos pelo Claude Code, áreas não tocadas, comandos executados, URL pública ou screenshot e a decisão que ainda ficou incerta. A próxima sessão reaproveita o mesmo julgamento sem redescobrir o contexto.

Para devs que começaram review com Claude Code e precisam de achados mais fortes, a meta não é criar um manual pesado no primeiro dia. Teste o padrão em um PR, uma nota ou um deploy. Se falhar, coloque a falha no checklist e rode uma versão menor. Amplie o acesso do Claude Code só quando build, diff, URL, CTA e rollback estiverem visíveis. Abrir permissões antes de prova parece mais rápido, mas empurra custo de verificação para a próxima revisão humana.

A rota de receita segue a mesma regra. Se o leitor ainda trava nos comandos básicos, o PDF grátis é o próximo passo. Se repete o mesmo tipo de prompt toda semana, Gumroad ajuda. Se decide sobre equipe ou produção, consultoria combina melhor. Este artigo não deve empurrar todos para compra; deve enviar ao guia pago apenas quem precisa de prompts de revisão de PR e rubricas reutilizáveis, e devolver os demais para o PDF grátis ou artigos relacionados.

Levar ao PDF grátis, Gumroad e consultoria

Se os comandos básicos ainda estão confusos, comece com a folha gratuita. Para aprofundar prompts de revisão de PR e rubricas reutilizáveis, use o guia no Gumroad. Se houver adoção de equipe, regras de revisão ou desenho de receita, vá para consultoria. A comparação de produtos começa em products.

O CTA não precisa ficar só no fim. Na introdução, o PDF grátis reduz atrito. Depois do exemplo prático, Gumroad faz sentido. Quando entra time ou risco de produção, consultoria vira o próximo passo natural.

Métricas após publicar

Depois de publicar, acompanhe cliques para Prompt Templates, futuro Code Review System e consultoria.

Não julgue só por PV. Separe leitura inicial, cliques internos, registros do PDF grátis, cliques no Gumroad e visitas à consultoria. HTTP 200, h1, canonical, heroImage, CTA e corpo localizado precisam apontar para o mesmo slug.