Claude Code First PR Review Rubric: detectar riesgo real antes del estilo

Si pides a Claude Code revisar un PR sin rúbrica, una regresión de producción y un detalle de nombre pueden salir con el mismo peso. Parece productivo, pero no ayuda a decidir qué bloquea el merge.

Esta guía crea una primera rúbrica de revisión. Define P0 a P3, evidencia, formato de comentario y reglas de reintento antes de leer el diff.

Lecturas relacionadas: claude-code-code-review-checklist, claude-code-prompt-library-maintenance, claude-code-pull-request-quality. Base de documentación oficial: Anthropic Claude Code docs.

Por qué decidirlo antes del primer comando

encontrar regresiones, riesgo de permisos, pérdida de datos y tests faltantes antes del estilo

La clave es no hacer demasiado grande la primera petición. Define alcance de lectura, zonas protegidas, primera acción y prueba antes de que Claude Code edite.

desarrolladores que usan Claude Code para review y necesitan hallazgos más fuertes

Flujo práctico

1. Pegar objetivo y archivos cambiados antes del diff
2. Definir P0 a P3 antes de revisar
3. Prohibir comentarios especulativos sin evidencia
4. Exigir prueba de test, build o reproducción
5. Dejar notas P3 de estilo para el final

Situación	Qué hace Claude Code	Prueba que revisa la persona
PR de auth	Tratar token y permisos como P0 primero	build, diff, URL
Arreglo UI	Revisar clics rotos y móvil como P1	build, diff, URL
Refactor	Separar prueba de comportamiento y tests faltantes como P2	build, diff, URL

Con esa prueba, Claude Code se evalúa por trabajo observable y no por una nota final convincente.

Prompt y código para copiar

Revisa este PR diff con severidad P0/P1/P2/P3. P0 es seguridad, pérdida de datos, pagos, auth o caída de producción. Cada hallazgo debe incluir línea, escenario de fallo, evidencia necesaria y arreglo. Deja estilo para el final.

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"));

Ejemplos reales y fallos

Situación	Qué hace Claude Code	Prueba que revisa la persona
PR de auth	Tratar token y permisos como P0 primero	build, diff, URL
Arreglo UI	Revisar clics rotos y móvil como P1	build, diff, URL
Refactor	Separar prueba de comportamiento y tests faltantes como P2	build, diff, URL

• Si el nombre y formato aparecen primero, Claude Code llena la revisión de notas de bajo riesgo.
• Sin severidad, un bug de pago y puntuación quedan juntos.
• Sin pedir pruebas, aumentan comentarios plausibles pero no verificados.

La clave es no hacer demasiado grande la primera petición. Define alcance de lectura, zonas protegidas, primera acción y prueba antes de que Claude Code edite.

Qué guardar como paquete de prueba

encontrar regresiones, riesgo de permisos, pérdida de datos y tests faltantes antes del estilo vale más cuando queda guardado como paquete de prueba y no como un chat aislado. Guarda la petición original, archivos leídos por Claude Code, áreas no tocadas, comandos ejecutados, URL pública o screenshot y la decisión que aún quedó dudosa. La siguiente sesión reutiliza el mismo criterio sin redescubrir el contexto.

Para desarrolladores que usan Claude Code para review y necesitan hallazgos más fuertes, el objetivo no es crear un manual pesado el primer día. Prueba el patrón en un PR, una nota o un deploy. Si falla, agrega la falla al checklist y repite una versión más pequeña. Amplía el acceso de Claude Code solo cuando build, diff, URL, CTA y rollback estén visibles. Abrir permisos antes de tener prueba parece rápido, pero mueve el costo de verificación a la siguiente revisión humana.

La ruta de ingresos sigue la misma regla. Si el lector sigue trabado en comandos básicos, el PDF gratis es el siguiente paso. Si repite el mismo tipo de prompt cada semana, Gumroad tiene sentido. Si decide sobre equipo o producción, la consulta encaja mejor. Este artículo no debe empujar a todos a comprar; debe enviar a la guía pagada solo a quienes necesitan prompts de revisión de PR y rúbricas reutilizables, y devolver al resto al PDF gratis o a lecturas relacionadas.

Llevar al PDF gratis, Gumroad y consulta

Si los comandos básicos aún no están claros, empieza con la chuleta gratis. Para profundizar en prompts de revisión de PR y rúbricas reutilizables, usa la guía en Gumroad. Si el trabajo incluye adopción de equipo, reglas de revisión o diseño de ingresos, pasa a consulta. La comparación de productos empieza en products.

El CTA no debe vivir solo al final. En la introducción, el PDF gratis reduce fricción. Tras el ejemplo práctico encaja Gumroad. Cuando aparece despliegue de equipo o riesgo de producción, la consulta es el siguiente paso natural.

Métricas tras publicar

Tras publicar, mira clics hacia Prompt Templates, el futuro Code Review System y consulta.

No juzgues solo por PV. Separa lectura inicial, clics internos, registros del PDF gratis, clics en Gumroad y visitas a consulta. HTTP 200, h1, canonical, heroImage, CTA y cuerpo localizado deben apuntar al mismo slug.