CR8-OS/retro-bot

Menez une rétrospective agile sur une session de collaboration Claude terminée, pour identifier ce qui a bien fonctionné, ce qui n'a pas marché et ce qu'il faut améliorer.

Qu'est-ce que retro-bot ?

Retro-Bot est une compétence spécialisée pour lancer des rétrospectives agiles légères après une session de travail avec Claude. Elle permet de réfléchir ensemble à ce qui a bien fonctionné, ce qui a posé problème, et ce qu'il faut changer concrètement. La compétence construit un tableau rétro collaboratif, cartographie les problèmes en actions modifiables (mise à jour de compétences, édition de Claude.md, modifications de processus), applique ces changements avec un système de versionnement basé sur la copie, et enregistre un instantané daté dans un répertoire d'archive configuré par l'utilisateur. Cela crée une piste d'audit permanente de chaque rétrospective et de ses résultats. Retro-Bot fonctionne avec Claude Code, Cursor, Codex et d'autres plateformes d'agents IA. Il est déclenché par des phrases clés comme « let's do a retro », « run a retro », « rétrospective », « session review », ou « débriefons », et doit toujours être utilisé plutôt que d'improviser une rétrospective.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/CR8-OS/retro-bot/tree/HEAD/skills/retro-bot

Installed? Explore more Recherche et analyse de données skills: affaan-m/uspto-database, affaan-m/scholar-evaluation, affaan-m/literature-review · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Que fait retro-bot ?

Une compétence pour mener des rétrospectives agiles légères sur les sessions de collaboration avec Claude — pour améliorer progressivement le processus de travail avec Claude au fil du temps.

La boucle centrale : après avoir terminé un travail avec Claude, vous prenez quelques minutes pour répondre ensemble à trois questions :

  • Qu'est-ce qui a bien fonctionné ? (à continuer)
  • Qu'est-ce qui n'a pas bien fonctionné ? (frictions, reprises, confusion, tokens gaspillés)
  • Que devrions-nous changer ? (améliorations concrètes des compétences, des invites ou du processus)

Les modifications sont appliquées immédiatement et chaque rétrospective est sauvegardée sous forme d'instantané dans une archive persistante. Au fil du temps, cela constitue une piste d'audit continue de l'évolution de votre workflow Claude — et s'accumule pour créer une configuration qui devient sensiblement plus rapide à chaque session.


Phase 0 — Configuration du répertoire d'archive (première exécution uniquement)

Avant de commencer la rétrospective, vérifiez si un répertoire d'archive rétro a été configuré. Cherchez dans Claude.md un bloc comme celui-ci :

## Retro-Bot
archive_dir: [chemin]

S'il est déjà défini : passez directement à la Phase 1. Inutile de redemander.

S'il n'est pas défini : demandez clairement à l'utilisateur une fois :

« Avant de commencer — où voulez-vous enregistrer les instantanés des rétrospectives ? C'est une configuration unique. Donnez-moi un chemin de dossier (par exemple H:\My Drive\Retros ou ~/Documents/retros) et j'y enregistrerai automatiquement chaque rétrospective à l'avenir. »

Une fois que l'utilisateur a fourni un chemin :

  1. Ajoutez le bloc suivant à Claude.md (créez le fichier s'il n'existe pas) :
    ## Retro-Bot
    archive_dir: [le chemin donné]
    
  2. Créez le répertoire s'il n'existe pas
  3. Créez un fichier retro-log.md vide dans ce répertoire (voir Phase 6 pour son format)
  4. Confirmez : « Compris — l'archive rétro est définie sur [chemin]. Toutes les futures rétrospectives y seront sauvegardées. »

Puis continuez à la Phase 1.


Phase 1 — Lire le contexte de la session

Lisez la transcription de la session pour comprendre ce qui s'est réellement passé. Si votre environnement fournit un historique de session ou un outil de transcription, utilisez-le maintenant pour récupérer l'enregistrement complet de ce qui s'est produit. (Dans Cowork, ceci est disponible automatiquement ; dans Claude Code, utilisez /transcript ou l'équivalent si disponible.) Même sans la transcription complète, tirez parti de ce que vous savez : quelles compétences ont été utilisées, quels fichiers ont été créés, quels retours l'utilisateur a donnés en cours de session, où des choses ont dû être refaites.

Si l'utilisateur invoque cette compétence immédiatement après une session, vous avez déjà le contexte. S'il l'invoque plus tard avec une description, travaillez à partir de celle-ci.

Demandez à l'utilisateur de confirmer sur quelle session/travail il souhaite faire la rétrospective si ce n'est pas clair.


Phase 2 — Claude ouvre avec ses observations

Passez en premier. N'attendez pas que l'utilisateur énumère les plaintes — partagez ce que vous avez remarqué. Cela modélise un bon comportement rétrospectif, montre que vous étiez attentif et fait souvent remonter des choses que l'utilisateur n'a pas consciemment enregistrées mais reconnaîtra immédiatement.

Formulez les observations honnêtement et spécifiquement :

  • « J'ai remarqué que j'ai dû restituer le SOW deux fois parce que le premier format de tableau ne s'ouvrait pas correctement dans Word — c'est un problème de configuration de compétence que je peux corriger. »
  • « Vous m'avez donné le brief client en trois messages séparés plutôt qu'en un seul bloc — c'est à noter comme un modèle de workflow qui ralentit les choses. »
  • « Les compétences de construction de périmètre et de construction de SOW ont produit des chiffres cohérents — cela semblait fluide. »
  • « Je n'étais pas sûr du format d'exportation dont vous aviez besoin jusqu'à ce que vous me le disiez à mi-parcours — une question rapide upfront aurait évité un aller-retour. »

Limitez-vous à 3 à 5 observations. Soyez direct, pas sur la défensive. Vous êtes un participant, pas un témoin.


Phase 3 — Invitez les commentaires de l'utilisateur

Après votre ouverture, invitez l'utilisateur à ajouter, modifier ou contester :

« Voici mes observations. Qu'y a-t-il sur votre liste — quelque chose que j'ai manqué, quelque chose que vous formuleriez différemment, ou des choses que vous voulez être sûr de capturer ? »

Les points de friction de l'utilisateur sont souvent différents des vôtres. Ils peuvent signaler des choses qui prêtaient à confusion, des problèmes de qualité de sortie qu'ils n'ont pas mentionnés sur le moment, des désagréments de processus, ou des choses qui étaient excellentes et devraient être préservées. Capturez tout.


Phase 4 — Construire le tableau rétro

Une fois que vous avez tous deux contribué, présentez le tableau complet. Soyez spécifique — les éléments vagues ne produisent pas d'actions utiles.

## ✅ Bien fonctionné
- [chose spécifique qui s'est bien passée]
- ...

## ❌ N'a pas bien fonctionné
- [point de friction spécifique, cause racine si connue]
- ...

## 🔧 Idées de changement
- [suggestion concrète liée à un élément « n'a pas bien fonctionné »]
- ...

Demandez à l'utilisateur de confirmer avant de continuer :

« Est-ce que cela capture ce qui s'est passé ? Quelque chose à ajouter ou ajuster avant que nous décidions quoi faire ? »


Phase 5 — Cartographier en actions

Pour chaque idée de changement, déterminez le type et la priorité :

TypeQuand l'utiliser
🔧 Mise à jour de compétenceLe problème venait des instructions, du format de sortie ou du comportement par défaut d'une compétence
📋 Mise à jour projet/sessionContexte ou instruction limité à un projet, client ou type de session spécifique — pas global
📝 Mise à jour Claude.mdContexte manquant qui s'applique partout, dans tous les projets et sessions
💡 Note de processusChangement comportemental — aucune modification de fichier nécessaire, juste une manière différente de travailler
🆕 Nouvelle compétenceL'écart est récurrent et suffisamment important pour justifier sa propre compétence

La distinction clé entre une mise à jour projet/session et une mise à jour Claude.md est la portée. Si le contexte ne doit s'appliquer que lorsque vous travaillez sur un projet, client ou type de session spécifique, il appartient à la couche projet/session. S'il doit s'appliquer toujours, partout, pour l'utilisateur dans chaque travail, il appartient à Claude.md. Se tromper est coûteux dans les deux sens : trop dans Claude.md crée du bruit et une interférence de contexte entre les clients ; trop dans les fichiers projet signifie que vous devez redéfinir le contexte à chaque changement de projet.

Pour chaque action, indiquez ce qui change, où, pourquoi c'est important, et si agir maintenant ou noter pour plus tard. Confirmez avant d'appliquer quoi que ce soit :

« Voici ce que je propose de changer. Voulez-vous que je continue ? »

Consultez references/action-item-types.md pour des conseils détaillés sur chaque type.


Phase 6 — Appliquer les modifications avec versionnement

Appliquez chaque action confirmée en utilisant un modèle de versionnement basé sur la copie — ne jamais écraser directement le fichier source. La règle : lire le fichier actuel → appliquer les modifications en mémoire → écrire dans un nouveau nom de fichier de version (par exemple, SKILL-v1.1.md) → conserver l'ancien fichier dans archive/. Cela crée un historique récupérable sans outil de versionnement séparé.

Mises à jour de compétence : Lire le fichier actuel → appliquer en mémoire → écrire dans un nouveau nom de version → archiver l'ancien → ajouter une entrée dans le journal des modifications. Incrémentez la version patch pour les petites corrections, la version mineure pour les ajouts significatifs, la version majeure pour les changements d'architecture.

Mises à jour projet/session : Identifiez le fichier d'instruction approprié pour la portée du changement — cela peut être un CLAUDE.md au niveau du projet ou du dossier racine (Claude Code), une configuration de session Cowork, un fichier de brief permanent pour un engagement client récurrent, ou des instructions personnalisées limitées à un type de session. Si le fichier n'existe pas, créez-le. Appliquez le même modèle de copie en premier que pour tout autre changement de fichier.

Cibles courantes :

  • [dossier-projet]/CLAUDE.md — chargé automatiquement dans chaque session Claude Code pour ce projet
  • Un fichier de référence permanent [nom-client]-brief.md ou [nom-projet]-context.md
  • Configuration de session Cowork ou invite système
  • Instructions personnalisées Claude.ai (paramètres du compte → « Qu'aimeriez-vous que Claude sache »)

Mises à jour Claude.md : Lire le fichier actuel → ajouter le nouveau contexte dans la bonne section → écrire la nouvelle version → archiver l'ancienne. Si aucun Claude.md n'existe, créez-en un.

Notes de processus : Documentez dans l'instantané rétro (aucun fichier séparé nécessaire).

Après l'application, confirmez ce qui a changé :

« Fait — j'ai mis à jour [nom de la compétence] en v1.1 et ajouté une note dans Claude.md à propos de [sujet]. »


Phase 7 — Sauvegarder l'instantané rétro et mettre à jour le journal d'audit

Cette phase est obligatoire — chaque exécution de rétrospective doit produire un instantané sauvegardé, quel que soit le nombre d'actions appliquées. L'instantané est l'enregistrement ; le journal d'audit est le flux.

Étape 1 : Sauvegarder l'instantané rétro

Sauvegardez un instantané rétro complet dans le archive_dir configuré. Format du nom de fichier :

[archive_dir]/YYYY-MM-DD-[court-descripteur]-retro.md

Exemple : H:\My Drive\Retros\2026-05-15-construction-doc-retro.md

Gardez les descripteurs courts (3 à 5 mots, avec traits d'union) : construction-tableau-de-bord, ébauche-contenu, analyse-données-t2.

Modèle d'instantané

# Retro Snapshot: [Session Descriptor]
**Date:** YYYY-MM-DD
**Session type:** [Construction SOW / analyse de données / contenu / code / autre]
**Skills used:** [liste séparée par des virgules]
**Retro format:** [Ce qui a bien fonctionné / Débuter-Arrêter-Continuer / 4L / etc.]

---

## ✅ Bien fonctionné
- [élément]

## ❌ N'a pas bien fonctionné
- [élément]

## 🔧 Idées de changement discutées
- [élément]

---

## Actions et résultats

| # | Changement | Type | Cible | Statut |
|---|---|---|---|---|
| 1 | [description] | Mise à jour de compétence | [compétence] v1.0 → v1.1 | ✅ Appliqué |
| 2 | [description] | Mise à jour projet/session | [CLAUDE.md projet / brief client / config session] | ✅ Appliqué |
| 3 | [description] | Mise à jour Claude.md | Claude.md | ✅ Appliqué |
| 4 | [description] | Note de processus | — | 📝 Noté |
| 5 | [description] | Nouvelle compétence | [nom] | 🔜 Mis en attente |

---

## Accords de processus
[Tout accord comportemental pris lors de cette rétrospective — des choses que les deux parties ont convenu de faire différemment la prochaine fois, qui ne correspondent pas à une modification de fichier]

## Questions ouvertes / Backlog
[Éléments notés pour plus tard, choses à revoir, ou suivis de cette rétrospective]

## Notes
[Tout contexte supplémentaire qui vaut la peine d'être conservé]

Étape 2 : Mettre à jour le journal d'audit

Après avoir sauvegardé l'instantané, ajoutez une ligne à retro-log.md dans le répertoire d'archive. Ce fichier est le flux continu — un enregistrement consultable d'un seul coup d'œil de toutes les rétrospectives jamais effectuées.

Format de retro-log.md (créez avec cet en-tête lors de la première exécution) :

# Retro Log

Registre courant de toutes les sessions retro-bot.

| Date | Session | Appliquées | Notées | Mises en attente | Instané |
|---|---|---|---|---|---|

Ajoutez chaque nouvelle rétrospective comme une ligne :

| 2026-05-15 | Construction doc – proposition longue | 2 | 1 | 0 | [lien](2026-05-15-proposition-doc-retro.md) |
  • Appliquées : nombre d'actions avec le statut ✅ Appliqué
  • Notées : nombre de notes de processus (📝 Noté)
  • Mises en attente : nombre d'éléments marqués 🔜 Mis en attente

Après avoir sauvegardé les deux fichiers, confirmez :

« Instané rétro sauvegardé dans [archive_dir]/[nom_fichier] et le journal d'audit mis à jour. Vous avez maintenant [N] rétrospectives enregistrées. »


Ton et esprit

  • Claude passe en premier — partagez vos observations avant de demander celles de l'utilisateur.
  • Soyez spécifique — « le tableau .docx ne s'est pas affiché parce que les largeurs de colonnes étaient codées en dur » est plus utile que « le format de fichier était faux ».
  • Les petits changements s'accumulent — une correction de 3 lignes qui économise 10 minutes par session s'additionne rapidement.
  • Tout ne nécessite pas une correction — deux changements bien choisis valent mieux que huit changements à moitié faits.
  • Restez rapide — visez 10 à 15 minutes. Si cela dure trop longtemps, vous résolvez des problèmes dans la rétrospective plutôt que de les identifier. Réservez la résolution pour la Phase 6.

Fichiers de référence

  • references/retro-formats.md — Formats alternatifs : 4L, Démarrer/Arrêter/Continuer, Fâché/Triste/Content, Bateau à voile. Lisez quand l'utilisateur demande un format différent ou quand la variété servirait mieux la session que le format par défaut.
  • references/action-item-types.md — Conseils détaillés sur la mise à jour de compétence vs Claude.md vs note de processus vs nouvelle compétence. Lisez quand le type d'une action est ambigu.

Journal des modifications

VersionDateChangement
v1.02026-05-26Version initiale — workflow rétro complet, structure en 6 phases, versionnement par copie, modèle de rapport rétro
v1.12026-05-26Ajout de la Phase 0 de configuration du répertoire d'archive (configuration unique sauvegardée dans Claude.md), sauvegarde obligatoire de l'instantané rétro, journal d'audit courant (retro-log.md) avec suivi des résultats par rétrospective
v1.22026-05-26Ajout de la mise à jour projet/session comme type d'action distinct — couvre CLAUDE.md projet, config session Cowork, fichiers de brief client et instructions personnalisées Claude.ai ; clarification de la distinction de portée par rapport au Claude.md utilisateur
v1.32026-05-29Migration vers la structure de plugin (skills/retro-bot/SKILL.md), ajout de .claude-plugin/plugin.json pour la compatibilité Claude Code

Skills associés