Examiner une PR

Examiner de manière autonome les commentaires de PR et l'état de compilation, en résolvant ce qui peut être fait avec une confiance élevée (>=80%) et en signalant le reste pour examen humain.

Workflow

Note : ce repository nécessite que vous utilisiez node 24. Utilisez nvm pour basculer vers node 24 avant d'exécuter des commandes :

nvm use 24

1. Rassembler le contexte

# Obtenir le numéro de PR pour la branche actuelle
gh pr view --json number,headRefName,url

# Obtenir les threads de review avec le statut de résolution
gh api graphql -f query='
  query($owner: String!, $repo: String!, $number: Int!) {
    repository(owner: $owner, name: $repo) {
      pullRequest(number: $number) {
        reviewThreads(first: 100) {
          nodes {
            id
            isResolved
            comments(first: 50) {
              nodes {
                body
                path
                line
                author { login }
                createdAt
                databaseId
              }
            }
          }
        }
      }
    }
  }
'

Filtrer pour afficher uniquement les threads non résolus.

2. Trier chaque commentaire non résolu

Lire le code référencé et enquêter. Classifier selon :

A. Faux positif / déjà résolu — Le problème n'existe plus dans le code actuel.

Répondre en expliquant pourquoi, en citant du code ou un commit spécifique.
Résoudre le thread.

B. Correction triviale (>=80% de confiance) — Correction évidente et mécanique. Aucune décision de conception ou question d'opinion. Exemples : typos, vérifications de null manquantes, noms de variables incorrects, erreur d'une unité, imports manquants.

Effectuer la correction.
Répondre en décrivant ce qui a été modifié.
Résoudre le thread.

C. Nécessite une intervention humaine (<80% de confiance) — Question de conception, refactorisation importante ou correction ambiguë.

NE PAS résoudre.
Ajouter au résumé de fin de session.

3. Répondre et résoudre les threads

Répondre à un commentaire :

gh api repos/{owner}/{repo}/pulls/{number}/comments/{comment_id}/replies \
  -f body="<your reply>"

Résoudre un thread :

gh api graphql -f query='
  mutation($threadId: ID!) {
    resolveReviewThread(input: {threadId: $threadId}) {
      thread { isResolved }
    }
  }
' -f threadId="$THREAD_ID"

Toujours effectuer les corrections, puis répondre, puis résoudre les threads associés (dans cet ordre).

4. Vérifier l'état de compilation

gh pr checks --json name,status,conclusion

Investiguer les échecs par catégorie :

Erreurs de lint — Exécuter yarn lint-current. Corriger si mécanique (formatage, ordre des imports, variables non utilisées). Signaler si la règle de lint elle-même est discutable.

Erreurs de type — Exécuter yarn typecheck depuis la racine du repo. Corriger les incompatibilités de type simples. Signaler si la correction nécessite des décisions architecturales.

Échecs de tests unitaires — Exécuter yarn test run dans le workspace pertinent. Corriger si l'attente du test est clairement obsolète en raison de modifications de code intentionnelles. Signaler si l'échec révèle un vrai bug ou une préoccupation de conception.

Échecs de snapshots E2E — Déterminer si les modifications de code de la PR doivent causer des différences visuelles :

Si oui (changements UI, mises à jour de style) : ajouter le label update-snapshots pour déclencher le workflow de mise à jour automatisée :
```
gh pr edit --add-label "update-snapshots"
```
Si non : signaler comme régression non intentionnelle pour examen humain.

Échecs mystérieux/inattendus — Ne pas tenter de corriger. Signaler pour examen humain avec la sortie d'erreur.

5. Commiter et pousser les corrections

git add <specific files>
git commit -m "Address PR review feedback

- <summary of changes>"
git push

Staging uniquement des fichiers spécifiques. Ne jamais forcer un push. Ne jamais utiliser git add -A.

6. Résumé de fin de session

Toujours terminer par :

## PR review summary

### Resolved
- <thread>: <what was done>

### Fixed
- <description of fix>

### Needs your input
- <thread>: <why it needs human judgment>

### Build status
- <status of each check, any actions taken>

Omettre les sections vides.

Directives

Seuil conservateur : agir uniquement avec >=80% de confiance que la correction est juste et non controversée.
Ne jamais résoudre les commentaires soulevant des questions de conception ou des questions d'opinion.
Ne jamais résoudre sans répondre d'abord.
Lire le code réel avant de conclure qu'un commentaire est un faux positif.
Vérifier que les corrections ne cassent pas les types (yarn typecheck) ni le lint (yarn lint-current).
Ne pas modifier les attentes des tests à moins que le changement soit clairement intentionnel.

shepherd-pr