KitewellTélécharger KitewellTélécharger pour MacTélécharger pour Windows
← Toutes les tâches

À chaque nouvelle pull request

Chaque pull request attend ma première lecture, et la plupart de ce que je signale, un second relecteur attentif l’aurait repéré.

Comment ça se passe aujourd’hui

Nouvelle pull request.L’ouvrir.Lire la description.Faire défiler le diff.Test manquant.Commenter.Erreur non vérifiée.Commenter.Retour à ce que je faisais.

Chaque pull request, avant que quiconque d’autre ne la regarde.

Dites-le une fois à Kitewell

Vous
Quand une pull request est ouverte dans mon dépôt, demandez à mon agent Codex de la relire, à mon agent Claude Code de vérifier cette revue par rapport au code, puis publiez la revue vérifiée sur la pull request une fois que j’ai approuvé.

C’est toute la configuration. Kitewell détaille chaque étape pour que vous la vérifiiez, et rien n’est enregistré tant que vous ne l’appliquez pas.

Pour votre propre version, copiez ce texte et complétez les blancs :

Créez un workflow qui, quand une pull request est ouverte dans [mon dépôt], demande à mon agent Codex de la relire, à mon agent Claude Code de vérifier cette revue par rapport au code, et publie la revue vérifiée sur la pull request une fois que j’ai approuvé.

Télécharger KitewellTélécharger pour MacTélécharger pour WindowsKitewell fonctionne sur Mac et Windows. Mac · Windows

Ensuite, la tâche s’exécute toute seule

Revue de #482En cours sur cet ordinateur

  1. Relire la pull requestCodex la lit avec gh et liste les bugs, les tests manquants et les changements risqués, chacun avec son fichier et sa ligne.Terminé
  2. Vérifier la revueClaude Code confronte chaque remarque au diff, écarte celles qui sont fausses et ajoute ce qui a été manqué.Terminé
  3. Attendre votre accordLisez la revue vérifiée, puis approuvez, renvoyez avec une note ou refusez.En attente de vous
  4. La publier sur la pull requestgh pr review --comment, avec votre propre compte GitHub.Terminé

Ce que vous obtenez à la place

Vérifier la revue

  • #482 Move sessions to the new store
  • Confirmé : logout.ts lit encore l’ancienne clé de session, ligne 41.
  • Confirmé : aucun test ne couvre une session expirée.
  • Écarté : un contrôle de null manquant signalé par Codex ; l’appelant le vérifie déjà.

Publier la revue vérifiée sur la pull request ?

Données d’exemple

Bon à savoir

  • GitHub lance chaque exécution via le relais de Kitewell, sans aucun port ouvert sur votre ordinateur. Configurez le webhook pour ne recevoir que pull_request.opened, et faites vérifier la signature de GitHub par Kitewell.
  • Les deux agents lancent gh pour lire la pull request, ce qui demande un accès réseau et l’autorisation d’exécuter des commandes : accordez-la dans les réglages propres à chaque outil, ou activez « Ignorer les demandes d’autorisation » sur son entrée dans « Agents et modèles ». Ils lisent du code écrit par quelqu’un d’autre : utilisez cela là où vous savez qui ouvre les pull requests.
  • Sous Windows, un événement de pull request de plus de 30 000 caractères environ peut ne pas encore lancer d’exécution.

Ce qu’il faut

  • Un agent en ligne de commande comme Codex ou Claude Code, installé et connecté
  • Un dépôt Git et la commande gh
  • Kitewell Personal ou Team, connecté à Dagu Cloud, pour le webhook GitHub

Autres tâches