ChristianSavinoDP/Claude-Skills

Revisión de PR

Procedimiento para revisar una PR. Las reglas de revisión (tono, categorías de comentarios, flujo de decisión, qué no hacer) se encuentran en el Playbook en la sección "PR Reviews"; este skill es el cómo. No repitas las reglas aquí, aplícalas. Los "Estándares Compartidos" del Playbook aplican en todo momento (sé conciso, nada de basura de IA, verifica no afirmes, nunca inventes).

Antes de revisar

1. Pide el ticket primero. Según el primer paso obligatorio del Playbook, no obtengas el diff ni analices nada hasta que tengas el ticket. El ticket establece el tipo de trabajo (feature vs seguimiento vs investigación) y los criterios de aceptación, que cambian la forma de revisar.
2. Identifica la PR: pide el número/URL de la PR si no se proporciona.

Reúne contexto

• Obtén el diff y los metadatos con la CLI de GitHub: gh pr view <pr> y gh pr diff <pr>.
• Para una PR de investigación, revisa también docs/investigations/ para el formato esperado.
• Lee los archivos modificados por completo, no solo los fragmentos del diff, cuando el comportamiento dependa del código circundante.

Revisión

Recorre el diff archivo por archivo. Aplica la sección "PR Reviews" del Playbook:

• Ejecuta la lista de verificación del Playbook (criterios de aceptación, fallos de compilación/pruebas, llamadores actualizados, cobertura de pruebas, evidencia para investigaciones).
• Clasifica cada hallazgo como bloqueante, nimiedad o pregunta, según el Playbook.
• Usa el flujo de decisión del Playbook para decidir si cada observación merece un comentario.
• Las reglas de alcance difieren según el tipo de ticket (seguimiento: resuelve todo aquí; feature: refactorizaciones válidas). Confirma el tipo desde el ticket.
• Según el "Verifica, no afirmes" del Playbook: comprueba las afirmaciones tú mismo antes de repetirlas. Ejecuta gh pr checks <pr> para CI, busca en el repositorio los símbolos eliminados. La descripción de la PR es una afirmación del autor, no una evidencia.
• Según el "No elimines silenciosamente el comportamiento existente" del Playbook: una regresión de comportamiento no confirmada es un hallazgo bloqueante, incluso si el autor lo señaló en la descripción.

Resultado

Sigue el "PR Reviews > Formato" del Playbook. Muestra la revisión directamente en el chat (no en un archivo, a menos que el usuario lo solicite), como una línea de veredicto y luego los hallazgos. NO es un ensayo en prosa, un registro de conversación o secciones como "Contexto Recopilado"/"Revisión Inicial". Cada hallazgo es exactamente: una línea de referencia de ubicación+código, el comentario en un bloque delimitado copiable, y luego el porqué. Concretamente, un hallazgo se ve así:

### Bloqueante

`internal/adapters/users/adapter.go:281`
```go
_, err := u.providersClient.Update(ctx, request)
```

Comentario (péguelo en la PR):

Esto elimina el reintento de consistencia eventual del que dependían estas escrituras. El retraso de Core->Users se manifiesta como NotFound, que la nueva política solo transitoria no reintentará, por lo que la escritura falla inmediatamente.

Por qué: AC #3 solicita confirmar que ninguna ruta depende de reintentar errores a nivel de aplicación; esta ruta lo hacía, y el diff lo elimina sin confirmar que la ventana haya desaparecido.
````

Repite un bloque de estos por hallazgo, agrupados bajo `### Bloqueante` / `### Nimiedades` / `### Preguntas` (omite grupos vacíos). El bloque delimitado después de "Comentario" es lo único que el usuario copia a GitHub; todo lo demás es para navegación. Si todo está bien, solo la línea de veredicto.

## Publicación (solo si se solicita)

Si el usuario desea que los comentarios se publiquen en lugar de redactarse en el chat, confírmalo primero, luego usa `gh pr review` / `gh pr comment`. Por defecto, redacta en el chat.