iterate-pr

Itérer sur une PR jusqu'à ce que CI passe. À utiliser lorsque vous devez corriger les défaillances de CI, traiter les retours d'examen ou continuellement repousser les correctifs jusqu'à ce que tous les contrôles soient au vert. Automatise le cycle retour-correction-transmission-attente.

npx skills add https://github.com/getsentry/skills --skill iterate-pr

Itérer sur une PR Jusqu'au Passage des CI

Itérez continuellement sur la branche actuelle jusqu'à ce que tous les contrôles CI passent et que les commentaires d'examen soient adressés.

Prérequis : GitHub CLI (gh) authentifié.

Prérequis : CLI uv pour la gestion des packages Python, guide d'installation à https://docs.astral.sh/uv/getting-started/installation/

Important : Tous les scripts doivent être exécutés depuis le répertoire racine du dépôt (où .git se trouve), et non depuis le répertoire skill. Utilisez le chemin complet du script via ${CLAUDE_SKILL_ROOT}.

Scripts Fournis

scripts/fetch_pr_checks.py

Récupère le statut des contrôles CI et extrait les extraits d'erreurs des journaux.

uv run ${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_checks.py [--pr NUMBER]

Retourne JSON :

{
  "pr": {"number": 123, "branch": "feat/foo"},
  "summary": {"total": 5, "passed": 3, "failed": 2, "pending": 0},
  "checks": [
    {"name": "tests", "status": "fail", "log_snippet": "...", "run_id": 123},
    {"name": "lint", "status": "pass"}
  ]
}

scripts/fetch_pr_feedback.py

Récupère et catégorise les commentaires d'examen des PR en utilisant l'échelle LOGAF.

uv run ${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_feedback.py [--pr NUMBER]

Retourne JSON avec feedback catégorisé comme :

  • high - Doit être adressé avant fusion (h:, blocker, changes requested)
  • medium - Devrait être adressé (m:, feedback standard)
  • low - Optionnel (l:, nit, style, suggestion)
  • bot - Commentaires automatisés informatifs (Codecov, Dependabot, etc.)
  • resolved - Fils de discussion déjà résolus

Le feedback des bots d'examen (de Sentry, Warden, Cursor, Bugbot, CodeQL, etc.) apparaît dans high/medium/low avec review_bot: true — il n'est PAS placé dans le bucket bot.

scripts/monitor_pr_checks.py

Supervise les contrôles PR jusqu'à ce qu'ils atteignent tous un état terminal. Réessaye les défaillances transitoires de gh, traite skipping et cancel comme des états terminaux, et attend que les contrôles s'enregistrent après un nouveau push au lieu de quitter tôt.

uv run ${CLAUDE_SKILL_ROOT}/scripts/monitor_pr_checks.py [--pr NUMBER]

Affiche un marqueur terminal suivi d'un résumé des contrôles séparés par des tabulations :

  • ALL_CHECKS_PASSED
  • CHECKS_DONE_WITH_FAILURES

Flux de Travail

1. Identifier la PR

gh pr view --json number,url,headRefName

Arrêtez s'il n'existe pas de PR pour la branche actuelle.

2. Rassembler les Commentaires d'Examen

Exécutez ${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_feedback.py pour obtenir les commentaires catégorisés déjà publiés sur la PR.

3. Traiter les Commentaires par Priorité LOGAF

Correction automatique (sans invite) :

  • high - doit être adressé (blockers, sécurité, changes requested)
  • medium - devrait être adressé (feedback standard)

Lors de la correction des commentaires :

  • Comprenez la cause racine, pas seulement le symptôme de surface
  • Vérifiez les problèmes similaires dans le code environnant ou les fichiers connexes
  • Corrigez toutes les instances, pas seulement celle mentionnée

Cela inclut le feedback des bots d'examen (éléments avec review_bot: true). Traitez-le de la même manière que le feedback humain :

  • Problème réel trouvé → le corriger
  • Faux positif → l'ignorer, mais expliquez pourquoi
  • Ne jamais ignorer silencieusement le feedback des bots d'examen — toujours vérifier la conclusion

Demander à l'utilisateur de sélectionner :

  • low - présenter une liste numérotée et demander lesquels adresser :
Found 3 low-priority suggestions:
1. [l] "Consider renaming this variable" - @reviewer in api.py:42
2. [nit] "Could use a list comprehension" - @reviewer in utils.py:18
3. [style] "Add a docstring" - @reviewer in models.py:55

Which would you like to address? (e.g., "1,3" or "all" or "none")

Ignorer silencieusement :

  • fils de discussion resolved
  • commentaires bot (informatifs uniquement — Codecov, Dependabot, etc.)

4. Vérifier le Statut CI

Exécutez ${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_checks.py pour obtenir des données de défaillance structurées.

Attendez si en attente : Si les contrôles des bots d'examen (sentry, warden, cursor, bugbot, seer, codeql) sont toujours en cours, attendez avant de continuer — ils publient des commentaires actionnables qui doivent être évalués. Les bots informatifs (codecov) ne valent pas la peine d'attendre.

5. Corriger les Défaillances CI

L'investigation est obligatoire avant toute correction. Ne devinez pas, n'assumez pas, et n'inférez pas la cause à partir du nom du contrôle ou d'une lecture superficielle de l'erreur. Vous devez retracer la défaillance à sa cause racine dans le code réel.

Pour chaque défaillance :

  1. Lisez le journal complet, pas seulement l'extrait. Utilisez gh run view <run-id> --log-failed si l'extrait est tronqué ou ambigu. Identifiez l'assertion exacte qui échoue, l'exception, ou la règle lint.
  2. Retracer à rebours de la défaillance à la cause. Suivez la stack trace ou le message d'erreur dans le code source. Lisez les fonctions, types et sites d'appel pertinents — pas seulement la ligne signalée. Ne vous arrêtez pas à la première explication plausible.
  3. Vérifiez votre compréhension avant de modifier le code. Vous devriez pouvoir affirmer : « Ceci échoue parce que X, qui a été introduit/affecté par Y. » Si vous ne pouvez pas l'affirmer clairement, continuez à investiguer.
  4. Ne supposez pas que le feedback est incorrect. Si un contrôle signale quelque chose qui semble incorrect, investigez complètement avant de conclure que c'est un faux positif. La plupart des faux positifs apparents s'avèrent être des problèmes réels à l'examen approfondi.
  5. Vérifiez les instances connexes. Si une erreur de type, un problème d'import, ou un bug de logique existe sur un site d'appel, cherchez le même motif dans le code environnant et les fichiers connexes. Corrigez toutes les instances.
  6. Corrigez la cause racine avec des changements minimes et ciblés. Ne masquez pas le symptôme avec une solution de contournement.
  7. Étendez les tests si nécessaire. Si la correction introduit un comportement non couvert par les tests existants, ajoutez un cas de test (pas tout un nouveau fichier de test).

6. Vérifier Localement, puis Committer et Pousser

Avant de committer, vérifiez vos corrections localement :

  • Si vous avez corrigé une défaillance de test : réexécutez ce test spécifique localement
  • Si vous avez corrigé une erreur lint/type : réexécutez le linter ou le type checker sur les fichiers affectés
  • Pour toute correction de code : exécutez les tests existants couvrant le code modifié

Si la vérification locale échoue, corrigez avant de continuer — ne poussez pas du code cassé connu.

git add <files>
git commit -m "fix: <descriptive message>"
git push

7. Superviser CI et Adresser les Commentaires

Continuez à superviser le statut CI et les commentaires d'examen en boucle au lieu de bloquer :

  1. Exécutez uv run ${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_checks.py pour obtenir le statut CI actuel
  2. Si tous les contrôles ont passé, procédez aux conditions de sortie
  3. Si des contrôles ont échoué (aucun en attente), retournez à l'étape 5
  4. Si les contrôles sont toujours en attente : a. Exécutez uv run ${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_feedback.py pour les nouveaux commentaires d'examen b. Adressez immédiatement tout nouveau feedback high/medium (même que l'étape 3) c. Si des changements étaient nécessaires, committez et poussez (cela relance CI), puis continuez la supervision depuis l'état rafraîchi de la branche d. Dormez 30 secondes (ne pas augmenter sur les itérations suivantes), puis répétez à partir du sous-point 1
  5. Après que tous les contrôles passent, attendez 10 secondes pour les commentaires des bots d'examen qui arrivent tardivement, puis exécutez uv run ${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_feedback.py. Adressez tout nouveau feedback high/medium — si des changements sont nécessaires, retournez à l'étape 6.

Si vous êtes en Claude Code, vous pouvez remplacer l'attente basée sur sleep ci-dessus avec MonitorTool afin que le polling se fasse en arrière-plan au lieu de consommer du contexte. Ceci est une optimisation spécifique à Claude, non le flux de travail par défaut pour les autres agents.

Exécutez le script monitor fourni via MonitorTool avec persistent: false :

uv run ${CLAUDE_SKILL_ROOT}/scripts/monitor_pr_checks.py

Définissez timeout_ms pour correspondre à la durée CI normale du dépôt au lieu de coder en dur un timeout de 15 minutes.

Après que MonitorTool rapporte l'achèvement, réexécutez uv run ${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_checks.py :

  • Si des contrôles ont échoué, retournez à l'étape 5.
  • Si tous les contrôles ont passé, continuez au sous-point 5 ci-dessus.

Si vous avez poussé de nouveaux changements pendant la supervision, démarrez une nouvelle monitor afin qu'elle supervise le nouvel ensemble de runs CI.

8. Répéter

Si l'étape 7 a nécessité des changements de code (à partir de nouveaux commentaires après le passage de CI), retournez à l'étape 2 pour un nouveau cycle. Les défaillances CI pendant la supervision sont déjà traitées dans la boucle de polling de l'étape 7.

Conditions de Sortie

Succès : Tous les contrôles passent, la vérification post-CI du feedback est propre (aucun nouveau feedback high/medium non adressé y compris les conclusions des bots d'examen), l'utilisateur a décidé des éléments de faible priorité.

Demander de l'aide : Même défaillance après 2 tentatives, le feedback nécessite une clarification, problèmes d'infrastructure.

Arrêter : Aucune PR n'existe, la branche doit être rebasée.

Secours

Si les scripts échouent, utilisez CLI gh directement :

  • gh pr checks name,state,bucket,link
  • gh run view <run-id> --log-failed
  • gh api repos/{owner}/{repo}/pulls/{number}/comments