Comment transformer les pull requests GitHub en rapport hebdomadaire dans Notion

Rédiger un rapport d’ingénierie hebdomadaire signifie généralement parcourir manuellement des dizaines de pull requests, copier des liens et déterminer ce qui a été fusionné par rapport à ce qui doit encore être relu.

Avec Leina, vous pouvez automatiser ce flux de travail directement depuis le chat d’équipe. En connectant GitHub et Notion, un agent peut rassembler les PR, rédiger un résumé structuré avec des liens vers les sources et ajouter la version approuvée à votre espace de travail Notion. La clé pour le rendre fiable est de séparer le brouillon de l’étape d’écriture, afin de pouvoir vérifier les chiffres avant publication.

Commencez par une semaine terminée, afin de pouvoir comparer le brouillon avec des enregistrements que vous connaissez déjà.

Définir le périmètre du rapport

Avant de demander à un agent IA de récupérer des enregistrements, établissez des règles de délimitation claires pour ce qui doit figurer dans le rapport. Pour votre première exécution, limitez-vous à un seul dépôt et à une semaine terminée.

Section	Règle d’inclusion	Ce qu’elle communique
Fusionnées cette semaine	L’horodatage de fusion se situe dans les limites de début et de fin spécifiées	Les changements entrés dans la branche cible pendant la période
Actuellement ouvertes	La PR est ouverte au moment de la requête	Travail en cours, statut de brouillon et blocages de relecture documentés

Remarque sur les PR ouvertes : Une liste de PR ouvertes décrit le dépôt au moment de la requête. Pour rapporter ce qui était ouvert à la fin d’une semaine précédente, vous avez besoin d’un instantané enregistré ou de preuves des changements d’état depuis lors. Conserver des rapports datés vous fournit ces instantanés pour de futures comparaisons.

Vous pouvez vérifier les enregistrements sources à l’aide des qualificateurs de recherche d’état et de date de fusion de GitHub :

repo:OWNER/REPOSITORY is:pr is:merged merged:2026-09-28T00:00:00+00:00..2026-10-04T23:59:59+00:00

Remplacez le dépôt et les dates, en gardant le fuseau horaire cohérent avec votre rapport. Cet exemple utilise +00:00 pour UTC ; utilisez les décalages appropriés pour votre fenêtre de rapport si votre équipe travaille dans un autre fuseau horaire.

Connecter GitHub et Notion

Dans Leina Console, autorisez les deux connexions d’espace de travail :

GitHub : Utilisez un compte pouvant lire le dépôt cible et une connexion qui expose les détails de PR nécessaires au résumé.
Notion : Pour l’étape d’enregistrement, utilisez une connexion pouvant lire et ajouter du contenu à la page prévue.

Consultez les opérations disponibles dans Integrations et vos comptes autorisés sous Connections. Le membre demandeur doit également avoir la permission d’utiliser ces connexions. Rédigez le rapport dans votre chat d’équipe connecté, puis écrivez dans Notion après l’avoir relu.

Demander à l’agent un brouillon relisible

Commencez par une invite qui exige des liens vers les sources et une gestion explicite des informations manquantes. Copiez et adaptez cette demande :

Prépare un rapport d’ingénierie hebdomadaire pour [owner/repository], couvrant [start timestamp] à [end timestamp] en [timezone].

PR fusionnées : Liste toutes les PR fusionnées dans cette fenêtre. Pour chaque PR, indique son numéro, son titre, son auteur, l’heure de fusion, le lien vers la source et un résumé de 1 à 2 phrases des changements, fondé sur sa description de PR et sur les changements disponibles via l’outil.

PR actuellement ouvertes : Liste les PR ouvertes à l’instant, en notant leur statut de brouillon et tout relecteur ou blocage documenté.

Contexte manquant : Si une PR a une description vide ou un impact peu clair, marque-la explicitement comme « Impact non documenté » — n’invente pas de raisons commerciales ni de résultats.

Avis de récupération : Note l’horodatage de récupération, récupère toutes les pages de résultats dans le périmètre lorsque cela est pris en charge, et signale toute récupération incomplète ou tout enregistrement inaccessible.

Renvoie le brouillon complet ici dans le chat. N’écris pas encore dans Notion.

Si votre équipe utilise une mise en page markdown standardisée, vous pouvez également fournir le modèle de rapport hebdomadaire vierge comme référence de formatage.

Vérifier le brouillon par rapport à GitHub

Avant de pousser quoi que ce soit vers Notion, comparez la liste des enregistrements et vérifiez par échantillonnage ses résumés :

Vérifiez le nombre par rapport à la recherche GitHub : Exécutez la requête avec le qualificateur de fusion dans la recherche GitHub. Le nombre de PR correspond-il à la liste des PR fusionnées de l’agent ?
Vérifiez les horodatages limites : Comparez les PR proches des deux extrémités de la fenêtre temporelle avec la liste source. Vérifiez leurs horodatages et le fuseau horaire utilisé pour les sélectionner.
Séparez les fusionnées des fermées : Vérifiez que les PR fermées et abandonnées sans fusion ne se sont pas glissées par erreur dans la section des PR fusionnées.
Séparez les fusionnées des déployées : Fusionner du code dans main ne signifie pas automatiquement qu’il a été déployé en production. Gardez le résumé centré sur ce qui a réellement été fusionné, sauf si un enregistrement de déploiement ou une autre source explicite confirme le déploiement dans cet environnement. Une étiquette de version seule identifie une version de code.
Vérifiez les résumés hallucinés : Si le titre d’une PR est simplement « fix typo » ou « chore: deps », assurez-vous que l’agent n’a pas inventé d’améliorations architecturales élaborées.

Si vous repérez des lacunes — par exemple des descriptions de PR manquantes — laissez-les marquées comme non documentées. Mettre en évidence les changements non documentés est un retour utile pour que l’équipe améliore les descriptions de PR.

Ajouter le rapport relu à Notion

Une fois le brouillon jugé exact, demandez à Leina d’écrire le rapport dans votre page Notion désignée :

Ajoute le rapport relu à [Notion page URL] sous le titre « [repository] — [reporting period] ».

Vérifie d’abord si ce titre existe déjà. S’il existe, montre-moi la section existante avant de modifier quoi que ce soit.

Préserve tout autre contenu existant sur la page.

Après l’écriture, relis la section ajoutée et renvoie le lien de la page Notion. Si le résultat de l’écriture est incertain, inspecte la page avant de réessayer ; si tu ne peux pas le vérifier, dis-le-moi.

Cela vous donne un point de relecture avant que le document ne change. C’est un flux de travail que vous demandez ; les permissions de connexion déterminent toujours les opérations que Leina peut effectuer. Vérifiez la section enregistrée avant de la partager avec l’équipe.

Une fois ce flux de travail bien rodé pour votre équipe, vous pouvez transformer cette invite en Skill réutilisable et réutiliser le format avec une nouvelle fenêtre de rapport. Les coéquipiers ont toujours besoin des permissions de connexion pertinentes.