Retro

retro

Overview

À la fin d'une session de travail, repérer les points de friction (ce qui a coincé entre l'utilisateur et l'agent), remonter chacun à sa cause racine, et proposer des éditions concrètes pour que les sessions suivantes se passent mieux — capitalisées dans le repo, donc versionnées et synchronisées sur toutes les machines.

Principe central : une friction récurrente = une règle manquante. La rétro convertit le feedback implicite de la session en texte persisté et actionnable, exactement comme un post-mortem.

Cette skill analyse la conversation en cours (celle qu'elle a déjà dans son contexte). Elle ne parse pas de fichier de transcript externe.

When to Use

• L'utilisateur dit : « rétro », « bilan de session », « qu'est-ce qui a coincé ? », « retro », ou invoque /retro
• En fin de session, ou après une tâche qui a demandé beaucoup d'allers-retours
• Quand l'utilisateur veut transformer une frustration ponctuelle en amélioration durable

Ne pas utiliser quand :

• La session a été triviale (une seule question, aucune correction) → répondre qu'il n'y a rien de notable à capitaliser
• Le contexte a été lourdement compacté → le signaler : la rétro ne porte que sur ce qui reste en contexte (voir Limites)

Limites

• La rétro ne voit que la conversation présente en contexte. Si une compaction a eu lieu, les frictions du début peuvent être perdues — le dire explicitement et ne pas inventer.
• Elle ne mesure pas (pas de métriques OpenTelemetry ici) : c'est une analyse qualitative des signaux de friction.

Signaux de friction à repérer

Balayer la conversation et relever, avec pour chacun le tour concerné :

Workflow

1. Analyser

Relire la conversation et lister les frictions repérées. Pour chacune : ce qui s'est passé, à quel moment, et l'impact (temps perdu, retouche, frustration).

2. Remonter à la cause racine

Pour chaque friction, répondre à : qu'est-ce qui, présent dès le départ, l'aurait évitée ? Les causes typiques :

• une règle/convention manquante que l'agent aurait dû connaître → cible rules/ ou CLAUDE.md
• un savoir-faire procédural absent (suite d'étapes réutilisable) → cible skills/
• une instruction ambiguë côté utilisateur → pas une édition de config, mais une note sur comment mieux formuler
• un manque de contexte ponctuel non récurrent → ne rien capitaliser (l'over-capitalisation pollue)

Ne pas transformer chaque friction en règle. Une friction ponctuelle ne mérite pas une règle. Privilégier ce qui a des chances de se reproduire.

3. Router chaque leçon vers la bonne destination

Toutes les destinations « repo » (rules/skills/CLAUDE.md) sont versionnées Git → synchronisées entre machines et partagées avec l'équipe. C'est le choix par défaut.

4. Proposer — et STOP

Présenter un tableau de propositions, sans rien écrire encore, puis attendre la validation explicite de l'utilisateur. Format :

Frictions de la session :

1. <friction> (tour ~N)
   Cause racine : <cause>
   → Proposition : <action> dans <fichier cible>
     Texte exact à ajouter/modifier :
     ----
     <le contenu précis>
     ----

2. …

Aucune capitalisation pour : <frictions jugées ponctuelles, listées avec une phrase de justification>

Règles pour les propositions :

• Donner le texte exact à écrire, jamais un vague « améliorer X ».
• Indiquer le fichier cible précis.
• Si une règle existante est concernée, proposer une modification (fusion/mise à jour) plutôt qu'un doublon — appliquer l'esprit ADD / MERGE / DELETE pour éviter que rules/ et CLAUDE.md enflent.
• Lister explicitement ce qu'on ne capitalise pas, avec la raison (transparence anti-bruit).

Après le tableau, demander : « On applique tout / une partie / rien ? » et attendre.

5. Appliquer

Sur validation, écrire uniquement les propositions retenues :

• nouveau fait/règle → créer/éditer .claude/rules/<sujet>.md
• nouveau savoir-faire → créer .claude/skills/<nom>/SKILL.md (frontmatter name + description, structure de cette skill comme modèle)
• convention transversale → éditer CLAUDE.md

6. Clôturer

• Récapituler ce qui a été écrit (liste des fichiers).
• Rappeler que ce sont des fichiers versionnés → proposer de committer (ne pas committer d'office ; suggérer /commit).

Garde-fous

• Ne jamais écrire avant validation (étape 4 obligatoire) — comme la skill commit.
• Ne pas sur-capitaliser : une session saine peut ne produire aucune règle, et c'est un résultat valable.
• Préférer modifier une règle existante plutôt qu'en ajouter une qui se recoupe.
• Ne pas committer sans demander.
• Si la rétro ne porte que sur un contexte compacté/partiel, le dire au lieu de prétendre couvrir toute la session.