Itérer sur la PR jusqu'à ce que les CI passent

Itérez continuellement sur la branche actuelle jusqu'à ce que tous les contrôles CI réussissent et que le feedback des reviews soit adressé.

Requis : GitHub CLI (gh) authentifiée.

Requis : Le CLI uv pour la gestion des packages Python, guide d'installation sur https://docs.astral.sh/uv/getting-started/installation/

Important : Tous les scripts doivent être exécutés depuis la racine du repository (où .git se trouve), pas depuis le répertoire de la skill. Utilisez le chemin complet vers le script via ${CLAUDE_SKILL_ROOT}.

Scripts fournis

`scripts/fetch_pr_checks.py`

Récupère l'état des contrôles CI et extrait les snippets d'échec des logs.

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

Retourne du 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 le feedback des reviews de la PR en utilisant l'échelle LOGAF.

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

Retourne du JSON avec le feedback catégorisé comme :

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

Le feedback des review bots (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`

Surveille les contrôles PR jusqu'à ce qu'ils atteignent tous un état terminal. Réessaye les échecs transitoires de gh, traite skipping et cancel comme des états terminaux, et attend que les contrôles s'enregistrent après un push frais au lieu de quitter trop 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

Workflow

1. Identifier la PR

gh pr view --json number,url,headRefName

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

2. Rassembler le feedback des reviews

Exécutez ${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_feedback.py pour obtenir le feedback catégorisé déjà posté sur la PR.

3. Traiter le feedback par priorité LOGAF

Correction automatique (sans demande) :

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

Lors de la correction du feedback :

Comprenez la cause racine, pas seulement le symptôme de surface
Cherchez des problèmes similaires dans le code à proximité ou les fichiers associés
Corrigez toutes les instances, pas seulement celle mentionnée

Cela inclut le feedback des review bots (éléments avec review_bot: true). Traitez-le comme du feedback humain :

Problème réel trouvé → corrigez-le
Faux positif → ignorez, mais expliquez pourquoi
Ne jamais ignorer silencieusement le feedback des review bots — vérifiez toujours la découverte

Demander à l'utilisateur de choisir :

low - présentez une liste numérotée et demandez laquelle adresser :

Trouvé 3 suggestions de faible priorité :
1. [l] "Envisagez de renommer cette variable" - @reviewer dans api.py:42
2. [nit] "Pourrait utiliser une list comprehension" - @reviewer dans utils.py:18
3. [style] "Ajouter une docstring" - @reviewer dans models.py:55

Lesquelles souhaitez-vous adresser ? (par ex., "1,3" ou "all" ou "none")

Ignorer silencieusement :

Threads resolved
Commentaires bot (informationnels uniquement — Codecov, Dependabot, etc.)

4. Vérifier le statut CI

Exécutez ${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_checks.py pour obtenir les données d'échec structurées.

Attendez si en attente : Si les contrôles des review bots (sentry, warden, cursor, bugbot, seer, codeql) sont encore en cours d'exécution, attendez avant de continuer — ils publient du feedback exploitable qui doit être évalué. Les bots informationnels (codecov) ne valent pas la peine d'attendre.

5. Corriger les échecs CI

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

Pour chaque échec :

Lisez le log complet, pas seulement le snippet. Utilisez gh run view <run-id> --log-failed si le snippet est tronqué ou ambigu. Identifiez l'assertion exacte qui échoue, l'exception, ou la règle de lint.
Tracez en arrière depuis l'échec jusqu'à 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 marquée. Ne vous arrêtez pas à la première explication plausible.
Vérifiez votre compréhension avant de toucher au code. Vous devriez pouvoir énoncer : "Cela échoue parce que X, qui a été introduit/affecté par Y." Si vous ne pouvez pas énoncer cela clairement, continuez l'investigation.
N'assumez pas que le feedback est faux. Si un contrôle signale quelque chose qui semble incorrect, enquêtez complètement avant de conclure que c'est un faux positif. La plupart des faux positifs apparents s'avèrent être de vrais problèmes à l'inspection plus approfondie.
Cherchez des instances associées. Si une erreur de type, un problème d'import, ou un bug logique existe à un site d'appel, cherchez le même motif dans le code à proximité et les fichiers associés. Corrigez toutes les instances.
Corrigez la cause racine avec des changements minimes et ciblés. Ne masquez pas le symptôme avec un contournement.
Enrichissez les tests au besoin. Si la correction introduit un comportement non couvert par les tests existants, ajoutez un cas de test (pas un fichier de test entièrement nouveau).

6. Vérifier localement, puis committer et pusher

Avant de committer, vérifiez vos corrections localement :

Si vous avez corrigé une échec de test : relancez ce test spécifique localement
Si vous avez corrigé une erreur de lint/type : relancez le linter ou le vérificateur de type sur les fichiers affectés
Pour toute correction de code : lancez les tests existants couvrant le code modifié

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

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

7. Surveiller CI et adresser le feedback

Continuez à surveiller l'état CI et le feedback des reviews en boucle au lieu de bloquer :

Exécutez uv run ${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_checks.py pour obtenir l'état CI actuel
Si tous les contrôles ont réussi, passez aux conditions de sortie
Si un contrôle a échoué (aucun en attente), retournez à l'étape 5
Si les contrôles sont encore en attente : a. Exécutez uv run ${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_feedback.py pour le nouveau feedback des reviews b. Adressez immédiatement tout nouveau feedback high/medium (même chose qu'à l'étape 3) c. Si des changements étaient nécessaires, committez et pushez (cela redémarre les CI), puis continuez la surveillance à partir de l'état de branche actualisé d. Attendez 30 secondes (ne pas augmenter lors des itérations suivantes), puis répétez à partir du sous-point 1
Après que tous les contrôles réussissent, attendez 10 secondes pour les commentaires des review bots en retard, 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 dans Claude Code, vous pouvez remplacer l'attente basée sur le sleep ci-dessus par MonitorTool afin que le polling se fasse en arrière-plan au lieu de consommer du contexte. C'est une optimisation Claude uniquement, pas le workflow par défaut pour les autres agents.

Lancez 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 repository au lieu de coder en dur un timeout de 15 minutes.

Après que MonitorTool rapporte la completion, relancez uv run ${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_checks.py :

Si un contrôle a échoué, retournez à l'étape 5.
Si tous les contrôles ont réussi, continuez au sous-point 5 ci-dessus.

Si vous avez pushé de nouveaux changements pendant la surveillance, démarrez une surveillance fraîche pour qu'elle observe le nouvel ensemble de runs CI.

8. Répéter

Si l'étape 7 a nécessité des changements de code (du feedback nouveau après que les CI aient réussi), retournez à l'étape 2 pour un nouveau cycle. Les échecs CI pendant la surveillance sont déjà gérés dans la boucle de polling de l'étape 7.

Conditions de sortie

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

Demander de l'aide : Même échec après 2 tentatives, le feedback a besoin de clarification, problèmes d'infrastructure.

Arrêter : Pas de PR existante, la branche a besoin d'un rebase.

Fallback

Si les scripts échouent, utilisez directement le CLI gh :

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

iterate-pr