Comment transformer une tâche IA fonctionnelle en une Skill réutilisable
Transformez un prompt ponctuel en un SKILL.md réutilisable. Séparez les entrées dynamiques des règles standard, testez les cas limites et partagez le flux de travail avec votre équipe.
Une fois que vous disposez d’un rapport hebdomadaire GitHub utilisable, vous voudrez probablement que le suivant suive les mêmes règles : filtrer par date de fusion, conserver les liens sources et laisser visible le contexte manquant. Enregistrer ces règles les rend plus faciles à réutiliser et à vérifier que de copier une longue conversation chaque semaine.
Dans Leina, vous pouvez empaqueter des flux de travail éprouvés dans une Skill — un fichier SKILL.md structuré suivant la spécification ouverte Agent Skills. Au lieu de réexpliquer les standards de reporting de votre équipe chaque lundi, fournissez le dépôt actuel, les dates, le fuseau horaire et toute destination nécessaire à la tâche.
Utilisez un rapport que vous avez déjà vérifié comme point de départ. Le tutoriel GitHub-vers-Notion montre comment en préparer et en vérifier un.
Séparez les entrées changeantes des règles standard
Une Skill fiable sépare les entrées pour cette exécution des règles à réutiliser.
| Entrées pour cette exécution | Règles enregistrées dans SKILL.md |
|---|---|
| Dépôt ou liste de dépôts cible | Règles de filtrage exactes (horodatage de fusion vs. date de fermeture) |
| Fenêtre de reporting et fuseau horaire | Exigence de citation des sources (inclure le lien de la PR et l’auteur) |
| URL de la page de destination Notion, pour une écriture | Règles de preuve (signaler le contexte manquant comme non documenté) |
| Public visé / niveau de détail | Instructions d’écriture (respecter la portée demandée et vérifier le contenu existant) |
Les identifiants et jetons d’accès ne doivent jamais figurer dans un fichier Skill. Leina gère l’accès via des Connections autorisées ; une Skill définit simplement comment l’agent doit utiliser les outils disponibles dans votre environnement.
Structurez votre fichier SKILL.md
Un fichier SKILL.md comporte un frontmatter YAML et des instructions Markdown. Ce modèle de départ est un exemple à adapter et à tester avec vos outils disponibles ; il n’a pas été exécuté sur vos comptes.
---
name: weekly-pr-report
description: "Préparer un rapport hebdomadaire de pull requests GitHub lié aux sources pour un dépôt et une fenêtre temporelle spécifiés, avec une écriture facultative autorisée dans Notion. À utiliser pour les rapports d'état d'ingénierie, et non pour la revue de code ou l'évaluation de la productivité individuelle."
---
# Rapport hebdomadaire de PR
Exemples d'instructions à adapter et à évaluer avec les outils disponibles dans l'environnement de l'agent. Ce fichier n'installe pas de connecteurs et n'accorde pas d'accès au compte.
## Entrées
Déterminez la liste des dépôts, la fenêtre de rapport avec le fuseau horaire et les lecteurs visés à partir de la demande. Demandez les informations manquantes qui modifieraient le rapport. Pour une écriture dans Notion, déterminez également la page exacte, le titre du rapport et si l'utilisateur souhaite un ajout ou un remplacement.
Utilisez les lectures GitHub autorisées exposées par l'environnement actuel. Si ces opérations ne sont pas disponibles, signalez la capacité manquante. N'inventez jamais d'ID d'action de connecteur ni d'enregistrements récupérés.
## Sélectionner et résumer
- Incluez les PR fusionnées dont les horodatages de fusion tombent dans la fenêtre demandée. Distinguez les enregistrements fermés non fusionnés des travaux fusionnés.
- Incluez un instantané distinct des PR actuellement ouvertes uniquement s'il est demandé, étiqueté avec l'heure de récupération. Ne présentez pas l'état actuel comme un état historique.
- Récupérez toutes les pages de résultats dans le périmètre lorsque cela est pris en charge. Divulguez les enregistrements indisponibles, les résultats tronqués ou les requêtes échouées ; une requête incomplète n'est pas une requête sans résultat.
- Conservez l'URL de la PR, son numéro, son titre, son auteur, son état et l'horodatage pertinent. Résumez à partir de la description de la PR et des modifications disponibles pour l'outil.
- Décrivez l'impact, le déploiement, les blocages et les responsables des prochaines actions uniquement lorsque les preuves le justifient. Ne considérez pas l'auteur comme le responsable des prochaines actions par défaut.
- Retournez le périmètre sélectionné, les sections du rapport, les liens sources et les questions non résolues. Adaptez le niveau de détail aux lecteurs visés.
## Écriture facultative dans Notion
Une demande de brouillon renvoie un brouillon. N'écrivez que lorsque l'utilisateur a autorisé la destination et l'opération concrètes ; préservez l'autorisation existante plutôt que d'exiger une confirmation répétée.
Vérifiez la présence du titre du rapport avant d'ajouter. Si un rapport existe déjà et que le remplacement n'est pas autorisé, retournez son emplacement et demandez comment procéder. Préservez le contenu non lié.
Après une écriture, relisez la section si cela est pris en charge et retournez son emplacement. Si le résultat de l'écriture est incertain, inspectez la cible avant de réessayer. Si la vérification n'est pas disponible, signalez cette limitation plutôt que d'affirmer que l'écriture a été confirmée.Téléchargez le même SKILL.md weekly-pr-report pour le personnaliser selon les champs de votre équipe.
Trois choix dans le fichier méritent d’être conservés :
- Une description ciblée : Elle indique quand la Skill est utile. La découverte et l’invocation dépendent de l’environnement de l’agent.
- Des règles de sélection explicites : L’heure de fusion détermine quelles PR appartiennent à la section du travail terminé.
- Une portée d’écriture définie : Les instructions demandent à l’agent de vérifier le contenu existant et de respecter l’opération demandée. Elles guident le comportement ; les permissions appliquent l’accès.
Testez les cas limites avant de déployer
Avant de partager la Skill avec votre équipe, exécutez-la sur une autre semaine ou un autre dépôt et comparez sa sortie avec les enregistrements sources. Essayez ces cas :
| Scénario de test | Comportement attendu de l’agent |
|---|---|
| Une semaine calme avec 0 PR fusionnée | Signale zéro après une requête complète ; n’invente pas de faits marquants et ne remonte pas d’anciennes PR. |
| Une PR fusionnée 1 minute en dehors de la fenêtre | Exclue de la section des fusions. |
| Une PR fermée, non fusionnée | Exclue du travail fusionné. |
| Une PR sans description (par ex. « bump version ») | Résume le changement brut et signale explicitement l’impact comme non documenté. |
| Le titre cible existe déjà dans Notion | Vérifie la section existante et suit l’opération autorisée ; demande comment procéder si le remplacement n’était pas autorisé. |
| Dépôt ou page inaccessible | Signale clairement la permission manquante au lieu de prétendre que le dépôt est vide. |
Si l’agent répète une ancienne date lors de la deuxième exécution, assurez-vous que la plage de dates n’est pas codée en dur dans les instructions. S’il hallucine un impact client, resserrez la règle de résumé.
Partagez et automatisez avec votre équipe
Après avoir vérifié une deuxième exécution, suivez les instructions d’installation de votre package Skill ou le mécanisme d’import pris en charge par votre environnement d’agent. Télécharger le fichier seul ne l’installe pas. Consultez Utiliser les Skills avec Leina pour le flux de travail par répertoire.
- Utilisation interactive : Les coéquipiers peuvent l’invoquer naturellement dans le chat : « @Leina exécute weekly-pr-report pour backend/api couvrant du 28 septembre au 4 octobre 2026, en America/Los_Angeles. Renvoie un brouillon ici. »
- Permissions : Chaque coéquipier a besoin de la permission d’utiliser la connexion GitHub, plus la connexion Notion lors de l’enregistrement d’un rapport. Vérifiez ces comptes dans Connections.
- Exécutions planifiées : Demandez une tâche récurrente avec son fuseau horaire, sa fenêtre de reporting et son lieu de livraison. Vérifiez la planification mise en place par Leina et examinez sa première sortie planifiée. Enregistrer la Skill ne crée pas de planification.
Partagez le fichier vérifié avec ses Apps requises, un exemple de rapport et une date de version ou de révision. Lorsque l’équipe modifie les règles de reporting, mettez à jour ce fichier et vérifiez une autre exécution.