Vérification PR

Exécute les vérifications de pré-fusion sur la branche courante. La skill itère à travers les validations sous validations, exécute chacune dont le déclencheur correspond au diff, et rapporte PASS ou FAIL. Les tests d'intégration, les tests Playwright et les tests Poshi sont hors de portée. Utilisez la skill test-plan quand leur couverture est nécessaire.

Préconditions

Sur une branche de fonctionnalité. Quand HEAD est master ou détaché, quitter avec un message d'une ligne.
Répertoire de travail propre. git status --porcelain doit retourner vide. Quand le répertoire est modifié, abandonner et demander au développeur de commiter d'abord.
Rebasé sur le dernier master. Résoudre la branche distante master. Préférer upstream, sinon la branche distante dont l'URL pointe vers liferay/liferay-portal (vérifier git remote --verbose). Quand aucune ne se résout, comparer git merge-base HEAD master à git rev-parse master. Abandonner et dire au développeur de rebaser quand les deux diffèrent, et avertir que la branche n'a pas été vérifiée contre une branche distante. Sinon exécuter ces étapes.
1. git fetch <remote> master.
2. Avancer rapidement le master local vers la pointe récupérée. Quand master est extrait dans un autre répertoire de travail, l'avancer rapidement là avec git -C <worktree> merge --ff-only <remote>/master. Sinon le mettre à jour en place avec git fetch <remote> master:master, qui crée aussi master s'il n'existe pas. Les deux sont avance rapide uniquement. Quand la commande échoue (parce que master a divergé ou son répertoire de travail n'est pas propre), avertir le développeur et arrêter la exécution.
3. git rebase <remote>/master. Sur un rebase propre, continuer contre la branche rebasée. En cas de conflit, lister les fichiers non fusionnés (git diff --diff-filter=U --name-only) et demander au développeur qui devrait résoudre les conflits. Quand le développeur vous demande de les résoudre, corriger les conflits, git add les fichiers, et exécuter git rebase --continue. Dans tous les autres cas (le développeur les résout, les conflits ne peuvent pas être résolus, ou le rebase échoue autrement) exécuter git rebase --abort et arrêter la exécution.
La ligne de base du diff est le master local. Après le rebase, le diff à trois points contre le master local est la ligne de base.
Le diff est non vide. Quand le diff à trois points ne produit aucun fichier, quitter avec un message d'une ligne — aucune validation ne produit de signal utile sur une branche propre.

Entrée

Diff

git diff --name-status "$(git merge-base HEAD master)...HEAD"

Sortie attendue

PASS ou FAIL, suivi d'une table Results Summary que les skills pr et pr-check-publish réutilisent pour enregistrer ce qui a été testé sur la PR GitHub.

La procédure s'exécute en deux passes sur les validations, dans l'ordre ci-dessous. L'ordre est piloté par les dépendances : dérive d'abord (les validations ultérieures voient l'arbre régénéré), puis formatage, puis build, puis tests.

Traiter chaque validation dans un sous-agent.

Pass 1 : Estimation

Lire chaque fichier de validation sous .claude/skills/pr-check/validations en un seul lot parallèle — un appel à l'outil Read par fichier, tous dans le même tour d'utilisation d'outils. De chaque fichier, prendre la regex à l'intérieur de sa section ## Match.

À votre tour suivant, composer un unique script bash qui :

calcule le diff : git diff --name-only "$(git merge-base HEAD master)...HEAD"
pour chaque validation, teste sa regex contre le diff et affiche le nom de la validation quand elle se déclenche (un ! au début de la regex inverse : se déclencher quand un chemin du diff ne correspond pas au reste)
&! dans la regex la divise en un côté inclusion et un côté exclusion. La validation se déclenche quand un chemin du diff correspond au côté inclusion mais pas au côté exclusion.
s'exécute comme un unique appel à l'outil Bash

À partir de la sortie du script, sommer les valeurs ## Time Estimate des validations correspondantes pour le total cumulatif. La correspondance est mécanique ; consulter la prose ## Trigger de chaque fichier uniquement quand un résultat nécessite du contexte humain (par ex., rattrapage Service Builder sortie uniquement).

Quand le total dépasse 20 minutes, surfacer la répartition et demander au développeur s'il faut réduire une validation ou procéder.

Pass 2 : Exécution

Pour chaque validation correspondante, créer un sous-agent. Lui passer uniquement les sections ## Command et ## Autocommit du fichier de validation, pas le fichier complet. Enregistrer PASS ou FAIL. Ne pas s'arrêter sur FAIL — continuer afin que le développeur voit l'image complète.

Quand le Command de la validation est un build (gradle, ant, npm, jest), borner la sortie :

<command> 2>&1 | tail --lines=100

Décider PASS/FAIL à partir des marqueurs de succès de l'outil de build dans la sortie capturée (BUILD SUCCESSFUL / BUILD FAILED, Tests: N passed, M failed, etc.). Appliquer uniquement aux commandes de build. Laisser inchangées les commandes inertes comme git status --porcelain et git diff --quiet.

Quand toutes les validations passent, rapporter PASS. Quand l'une échoue, rapporter FAIL et surfacer les validations échouées.

Results Summary

Après que les deux passes se complètent, émettre un bloc Results Summary. C'est l'enregistrement canonique de ce qui a été testé, embarqué verbatim par la skill pr dans la description de la PR et réutilisé par la skill pr-check-publish lors de l'enregistrement d'une exécution sur une PR existante.

Capturer le commit testé avec git rev-parse HEAD après que Pass 2 se complète, afin que le SHA reflète l'arbre qui a été réellement exercé — y compris les autocommits que les validations ont effectués, comme le commit source-format <TICKET> SF. C'est le commit que la skill pr pousse comme tête de PR et le commit auquel le webhook lie le statut pr-check, afin qu'un relecteur puisse dire si la tête courante est celle qui a été testée.

Le bloc est l'état global et le SHA testé, suivi d'une table avec une ligne par validation correspondante — les validations qui ont réellement s'exécuté, dans l'ordre d'exécution ci-dessus. Les validations dont la regex ## Match ne s'est pas déclenchée sont omises plutôt que listées comme ignorées, afin que la table reflète uniquement ce que le diff a exercé.

**pr-check: PASS** — tested on `<head-SHA>`

| Validation | Result |
| --- | --- |
| Source Format | PASS |
| Full Portal Build | PASS |
| Java Unit Tests | PASS |

L'état global est PASS uniquement quand chaque ligne est PASS ; toute ligne FAIL le rend FAIL.