Présentation des Règles Niveau PR :
Révisez le PR, Pas Seulement le Code

Nous sommes ravis de présenter les règles niveau PR — une nouvelle catégorie de règles qui analysent l'ensemble du Pull Request, pas seulement les fichiers individuels. Avec deux nouveaux tags spéciaux, pr-level et git-history, vous pouvez maintenant appliquer automatiquement les conventions PR de votre équipe.

Quoi de Neuf

Le code review IA traditionnel analyse les fichiers un par un, vérifiant les bugs, les problèmes de sécurité et les patterns. Mais certains des aspects les plus importants d'un bon PR ne peuvent être trouvés dans aucun fichier individuel :

Maintenant diffray peut vérifier tout cela — automatiquement, sur chaque PR.

Deux Nouveaux Tags : pr-level et git-history

Nous avons ajouté deux tags spéciaux qui changent la façon dont l'agent IA traite les règles :

Exemples de Règles Utilisables Dès Aujourd'hui

1. La Description du PR Doit Expliquer le « Pourquoi »

Le problème le plus courant avec les PRs : ils listent ce qui a changé, mais pas pourquoi. Les réviseurs peuvent voir le diff — ils ont besoin de contexte.

- id: pr_description_explain_why
  agent: general
  title: La description du PR doit expliquer la motivation
  importance: 7
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Vérifier si la description du PR explique la raison métier
    - Vérifier qu'elle répond à "Pourquoi ce changement est-il nécessaire ?"
    - Chercher le contexte sur le problème résolu
  tags:
    - pr-level
    - quality

2. Messages de Commit Conventionnels

Appliquez un format de commit cohérent pour les changelogs automatisés et le versionnement sémantique :

- id: commit_message_format
  agent: general
  title: Les messages de commit doivent suivre le format conventionnel
  importance: 5
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Utiliser git log --oneline pour vérifier les commits récents
    - Vérifier que les commits suivent le format type(scope): description
    - Vérifier les messages clairs (pas "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. Les Breaking Changes Doivent Être Documentés

Rien ne brise la confiance plus vite que des breaking changes non documentés atteignant la production :

- id: breaking_changes_documented
  agent: general
  title: Les breaking changes doivent être clairement documentés
  importance: 9
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Vérifier si les changements modifient des APIs publiques ou suppriment des fonctionnalités
    - Si breaking, vérifier que les messages de commit incluent BREAKING CHANGE
    - Vérifier la présence d'un guide de migration dans la description du PR
  tags:
    - pr-level
    - git-history
    - breaking-changes

4. PRs à Responsabilité Unique

Les PRs qui mélangent fonctionnalités, corrections de bugs et refactoring sont impossibles à bien réviser :

- id: pr_single_responsibility
  agent: general
  title: Le PR mélange des changements non liés
  importance: 7
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Réviser les fichiers modifiés pour identifier les zones de changement distinctes
    - Vérifier si les changements couvrent plusieurs fonctionnalités non liées
    - Signaler si le PR touche auth ET paiement ET styling
  tags:
    - pr-level
    - quality

5. Références de Tickets Requises

Pour la traçabilité et les notes de release, chaque PR devrait être lié à une issue :

- id: pr_ticket_reference
  agent: general
  title: Le PR devrait référencer une issue ou un ticket
  importance: 5
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Vérifier les commits pour les références de tickets (PROJ-123, #123, ENG-456)
    - Chercher les URLs d'issues dans les messages de commit
    - Signaler seulement si AUCUN commit n'a de référence de ticket
  tags:
    - pr-level
    - git-history
    - traceability

Comment Ça Fonctionne Sous le Capot

L'agent general a été mis à jour avec des instructions spéciales pour gérer ces tags :

Les règles avec always_run: true s'exécutent sur chaque PR indépendamment des fichiers modifiés. Cela les rend parfaites pour les vérifications niveau PR qui ne dépendent pas de patterns de fichiers spécifiques.

Pour Commencer

Ajouter des règles niveau PR à votre projet est simple :

Nous avons publié des exemples de règles dans notre dépôt project-specific-rules que vous pouvez copier et personnaliser.

Pourquoi C'est Important

Les bons PRs concernent plus que du code fonctionnel. Ce sont de la documentation pour les futurs développeurs. Ce sont des pistes d'audit pour la conformité. C'est la différence entre « que s'est-il passé ici ? » et « ah, je comprends ».

Les règles niveau PR transforment le savoir tribal en application automatisée. Au lieu d'espérer que tout le monde se souvienne de lier les tickets, documenter les breaking changes et écrire des descriptions significatives — vous obtenez des retours cohérents sur chaque PR.