Skill Handoff : reprendre le travail d’un agent sans recommencer la configuration

Un nouvel agent peut lire un résumé et répéter malgré tout le travail de la veille. Il manque souvent ce qui a été vérifié, ce qui reste incertain et la première action à effectuer. Ce guide aide à rendre une transmission utile vers une autre session, un autre espace ou une autre personne.

Publié le Analyse originale, sources citées

Ce que ce skill produit réellement

Les instructions handoff de Matt Pocock à la révision liée produisent un document de continuation dans le répertoire temporaire du système. Elles demandent des références aux livrables, des skills suggérés, le retrait des données sensibles et un contenu adapté à la prochaine session. L’installation ne transfère pas automatiquement les fichiers et ne lance pas un autre agent.

Les exemples ci-dessous sont des illustrations éditoriales SkillSignal, pas les journaux d’un test d’exécution indépendant. Installation et compatibilité figurent sur la fiche ; ce guide examine l’utilité du document produit.

Compactage ou transmission : le travail doit-il changer de contexte ?

Le guide de l’auteur recommande le compactage pour continuer normalement dans le même environnement et un fichier de transmission pour passer à un autre agent, répertoire, collègue ou tâche secondaire. Ce conseil concerne ce skill ; il ne promet pas des commandes identiques dans tous les agents.

Par exemple, un designer peut transmettre un défaut précis à un second espace en préservant la discussion principale. Précisez le responsable de chaque fichier : si deux sessions modifient le même composant, un résumé seul n’empêchera pas les conflits.

  • Même tâche et contexte accessible : continuer ou utiliser le compactage pris en charge par l’agent.
  • Autre espace ou destinataire : préparer une transmission et rendre les fichiers nécessaires accessibles.
  • Travail parallèle : définir la propriété des fichiers et le résultat à restituer avant toute modification partagée.

Exemple commenté : une correction de formulaire mobile inachevée

Imaginons un formulaire de paiement fictif dont le champ courriel est coupé à 390 pixels CSS. La première session modifie une règle de largeur et vérifie cette largeur. Elle n’a contrôlé ni 768 pixels, ni le focus clavier, ni la soumission. Écrire « mobile corrigé ; terminer » cacherait le travail restant.

Un document utile dirait : « Objectif : supprimer la coupure sans changer le paiement. Modification : règle de largeur du champ courriel dans le composant ; examiner le diff courant. Preuve : aucune coupure à 390 pixels CSS dans la capture conservée. Non vérifié : 768 pixels, navigation clavier et soumission. Suite : reproduire à 768 pixels, puis vérifier focus et soumission avec des données de test. Ne pas publier avant réussite. » Ces résultats sont fictifs et illustrent le format, pas une application testée.

L’agent destinataire doit examiner le fichier et le diff réels avant de se fier au document. Si la règle a changé depuis la capture, celle-ci ne prouve plus que la version actuelle fonctionne. Consignez l’écart et revérifiez l’état concerné.

Six champs à vérifier avant envoi

Utilisez cette liste pour examiner le document, pas comme un format obligatoire prétendument imposé par le skill. Remplacez les statuts vagues par des preuves consultables. « Tests réussis » reste incomplet sans préciser contrôles, révision et couverture.

  • Résultat : effet visible pour l’utilisateur et limites de la tâche.
  • État : branche ou révision actuelle, fichiers modifiés et travail non validé à préserver.
  • Preuves : contrôles réellement effectués, résultats et références accessibles.
  • Inconnues : hypothèses, cas non testés et blocage exact éventuel.
  • Action suivante : étape concrète, critère d’acceptation et skill nécessaire avec son rôle.
  • Autorité : opérations déjà autorisées et décisions encore nécessaires ; le résumé n’implique pas l’accès.

Où est le fichier et pourquoi l’autre agent ne peut-il pas le lire ?

Demandez le chemin absolu et rouvrez le document enregistré. Un chemin temporaire sur une autre machine n’est pas une pièce jointe partageable. Si le destinataire ne peut le lire, transférez le document examiné et ses livrables nécessaires vers un emplacement partagé approprié ; confirmez l’accès avant de fermer la session d’origine.

Un ticket communautaire rapporte une difficulté à trouver le répertoire temporaire sous Windows. C’est un témoignage individuel, pas une mesure de taux d’échec. Vérifiez chemin, contenu lisible et accès à destination dans votre environnement. Ne supposez pas qu’un fichier vide ou inaccessible contient un document terminé.

Pour une reprise ultérieure, conservez une copie durable appropriée. Avant partage, examinez identifiants, liens privés, exemples clients et références de fichiers. Le document peut exclure les secrets alors qu’un journal lié en contient encore.

Une bonne reprise commence par une petite vérification

Demandez à l’agent destinataire d’identifier le résultat restant, d’ouvrir les livrables cités et d’énoncer le premier contrôle non résolu. S’il recommence une enquête terminée, il manque probablement un résultat ou une référence utilisable. S’il annonce immédiatement la fin, demandez quelle preuve actuelle la justifie.

Évaluez la transmission par la capacité de la session suivante à atteindre la prochaine étape avec les bonnes contraintes. Un texte court ne prouve ni gain de temps ni exactitude. À la fin, transférez les décisions durables dans la documentation normale du projet au lieu de traiter un document temporaire comme vérité permanente.

Reprenez une tâche inachevée à partir d’un document vérifié

Partez de la fiche Handoff existante, puis vérifiez fichier et références avant de demander à un autre agent de continuer.