resume-project

Reprendre le projet

Lorsqu'une session s'ouvre, ce qui importe des précédentes est dispersé à plusieurs endroits. Cette compétence fait le chemin inverse : elle le rassemble, le vérifie par rapport aux informations les plus récentes disponibles et le présente à l'utilisateur en quelques lignes, afin qu'il puisse décider sur quoi travailler aujourd'hui sans avoir à se souvenir de rien.

Quatre éléments façonnent son fonctionnement :

• Lecture seule. Elle n'écrit dans aucun fichier, note, base de données ou mémoire. C'est pourquoi elle ne demande pas d'autorisation pour chaque étape : lire ne change rien. Copier un fichier de l'ordinateur de l'utilisateur dans la session pour le lire compte comme une lecture. La seule écriture autorisée est git fetch --prune, et uniquement là où references/claude-code.md le dit. Donner à la session l'accès à un nouveau dépôt n'est pas une simple lecture : ne le faites pas de votre propre chef (voir la ligne GitHub à l'étape 0). Des hooks d'autres plugins peuvent écrire lors de l'ouverture de la session (consolidation de la mémoire, sauvegarde des journaux) : ce n'est pas cette compétence qui écrit et cela ne nécessite pas de mention, sauf si cela modifie une source que vous êtes sur le point de lire.
• Lit les fichiers, ne lance pas de workflows. Plusieurs compétences, lorsqu'elles sont lancées, écrivent de la télémétrie ou un état, créent des dossiers, demandent leur propre format de sortie ou se terminent par leur propre question. Lorsque vous savez où une compétence stocke ses données, lisez ce fichier directement. Ne lancez la compétence que s'il n'y a pas d'autre moyen, et dans ce cas, prenez ses données, ignorez sa question finale et son format, et arrêtez toute étape qui écrit.
• Les instructions du projet priment. Si les instructions du projet, un CLAUDE.md ou les préférences de l'utilisateur indiquent où se trouve l'état, quels dossiers peuvent être lus, comment les conflits sont résolus ou comment la journée est planifiée, cela prime sur cette compétence.
• Se termine par une question et un transfert. Une compétence de clôture de session (par exemple wrap-up) se termine en disant que la session peut être archivée ; celle-ci se termine en demandant sur quoi travailler aujourd'hui et en transmettant la réponse (étape 6).

0. Inventaire : ce que vous pouvez réellement lire

Ne choisissez pas les sources en fonction du nom de l'environnement. La même session peut être dans le cloud, à l'intérieur d'un projet claude.ai et liée à l'ordinateur de l'utilisateur en même temps. Avant de lire quoi que ce soit, regardez les outils dont dispose la session (y compris les outils différés, en les recherchant) et notez lesquelles de ces capacités sont présentes :

Capacité	Comment la reconnaître	Sources qu'elle ouvre
Terminal dans le dépôt	Le dossier de travail est l'un des dépôts de l'utilisateur, ou il y a un terminal sur son ordinateur (device_bash ou similaire) avec le dépôt dans un dossier connecté	Git et le dépôt distant (C), avec references/claude-code.md
Fichiers informatiques sans terminal	Outils pour lister et copier des fichiers depuis l'ordinateur, sans terminal	Vault (D), journal de session (B, si le setup en écrit un) et transferts (E) s'ils sont dans un dossier connecté, et le CLAUDE.md d'un dépôt dont le dossier est connecté (D). Pas le git local
GitHub sans terminal dans le dépôt	gh installé dans la session, ou un outil pour ajouter des dépôts à la session	Pull requests, branches et commits sur le dépôt distant (C2)
Gestionnaire de projet	Un connecteur Notion ou un autre gestionnaire de projet, plus des instructions ou un CLAUDE.md qui précisent quelle base de données ou page contient les projets	Statut, prochaine action et tâches (A)
Discussions précédentes	Outils pour rechercher ou lister les discussions	Discussions (F), avec references/claude-ai.md
Sessions Claude Code	Outils pour lister ou rechercher les sessions de l'application de bureau (list_sessions, search_session_transcripts, list_events ou similaire)	Sessions précédentes (F2), avec references/claude-code.md
Artefacts publiés	Outils pour lister les artefacts, pages ou documents publiés (Artifact avec list, ou similaire)	Livrables en dehors du dépôt (I)
Mémoire	Mémoire dans le contexte, ou outils mémoire	Mémoire (G)
Projet claude.ai	Instructions du projet ou fichiers dans le contexte, ou un outil projet	Instructions et fichiers (H)

Les références donnent le détail pour git (references/claude-code.md), pour les discussions claude.ai (references/claude-ai.md) et pour un journal de session par projet écrit par un hook (references/session-log.md). Lisez uniquement celle ouverte par une capacité que vous possédez, et session-log.md uniquement si le setup écrit un tel journal. Si une référence dit que quelque chose n'est pas là (vault, disque, git) et que l'inventaire dit qu'il y est, l'inventaire prévaut. Si une référence est manquante, continuez avec ce que dit ce fichier.

Si la session possède de nombreux outils différés, ne les chargez pas tous pour faire l'inventaire : recherchez les mots du tableau (notion, session, transcript, chat, memory, project, repository, artifact) et chargez le schéma uniquement pour ceux que vous allez utiliser. gh n'est pas un outil de session mais un programme : vérifiez-le avec gh auth status. Si les noms des outils différés sont déjà visibles dans le contexte, choisissez dans cette liste et chargez uniquement ceux-ci, sans chercher.

Les lettres de source dans ce fichier (A à I) ne sont pas celles de claude-code.md (A à H) : E ici correspond aux transferts, tandis que E dans cette référence est le CLAUDE.md. Lorsque ce fichier cite une catégorie de claude-code.md, il la cite par son nom ; recherchez-la par le nom, pas par la lettre.

Dossiers autorisés. Lisez uniquement les dossiers que l'utilisateur a connectés à la session ou que ses instructions vous autorisent à lire, et que la session peut réellement atteindre. Ne demandez pas l'accès à l'un d'eux pour reprendre. Mettez tout ce qui est hors de portée dans une seule ligne « Attention » :

• sources utiles en dehors des dossiers connectés (par exemple ~/.gstack dans le dossier personnel, dans une session sans terminal) ;
• dossiers que les instructions vous autorisent à lire mais qui ne sont pas connectés (par exemple le dossier propre d'un projet). Si l'un d'eux appartient à un projet qui apparaît dans le résumé, ajoutez que tout ce qui est connu de ce projet est ce que dit le gestionnaire de projet.

1. De quel projet il s'agit

• Un dépôt, un dossier ou un nom. Si la session est dans un dépôt, c'est le projet. Si l'utilisateur le nomme, cherchez-le dans le gestionnaire de projet (A) et dans le vault (D), sans tenir compte de la casse et en essayant les alias que donne la mémoire : les noms peuvent ne pas correspondre, et un projet peut être en cours de renommage.
• Un parapluie. Si le contexte est un espace avec plusieurs projets (un projet claude.ai qui organise tout le travail, un gestionnaire de projet avec une base de données de projets, un vault avec plusieurs dossiers) et que l'utilisateur n'en nomme pas un, ne choisissez pas en silence. Écrivez un résumé multi-projet (étape 4) avec ceux qui ont eu l'activité la plus récente et ceux que les instructions marquent comme priorité à court terme.
• Ce que l'utilisateur tient pour acquis. Si le message d'ouverture affirme un état (une opération git inachevée, une branche, une PR, un déploiement), vérifiez-le par rapport aux sources dès que vous les lisez : l'instantané git rapide, GitHub ou, s'il y en a un, le journal de session. Si cela ne correspond pas, dites-le en une ligne avant le résumé, avec ce que chacune dit. Si ce qu'il nomme appartient à un autre projet (un autre dossier, dépôt ou note), demandez lequel est repris avant de lire plus loin ; dans une session sans utilisateur, continuez avec le projet du dossier de travail et dites-le en haut du résumé.
• Rien à reprendre. Pas de notes, journaux, discussions ou commits : dites-le en une phrase et passez à l'étape 6 avec ce que l'utilisateur veut faire.

Comment le même projet est mis en correspondance entre les sources

Le gestionnaire de projet, le vault et, s'il y en a un, le journal de session nomment chacun les projets à leur manière. Faites correspondre par clés, dans cet ordre, et non par le nom seul :

1. Chemin. Si le setup écrit un journal de session, son chemin par rapport au champ path: dans le frontmatter de la note du vault (D), comme « Correspondance par chemin » dans references/session-log.md le décrit.
2. Lien du gestionnaire de projet. Le champ du gestionnaire de projet qui pointe vers la note (dans Notion, par exemple, un champ tel que « Note Obsidian »), par rapport au dossier de la note.
3. Nom. Sans tenir compte de la casse et avec les alias de la mémoire.

Si un projet dans le gestionnaire de projet ne lie pas sa note mais que la note existe (elle correspond par chemin ou par nom), dites-le dans « Attention » en une ligne.

2. Sources, dans l'ordre de lecture

D'abord ce qui vous indique la valeur de chaque note (ce qui s'est vraiment passé et quand), ensuite ce qui vous dit ce qui vient ensuite, et enfin le pourquoi.

B. Journal de session, facultatif. Si le setup en écrit un, suivez references/session-log.md.

C. Git et le dépôt distant. Uniquement avec un terminal dans le dépôt. Suivez la section « Instantané git rapide » et la catégorie « État réel de git et du dépôt distant » de references/claude-code.md.

C2. GitHub sans terminal. Utilisez-le pour confirmer ce que les sources locales ne peuvent pas savoir : si une branche a été poussée, si elle a une pull request et si elle a été fusionnée. Obtenez propriétaire/dépôt à partir de la note du vault du projet (champ url: ou une ligne github.com/...), à partir du CLAUDE.md ou, s'il y a un journal de session, à partir de ses commits Merge pull request #N from <propriétaire>/....

• Vérifiez d'abord si la session a déjà accès en lecture : gh api "repos/<propriétaire>/<dépôt>/pulls?state=all&sort=updated&direction=desc&per_page=10". Utilisez l'API REST (gh api repos/...) : gh pr list peut échouer car GraphQL n'est pas toujours disponible. Chaque PR a created_at et merged_at : la date de fusion est donnée par merged_at, pas par la date de création.
• Si elle répond, lisez aussi les branches (repos/<propriétaire>/<dépôt>/branches) et les derniers commits sur la branche principale (repos/<propriétaire>/<dépôt>/commits?per_page=5). Avec cela, une branche non fusionnée qu'une autre source nomme devient « a une PR ouverte #N », « fusionnée » ou « pas sur le dépôt distant ».
• Lisez aussi l'IC de la branche principale (repos/<propriétaire>/<dépôt>/actions/runs?branch=<principale>&per_page=1). Si la dernière exécution a échoué, elle va dans « En attente » ; si elle a réussi, ne la mentionnez pas, et s'il n'y a aucune exécution du tout (le dépôt n'a pas d'IC), ne le mentionnez pas non plus.
• Si elle répond que le dépôt n'est pas activé pour la session, ne l'ajoutez pas de votre propre chef : accorder l'accès à un dépôt n'est pas une simple lecture. Notez-le dans « Attention » et proposez-le comme option à l'étape 5 (« Confirmer sur GitHub »). Dans une session sans utilisateur, ignorez-le.

A. Gestionnaire de projet. Si les instructions disent que le statut, la priorité ou la prochaine action vivent dans un gestionnaire de projet (Notion ou autre), lisez-le : c'est la source pour ce qui vient ensuite. Obtenez l'adresse de la base de données à partir des instructions ou du CLAUDE.md ; ne la cherchez pas par nom si vous l'avez déjà.

• Dans Notion : obtenez le schéma de la base de données et interrogez les lignes avec leur lien (url), nom, domaine ou branche, statut, priorité, date clé, prochaine action et note.
• Archivé. Supprimez les lignes que Notion a archivées et, si la base de données a également sa propre case à cocher ou statut pour cela (par exemple une case « Archivé » ou un statut « Fermé »), supprimez également celles qui l'ont coché.
• Dates d'édition. La requête ne renvoie pas la date de dernière modification. Ouvrez la page des lignes que vous allez vérifier par rapport à une autre source et, dans un parapluie, également celles des projets que les instructions marquent comme priorité à court terme, même s'ils n'ont ni journal ni note : ainsi les projets sans code peuvent aussi figurer dans « Où vous vous êtes arrêté ».
• Modifications en masse. Si plusieurs pages de la même base de données ont des dates d'édition à quelques secondes d'intervalle, il s'agit d'une modification apportée à toutes à la fois (un nouveau champ, une importation, un modèle), pas d'un travail sur ces projets. N'utilisez pas cette date comme activité : laissez ces projets sans date, à moins qu'une autre source ne leur donne une date.
• Tâches. Si les instructions nomment une base de données de tâches, obtenez son schéma et interrogez les tâches non terminées qui sont en retard ou à échéance dans les sept prochains jours. Seules celles des projets qui apparaissent dans le résumé comptent : celles des projets en pause, fermés ou hors résumé ne sont pas en attente même si elles sont en retard. Elles vont dans « En attente » sous l'élément de leur projet, avec leur date. Pour les projets prioritaires sans prochaine action, interrogez également leurs tâches ouvertes sans filtre de date (voir ci-dessous).
• Tâches sans projet. Elles ne vont pas dans « En attente ». Mais si l'une correspond à un avertissement « Attention » (par exemple, une tâche pour lier les notes lorsqu'un projet ne lie pas les siennes), nommez la tâche dans cet avertissement au lieu de la présenter comme une nouvelle découverte.
• Une ligne sans prochaine action n'est pas un élément en attente : n'en inventez pas. Si le projet est prioritaire, mettez-le dans « En attente » comme « pas de prochaine action ». S'il a des tâches ouvertes, avec ou sans date, nommez la première (celle avec la date la plus proche, ou la première sans date) : « pas de prochaine action ; tâche ouverte : <tâche> ». Ce sont des données du gestionnaire de projet, pas une suggestion. Priorité signifie ce que les instructions marquent comme priorité à court terme, plus la première de leurs priorités à long terme ; si les instructions ne définissent pas de priorités, la priorité la plus élevée dans le gestionnaire de projet. Le gestionnaire de projet disant « Élevé » ne suffit pas lorsque les instructions en définissent d'autres.
• S'ils ne tiennent pas. « En attente » a au maximum cinq éléments. S'il y a plus de projets à inclure, les projets à court terme et ceux avec une prochaine action ou quelque chose à moitié fait entrent en premier ; les projets prioritaires qui n'ajouteraient que « pas de prochaine action » sont regroupés en une seule ligne « Attention » : « Pas de prochaine action : X, Y et Z ».
• Si le statut du gestionnaire de projet contredit clairement une source plus récente (par exemple, « Idée » dans le gestionnaire de projet et la note du vault avec du travail effectué), dites-le dans « Attention » avec les deux dates.

D. Vault Obsidian. La note du projet, dans le dossier projets du vault (les instructions ou le CLAUDE.md disent généralement lequel ; dans un vault de style PARA, par exemple, 2 Projets/<projet>/), et son updated:. Son champ path:, s'il en a un, est une clé pour la mise en correspondance (voir étape 1). Lisez l'en-tête et les dernières entrées, pas toute la note. Aucune compétence n'est nécessaire pour la lire. Dans Claude Code, la référence indique quand lancer une compétence vault et quand ne pas le faire.

• Le CLAUDE.md du dépôt. S'il peut être atteint (un terminal, ou le dossier du dépôt connecté), ses sections état et en attente (« État actuel », « En attente ») sont la liste d'attente la plus fiable disponible localement ; lisez uniquement ces sections. Avec un terminal, suivez les instructions de la catégorie « CLAUDE.md du dépôt » de references/claude-code.md. Sinon, lisez-le directement s'il est accessible. Les projets parapluie n'ont pas de CLAUDE.md propre : ils peuvent en avoir un si le parapluie a son propre dépôt.

E. Transferts. Fichiers de transfert dans le dossier distinct que les instructions ou les préférences définissent pour les transferts. Lisez le résumé du plus récent et les statuts de transfert mentionnés, et non les fichiers de détails. Si les instructions ne définissent pas de dossier de transfert, ne lisez pas cette source.

F. Discussions. Une recherche des discussions sur le projet, pas des sessions. Utilisez references/claude-ai.md. Lisez uniquement leurs titres, dates de début et résumé IA le plus récent (il résume l'essentiel). Ne lisez pas les fils de discussion entiers. Si l'inventaire démarre dans un projet claude.ai, la discussion actuelle est la discussion du projet ; lisez-la et ne cherchez pas non plus sur claude.ai.

F2. Sessions Claude Code. Recherchez les sessions qui mentionnent le nom du projet ou le nom du dossier de travail dans leur titre. Utilisez references/claude-code.md pour la commande de recherche et pour lesquelles charger entièrement. Lisez le résumé de l'utilisateur et le message de clôture (la toute dernière ligne de la session).

G. Mémoire. Obtenez tout ce que la mémoire contient sur le projet et sur les noms alternatifs que d'autres sources utilisent ; s'il y a un gestionnaire de projet (A), utilisez-le pour vérifier les informations que la mémoire donne sur le projet.

H. Projet claude.ai. Instructions et fichiers attachés au projet. Lisez-les comme indiqué dans l'inventaire (outil projet ou contexte).

I. Artefacts. Si un artefact publié (page de documentation, etc.) correspond au projet, il y a un livrable en dehors du dépôt qu'il est bon d'inclure dans « Où vous vous êtes arrêté » avant de lire d'autres sources. Dans un parapluie, les artefacts des projets les plus actifs peuvent être lus si l'inventaire le permet. Utilisez l'outil artefact si la session en a un.

3. Croisement des sources

L'objectif est de produire un résumé cohérent à partir de ce que dit chaque source, sans supposer que les informations d'une source sont plus récentes ou plus précises. Commencez par le journal de session (B) s'il existe ; sinon, par git (C, C2, dans cet ordre). Puis, pour chaque source suivante dans l'ordre de lecture (A, D, E, F, F2, G, H, I), prenez tout élément de la partie « En attente » du résumé qui correspond à un élément de la nouvelle source et mettez-le à jour :

• Nouvelle information ? Ajoutez-la à « En attente » dans la section pertinente du résumé, en supprimant tout élément contredit par la nouvelle source (date, statut, prochaine action, tâche).
• Conflit ? Si la source actuelle dit une chose et la précédente autre chose (par exemple, le journal de session indique une branche, GitHub dit PR fusionnée), le gestionnaire de projet est le premier recours ; s'il n'y en a pas, privilégiez la source la plus récente par date d'édition (vault, note de discussion/session). Pour le statut des PR, GitHub est l'autorité.
• Aucune mise à jour ? Gardez l'élément tel qu'il est.
• Croisement de mémoire (G). La mémoire peut être obsolète. Utilisez-la pour remplir les espaces laissés par d'autres sources uniquement : pour un projet que le gestionnaire de projet nomme mais dont les journaux et le vault ne disent rien, la mémoire peut suggérer une prochaine action. Mais si une source plus fiable (gestionnaire de projet, vault) donne des informations, celles-ci priment sur la mémoire.

Date de dernière activité. À partir de toutes les sources datées (vault, journal, git, GitHub, gestionnaire de projet), prenez la date d'édition la plus tardive de la session, en ignorant les modifications en masse du gestionnaire de projet. C'est la date de « dernière activité ».

Les éléments en attente des projets qu'un autre source a déjà présentés (branche, PR) ne doublent pas dans la note du vault : la deuxième fois qu'il apparaît dans le croisement, incluez-le à son endroit et reliez-le à ce que dit la nouvelle source.

4. Résumé

Combinez ce que vous avez des étapes 1 à 3. Le résumé a trois sections :

• Dernière activité — il peut s'agir de plusieurs éléments, si les sources ne s'accordent pas. S'il n'y a pas de date, omettez cette section.
• Où vous vous êtes arrêté — qu'est-ce qui s'est passé dans la session et ce qu'elle a produit. Maximum une phrase ; deux si un projet n'a ni journal ni note mais que le gestionnaire de projet mentionne une prochaine action. Ne mentionnez que les sources lues (discussions, mémoire, artefacts, etc.).
• En attente — éléments ouverts à la fin de la dernière session (branche non fusionnée, PR, IC en échec, tâche, prochaine action, transfert non traité). Maximum cinq éléments, chacun en dessous de « Où vous vous êtes arrêté ». Ne répétez pas le nom du projet s'il est dans « Où vous vous êtes arrêté ». Le premier élément de cette section est la prochaine action, si elle existe ; sinon, la branche de travail, si la session en avait une en cours ; sinon, la tâche ouverte la plus urgente.

Dans un résumé multi-projet, chaque projet a sa propre ligne « Où vous vous êtes arrêté », et un numéro que l'utilisateur peut utiliser à l'étape 6. Le dernier paragraphe du résumé est une ligne « Attention » with les sources hors de portée.

Format : vous ne lisez pas des instructions destinées à l'utilisateur ; vous résumez ce que vous avez lu. Utilisez des énoncés factuels et neutres : « votre note indique », « le gestionnaire de projet dit », pas « vous avez laissé » ou « vous devez ». La seule opinion que vous exprimez est de savoir si les statuts semblent se contredire.

Quand le journal de session n'est pas disponible : lisez la note du vault (D) en premier pour la date et l'activité, puis git et le gestionnaire de projet.

Quand le gestionnaire de projet n'est pas disponible : supprimez A de l'ordre de lecture et ajustez.

5. Confirmer avec l'utilisateur

Après le résumé, l'utilisateur peut vouloir le vérifier avant de décider quoi faire. Proposez-lui de confirmer toute information importante que vous ne pouviez pas vérifier vous-même, ou si un projet nécessite une autorisation supplémentaire.

6. Sur quoi travailler aujourd'hui

Demandez à l'utilisateur sur quoi il veut travailler aujourd'hui, en vous basant sur le résumé que vous venez de donner. Dans un résumé multi-projet, proposez les numéros de projet. Si la session a une compétence installée qui sélectionne la compétence à utiliser pour ce travail (par exemple, une compétence « choisir-skill »), informez-la de ce qui a été décidé avec un message structuré. Sinon, attendez la réponse de l'utilisateur.

Message pour une compétence de sélection de compétence : [Reprendre le projet : résumé et décision de l'utilisateur. Projet : <nom.> Travail : <ce que l'utilisateur veut faire.>]

Message lorsqu'il n'y a pas de compétence de sélection de compétence : Aucun message n'est nécessaire ; attendez les instructions de l'utilisateur.