alex20-create/wrap-up

Clôture

L'utilisateur est sur le point d'archiver cette conversation. Tout ce qui ne vit que dans la conversation est sur le point d'être perdu : les décisions prises, ce qui a changé sur le disque, ce que la prochaine session doit reprendre. Plusieurs compétences installées sauvegardent chacune une partie de ces informations. Le travail de cette compétence est de les trouver, de les exécuter dans le bon ordre et de s'arrêter après une seule confirmation.

L'ensemble des compétences n'est pas fixe : des plugins apparaissent et disparaissent, l'utilisateur écrit de nouvelles compétences. Ne codez jamais les noms en dur ; découvrez-les à chaque fois à partir de ce qui est installé, puis faites correspondre les catégories dans references/close-out-catalogue.md. Le catalogue indique ce qu'est chaque catégorie, dans quel ordre et à quel coût ; ce fichier indique comment chacune s'exécute dans chaque environnement. Si les deux semblent en désaccord, suivez le catalogue pour le « quoi » et l'ordre, ce fichier pour le « comment », et mentionnez le désaccord dans le rapport afin que l'utilisateur puisse corriger le catalogue.

0. Sachez où vous êtes et quel âge a la session

La majeure partie de ce qui suit change en fonction de l'environnement et de l'âge de la session, alors établissez d'abord les deux et dites-les en une ligne en haut du plan. Trois environnements :

• Claude Code sur la machine de l'utilisateur. Un shell sur cette machine, des compétences dans ~/.claude/skills, des hooks qui s'exécutent (y compris, si l'un d'eux est configuré, un hook SessionEnd qui enregistre chaque session ; la carte locale ou settings.json indique s'il y en a un), des dépôts et un coffre sur le disque. Tout ce qui suit s'applique tel quel.
• claude.ai ou une session cloud avec un shell de périphérique. La conversation s'exécute dans un conteneur Linux, mais un outil shell pour l'ordinateur de l'utilisateur est répertorié, donc les commandes s'exécutent là-bas, dans les dossiers que l'utilisateur a connectés. Le coffre et tout script stocké dans un dossier connecté sont accessibles. Les fichiers de cette compétence (le catalogue, scripts/) se trouvent dans le conteneur, pas sur cette machine. Les hooks ne s'exécutent pas. La mémoire passe par les outils mémoire, et un passage en arrière-plan enregistre les faits durables après chaque tour.
• claude.ai ou une session cloud sans ce shell. Les fichiers sur l'ordinateur de l'utilisateur ne sont accessibles que via les outils qui transfèrent un fichier dans le conteneur et le renvoient, et uniquement lorsque l'application de bureau est liée. Sinon, rien sur leur disque n'est accessible. Hooks et mémoire comme ci-dessus.

Signaux : la plateforme et le répertoire de travail, les outils répertoriés (shell de périphérique, outils de fichiers de périphérique, outils mémoire), ce que l'invite système dit à propos de la mémoire et d'un projet. Si vous ne pouvez pas le dire, dites-le et demandez, car une mauvaise hypothèse écrit au mauvais endroit.

Puis l'âge. Une clôture est généralement demandée à la fin du travail, mais une conversation peut rester ouverte pendant des jours et être fermée plus tard, après que d'autres sessions ont travaillé sur les mêmes fichiers, notes et compétences. La session est obsolète lorsque quelque chose qu'elle a touché a changé après son dernier travail réel : comparez la date de ce travail (les horodatages de la conversation ou les notes datées) avec les heures de modification des fichiers et des entrées du magasin qu'elle a touchées, un commit ultérieur, une entrée du magasin datée ultérieurement, ou une compétence qu'elle a utilisée et que la liste n'affiche plus ou ne montre plus. Un seul changement suffit. L'âge seul est une raison de regarder, pas un verdict : une conversation d'une semaine sur laquelle personne n'a construit n'est pas obsolète. Dites-le dans la ligne du haut avec l'écart (« dernière activité le 4 novembre ; les fichiers qu'elle a touchés ont changé depuis »).

Dans une session obsolète, le disque et les magasins sont plus récents que la conversation, donc ils l'emportent :

• Avant de planifier une écriture, lisez la version actuelle de chaque fichier et entrée du magasin que l'étape toucherait, et planifiez en fonction de ce qui est là maintenant, pas de ce dont la conversation se souvient.
• Une décision prise par la session qu'une session ultérieure a déjà enregistrée est terminée : pointez-la, ne l'écrivez pas à nouveau. Une session ultérieure a modifié ou annulée n'est pas à rétablir par cette clôture : nommez-la comme remplacée et abandonnez-la. Lorsque l'enregistrement ultérieur ne couvre qu'une partie de la décision, ou qu'il n'est pas clair dans quelle mesure il la couvre, abandonnez uniquement la partie qu'il couvre clairement et nommez le reste comme potentiellement remplacé ; la direction dépend d'une seule question.
• Les chemins, noms et compétences que la session a utilisés peuvent avoir été déplacés ou renommés. Résolvez chacun à nouveau avant de l'utiliser. Une nouvelle forme ne compte que lorsque quelque chose écrit depuis l'indique (mémoire, une note, un commit, la propre description d'une compétence indiquant comment elle s'appelait auparavant) ; utilisez cette forme et dites-le. Lorsque rien ne l'indique, nommez l'ancienne comme ne se résolvant plus au lieu de deviner, et ne l'écrivez pas dans un magasin comme si elle était actuelle.
• Ce qui reste à proposer est ce que la session a décidé et que rien depuis n'a enregistré, modifié ou contredit. Cela peut être très peu ; une clôture obsolète qui écrit une ligne, ou rien, est une clôture correcte.

La même conversation peut déjà contenir une clôture antérieure, exécutée avant que l'utilisateur ne continue à travailler. Alors cette clôture s'appuie sur celle-ci au lieu de recommencer : prenez son plan et marquez chaque étape comme terminée (son rapport le dit et le disque est d'accord), remplacée, ou toujours en attente, et vérifiez uniquement ce qui s'est passé après. Un plan que la clôture antérieure a proposé et auquel l'utilisateur n'a jamais répondu n'a pas été approuvé : reportez ses étapes en attente dans ce plan, vérifiées à nouveau par rapport au disque et aux règles ci-dessus, au lieu de les exécuter ou de les abandonner silencieusement, et dites dans la ligne du haut qu'une clôture antérieure existe.

1. Découvrir

Avant de découvrir quoi que ce soit, vérifiez les instructions permanentes de l'environnement (dans Claude Code, les fichiers CLAUDE.md et la mémoire automatique, qui compte comme permanente ici ; dans claude.ai, les instructions du projet, les préférences et la mémoire de l'utilisateur, et une section « Carte locale pour cette installation » qu'une copie packagée de ce SKILL.md peut contenir) pour une carte locale de cette routine : une courte section nommant quelle compétence installée couvre chaque catégorie, les magasins, ce qui est retiré, les coûts mesurés. Lorsqu'une existe, elle remplace la découverte ; vérifiez que chaque compétence qu'elle nomme est toujours installée (et une commande nommée ou un chemin avec un regard bon marché en lecture seule là où c'est pratique), et traitez ce qu'elle retire comme réglé. Une carte partielle (magasins ou retraits nommés, mais pas de compétence par catégorie) informe la découverte au lieu de la remplacer : respectez ce qu'elle nomme, découvrez le reste, et l'offre de la section 5 devient la complétion de cette section, pas l'ajout d'une seconde. Lorsqu'aucune n'existe, découvrez comme suit et offrez à la fin d'en écrire une (section 5). Dans Claude Code, lisez les fichiers CLAUDE.md depuis le disque, pas seulement depuis le contexte : une copie injectée peut précéder une modification, et une copie obsolète vous envoie en découverte complète et une offre d'écrire une seconde carte par-dessus une qui existe déjà.

La liste des candidats est le listing des available skills déjà dans le contexte (nom + description). Il couvre les compétences locales, les compétences de plugin et gstack de la même manière ; il n'y a pas de meilleure source. Deux bizarreries du listing : une compétence affichée à la fois avec et sans préfixe de plugin, même description, est une seule compétence, alors appelez-la par le nom nu dans le plan, mais invoquez-la avec le nom exact que le listing montre ; et le listing peut s'allonger en cours d'exécution lorsqu'une commande touche un dossier contenant ses propres compétences, dont les arrivées tardives ne modifient le plan que si elles correspondent à une catégorie.

Lisez references/close-out-catalogue.md. Pour chaque catégorie qu'il définit, choisissez la ou les compétences installées dont la description correspond à son objectif. Les membres connus sont des indices, pas la réponse : une compétence installée non répertoriée y est admissible si sa description correspond, une compétence répertoriée mais plus installée est ignorée. Surveillez les quasi-correspondances que le catalogue signale. Lorsque le listing montre une compétence par son nom uniquement (les deux environnements le font pour certaines), faites correspondre le nom et les mots « Reconnaître par » du catalogue, et marquez-la « (aucune description) » dans le plan afin que l'utilisateur sache que la correspondance est plus faible.

Une catégorie sans compétence installée va dans le plan comme « ignorer, non installée » ; n'improvisez pas de remplacement, sauf si l'environnement a son propre mécanisme pour ce travail (section 2). Certaines catégories ne sont pas des compétences (dans Claude Code, la mémoire automatique est écrite avec l'outil Write et une actualisation du graphe est une commande) ; ce sont des étapes dans le même plan, uniquement là où l'environnement les a.

Ensuite, vérifiez ce qui vaut vraiment la peine d'être fait dans cette session :

• Graphes. Dans Claude Code sur la machine, exécutez python scripts/find_graphs.py <racine-du-espace-de-travail> (chemin relatif au répertoire de cette compétence ; n'importe quel Python fonctionne). La racine de l'espace de travail est le dossier de travail de la session, ou le dossier plus large que les instructions du projet décrivent comme contenant chaque dépôt, lorsqu'elles le font. Le script liste chaque graphify-out/ dont le dossier de projet se trouve à au plus cinq niveaux en dessous, et si les fichiers ont changé depuis son manifeste : une ligne par graphe, CURRENT, STALE avec les comptes de modifiés et supprimés, ou UNKNOWN (pas de manifeste, ou graphify non importable), ou une seule ligne disant qu'aucun n'a été trouvé. Les comptes ne disent pas si les changements sont des notes, ~85k chacune à ré-extraire, ou du code, qui n'a pas besoin de LLM ; dites lequel à partir de ce que la session a touché. CURRENT n'est pas une étape, même si vous vous souvenez d'avoir modifié un fichier graphe : le manifeste sait si le graphe a été reconstruit après cela. Sans Python sur la machine, les graphes ne sont pas vérifiés ; dites-le. Ailleurs, le script ne peut pas voir l'espace de travail (il s'exécute dans le conteneur, les graphes sont sur le disque de l'utilisateur) : signalez chaque graphe comme non vérifié, ce qui n'est pas « rien à mettre à jour ».
• La session. Décisions, corrections, nouveaux faits sur l'utilisateur ou le projet, fichiers créés ou déplacés ? Cela décide si les étapes de mémoire et d'apprentissages ont quelque chose à écrire. Une session qui était purement de la lecture peut n'avoir besoin de rien d'autre qu'une sauvegarde de contexte.
• Git. git status dans chaque dépôt que la session a touché. Le travail non validé n'est pas à cette compétence de valider ; il va dans la ligne « reste avec l'utilisateur » du plan. Lorsque l'histoire de la session et git ne sont pas d'accord (fichiers modifiés dans la session, arbre propre), nommez la divergence au lieu de la réconcilier silencieusement.
• Écritures revendiquées. Listez ce que la session a dit avoir écrit, créé, installé ou modifié (fichiers, notes, commits, paramètres, packages installés), et vérifiez chacun avec un regard en lecture seule : il existe, et son contenu est celui que la session a écrit (une ligne distinctive ou la taille, pas l'existence seule, car un écrasement raté laisse l'ancien fichier en place). Un outil qui a signalé un succès n'est pas une preuve. Lorsque le contenu diffère, l'heure de modification décide : modifié après le dernier travail de la session signifie qu'une session ultérieure l'a modifié (section 0, obsolète) ; non modifié après signifie que l'écriture n'a jamais abouti. Un fichier qui devrait exister et n'existe pas n'a pas non plus abouti, sauf si un commit ou une note ultérieur en enregistre la suppression. Une écriture qui n'a jamais abouti, ou un travail que la session a laissé à moitié fait (installé à certains endroits et pas à d'autres, une étape qu'elle a promise et n'a pas exécutée), va dans la ligne « laissé cassé » du plan (section 3). Une session qui n'a revendiqué aucune écriture ignore cette étape.
• Travail en cours qu'une autre compétence étale sur plusieurs sessions (catalogue, « Travail en cours »). Pas une étape en soi : il va dans la note de passation et la sauvegarde de contexte.
• Où l'état vit déjà. Les instructions du projet peuvent nommer les magasins que l'utilisateur traite comme la source : un coffre, une base de données de projet, un champ qui contient la prochaine action. Lisez les instructions avant de planifier une écriture (les magasins eux-mêmes sont lus par les étapes qui les écrivent) ; elles décident comment les catégories 3 et 5 s'exécutent. Lorsque deux magasins nommés pourraient contenir le même fait (une note de décisions et une note de projet, par exemple), le plan nomme celui que l'écriture cible ; si les instructions ne le règlent pas, réglez-le dans la question unique, jamais silencieusement.

2. Ce qui change avec l'environnement

Dans Claude Code, exécutez chaque catégorie comme le catalogue le décrit ; de ce qui suit, seules les règles qui le disent s'appliquent également là. Dans les deux autres cas de la section 0, ajustez comme suit.

1 Mémoire : vérifier, ne pas écrire. Le passage en arrière-plan enregistre déjà les faits durables après chaque tour. Lisez le(s) fichier(s) mémoire qu'il a probablement utilisé(s) (le listing montre les chemins) et dites dans le plan si les décisions de cette session y sont. Le passage s'exécute après chaque tour, donc ce qui a été décidé dans le tour de clôture lui-même n'y est pas encore et sera enregistré après ; c'est normal, pas un écart. La plateforme n'autorise une écriture mémoire que sur demande explicite de l'utilisateur, donc si quelque chose qu'il a dit manque, nommez-le dans le plan et laissez-le dire « sauvegarde-le » ; cette phrase est la demande. À l'intérieur d'un projet, les écritures vont dans le sous-arbre propre du projet, sous la forme que les instructions mémoire exigent.

1b Note de passation, 2 Apprentissages : ignorer si non installé. Il n'y a pas de remplacement ; un document de projet, une nouvelle note ou un résumé de conversation n'en devient pas un (voir la règle de l'unique emplacement).

3 Synchronisation du coffre : dépend de l'accessibilité. Avec un shell de périphérique et le dossier du coffre connecté, exécutez la compétence de synchronisation si elle est installée ; si elle a besoin de quelque chose que cet environnement n'a pas, elle le dira, et ensuite faites la synchronisation à la main. Sans shell, et uniquement lorsque l'ordinateur est lié, faites-la à la main avec les outils de fichiers. Dans les deux cas, lisez d'abord la note des conventions propres au coffre (transférez-la quand il n'y a pas de shell), et mettez chaque changement proposé dans le plan comme ce qui reste, ce qui change et ce qui disparaît, afin que la confirmation unique couvre les écritures. Le journal de session qu'un hook écrit n'existe pas ici ; dites-le.

4 Graphe : non vérifié, comme le dit la section 1. Pas « rien à faire ».

5 Sauvegarde de contexte : écrire là où le projet le dit. Cela vaut aussi dans Claude Code : un emplacement nommé par les instructions du projet l'emporte sur une compétence générique d'instantané, et sans cela, la compétence d'instantané installée est l'étape. Si les instructions du projet nomment un emplacement où « là où je me suis arrêté » vit (un champ dans une base de données de projet, par exemple), cet emplacement est la sauvegarde de contexte. Si une compétence installée possède cet emplacement (une routine de clôture quotidienne), cette compétence est l'étape ; si elle a déjà été exécutée dans cette session, ignorez-la. Sinon, écrivez-y vous-même. Le plan porte le texte exact proposé pour cet emplacement, de sorte que la réponse unique le couvre ; cette règle s'applique lorsque vous écrivez l'emplacement vous-même, tandis qu'une compétence qui possède l'écriture compose son propre contenu, dans Claude Code ou ailleurs. Si aucune entrée de projet ne couvre sur quoi la session a travaillé, dites-le et proposez

…

[Le contenu complet a été tronqué pour la traduction]