Presentamos Reglas a Nivel de PR:
Revisa el PR, No Solo el Código

Estamos emocionados de presentar reglas a nivel de PR — una nueva categoría de reglas que analizan todo el Pull Request, no solo archivos individuales. Con dos nuevas etiquetas especiales, pr-level y git-history, ahora puedes aplicar las convenciones de PR de tu equipo automáticamente.

Qué Hay de Nuevo

El code review tradicional con IA analiza archivos uno por uno, buscando bugs, problemas de seguridad y patrones. Pero algunos de los aspectos más importantes de un buen PR no se pueden encontrar en ningún archivo individual:

Ahora diffray puede verificar todo esto — automáticamente, en cada PR.

Dos Nuevas Etiquetas: pr-level y git-history

Agregamos dos etiquetas especiales que cambian cómo el agente de IA procesa las reglas:

Reglas de Ejemplo que Puedes Usar Hoy

1. La Descripción del PR Debe Explicar el "Por Qué"

El problema más común con los PRs: listan qué cambió, pero no por qué. Los revisores pueden ver el diff — necesitan contexto.

- id: pr_description_explain_why
  agent: general
  title: La descripción del PR debe explicar la motivación
  importance: 7
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Verificar si la descripción del PR explica la razón de negocio
    - Verificar que responde "¿Por qué es necesario este cambio?"
    - Buscar contexto sobre el problema que se está resolviendo
  tags:
    - pr-level
    - quality

2. Mensajes de Commit Convencionales

Aplica formato de commit consistente para changelogs automatizados y versionado semántico:

- id: commit_message_format
  agent: general
  title: Los mensajes de commit deben seguir formato convencional
  importance: 5
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Usar git log --oneline para revisar commits recientes
    - Verificar que commits sigan formato type(scope): description
    - Verificar mensajes claros (no "fix stuff", "WIP")
  examples:
    bad: |
      fix stuff
      WIP
      update code
    good: |
      feat(auth): add OAuth2 login with Google
      fix(api): handle null response from payment service
  tags:
    - git-history
    - automation

3. Los Cambios Importantes Deben Estar Documentados

Nada rompe la confianza más rápido que cambios importantes no documentados llegando a producción:

- id: breaking_changes_documented
  agent: general
  title: Los cambios importantes deben estar claramente documentados
  importance: 9
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Verificar si los cambios modifican APIs públicas o eliminan funcionalidades
    - Si son importantes, verificar que los mensajes de commit incluyan BREAKING CHANGE
    - Verificar guía de migración en la descripción del PR
  tags:
    - pr-level
    - git-history
    - breaking-changes

4. PRs de Responsabilidad Única

Los PRs que mezclan funcionalidades, correcciones de bugs y refactoring son imposibles de revisar bien:

- id: pr_single_responsibility
  agent: general
  title: El PR mezcla cambios no relacionados
  importance: 7
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Revisar archivos cambiados para identificar áreas distintas de cambio
    - Verificar si los cambios abarcan múltiples funcionalidades no relacionadas
    - Marcar si el PR toca auth Y payment Y styling
  tags:
    - pr-level
    - quality

5. Referencias a Tickets Requeridas

Para trazabilidad y notas de release, cada PR debe enlazar a un issue:

- id: pr_ticket_reference
  agent: general
  title: El PR debe referenciar un issue o ticket
  importance: 5
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Revisar commits por referencias a tickets (PROJ-123, #123, ENG-456)
    - Buscar URLs de issues en mensajes de commit
    - Solo marcar si NINGÚN commit tiene referencia a ticket
  tags:
    - pr-level
    - git-history
    - traceability

Cómo Funciona Internamente

El agente general ha sido actualizado con instrucciones especiales para manejar estas etiquetas:

Las reglas con always_run: true se ejecutan en cada PR sin importar qué archivos cambiaron. Esto las hace perfectas para verificaciones a nivel de PR que no dependen de patrones de archivos específicos.

Primeros Pasos

Agregar reglas a nivel de PR a tu proyecto es simple:

Hemos publicado reglas de ejemplo en nuestro repositorio de reglas específicas de proyecto que puedes copiar y personalizar.

Por Qué Esto Importa

Los buenos PRs son más que solo código funcionando. Son documentación para futuros desarrolladores. Son registros de auditoría para cumplimiento. Son la diferencia entre "¿qué pasó aquí?" y "ah, entiendo."

Las reglas a nivel de PR convierten conocimiento tribal en enforcement automatizado. En lugar de esperar que todos recuerden enlazar tickets, documentar cambios importantes y escribir descripciones significativas — obtienes feedback consistente en cada PR.