feat: commandes /retro (feedback persisté) et /sync (amorce de contexte)

.claude/commands/retro.md

@@ -0,0 +1,46 @@
+---
+description: Capture en fin de session ce qui a marché ou coincé, en mémoire feedback
+argument-hint: "[note libre facultative sur la session]"
+---
+
+Note libre du développeur : $ARGUMENTS
+
+Boucle de feedback persistée. But : que les corrections et les façons de
+travailler validées **survivent à la session** au lieu d'être à répéter. Tu écris
+dans la mémoire fichier du projet (le mécanisme `MEMORY.md` + `memory/`), pas dans
+le dépôt.
+
+Procède en trois temps, et ARRÊTE-TOI après le 1ᵉʳ :
+
+## 1. Proposer (puis STOP)
+- Relis la session : qu'est-ce qui a bien fonctionné, qu'est-ce qui a frotté, et
+  quelle correction ou préférence le développeur a exprimée ?
+- Propose **1 à 3 entrées** `feedback` candidates, chacune résumée en une ligne.
+  Pas plus : on garde le signal, pas le bruit.
+- Pour chaque candidate, vérifie d'abord s'il existe déjà une entrée qui la
+  couvre (lis `MEMORY.md`) — si oui, propose de **mettre à jour** plutôt que de
+  dupliquer.
+- **STOP.** Attends que le développeur valide, amende ou retire des entrées.
+
+## 2. Écrire (après validation)
+Pour chaque entrée validée, crée un fichier dans `memory/` au format mémoire :
+
+```markdown
+---
+name: <slug-kebab-case>
+description: <résumé en une ligne, sert au rappel>
+metadata:
+  type: feedback
+---
+
+<le fait : ce qui a marché / la correction.>
+**Pourquoi :** <la raison, le gain.>
+**Comment l'appliquer :** <règle actionnable la prochaine fois.>
+```
+
+- Lie les entrées connexes avec `[[autre-nom]]`.
+- Ajoute le pointeur dans `MEMORY.md` : `- [Titre](fichier.md) — accroche.`
+
+## 3. Clôturer
+Récapitule en une ligne par entrée écrite (ou « rien à retenir » si la session
+n'a rien produit de durable). N'invente pas de feedback pour remplir.

.claude/commands/sync.md

@@ -0,0 +1,28 @@
+---
+description: Amorce de contexte — restitue l'état du projet et l'intention présumée
+---
+
+Amorce de contexte en début de session. But : éviter de te faire ré-expliquer où
+on en est. Tu **lis seulement** et tu restitues — tu ne modifies rien.
+
+## 1. Lire l'état présent
+- Le journal des décisions : `DECISIONS.md` (les dernières entrées surtout).
+- L'état git : branche courante, `git status` (travail en cours non commité),
+  `git log --oneline -5` (commits récents).
+- Le cas échéant, les PR ouvertes (`gh pr list`) si pertinent.
+
+## 2. Restituer (court)
+En **trois lignes maximum**, sans détailler le diff :
+- **Où on en est** : branche, ce qui est commité vs en cours, dernière décision.
+- **Ce que je crois que tu veux faire** : l'intention probable de la session,
+  déduite du travail en cours.
+- **Point d'attention** s'il y en a un (travail non commité qui traîne, branche
+  en retard sur `main`, décision laissée ouverte).
+
+## 3. Faire valider
+Termine par une question fermée : « C'est bien ça, ou je me trompe ? » Attends la
+correction du développeur avant d'entamer quoi que ce soit. Ne propose pas de
+plan ici — `/sync` cadre le **présent**, pas la tâche à venir (ça, c'est `/brief`).
+
+> Alternative : ce cadrage pourrait être automatisé via un hook `SessionStart`.
+> On a préféré une commande explicite pour rester maître du moment et du coût.

DECISIONS.md

@@ -30,6 +30,27 @@ Entrées **antéchronologiques** (la plus récente en haut). La date au format `
 
 ---
 
+## 2026-06-17 — Commandes /retro (feedback persisté) et /sync (amorce de contexte)
+
+- **Contexte** : deux frictions récurrentes dans la collaboration dev ↔ Claude —
+  les corrections de méthode se perdent d'une session à l'autre (à répéter), et
+  chaque début de session impose de ré-expliquer où en est le projet.
+- **Décision** : deux slash-commands sur le modèle de `/brief`. (1) `/retro` :
+  en fin de session, formaliser ce qui a marché/coincé en 1–3 entrées `feedback`
+  de la mémoire fichier (`MEMORY.md` + `memory/`), avec validation et anti-doublon.
+  (2) `/sync` : en début de session, lire `DECISIONS.md` + l'état git + le WIP et
+  restituer en ≤ 3 lignes l'état présent et l'intention présumée, à valider, sans
+  rien modifier. Versions génériques ajoutées au `claude-code-starter-kit/`.
+- **Options écartées** : pour `/retro`, un `FEEDBACK.md` versionné dans le dépôt
+  (rejeté — le feedback de collaboration relève de la mémoire, pas du code, et la
+  mémoire existe déjà pour ça). Pour `/sync`, un hook `SessionStart` automatique
+  (rejeté pour l'instant — coûteux/bruyant à chaque démarrage ; une commande
+  explicite garde la main sur le moment et le coût).
+- **Pourquoi** : faire durer les corrections (moins de répétition) et supprimer le
+  coût de ré-amorçage en début de session — compléments de `/brief` (cadre la
+  tâche à venir) et du hook `verify-gate` (vérifie la clôture).
+- **Trace** : branche `main` (session du 2026-06-17).
+
 ## 2026-06-17 — Porte de vérification (hook Stop) avant clôture
 
 - **Contexte** : le principe « ne jamais affirmer 'c'est fait' sans avoir lancé

claude-code-starter-kit/.claude/commands/retro.md

@@ -0,0 +1,46 @@
+---
+description: Capture en fin de session ce qui a marché ou coincé, en mémoire feedback
+argument-hint: "[note libre facultative sur la session]"
+---
+
+Note libre du développeur : $ARGUMENTS
+
+Boucle de feedback persistée. But : que les corrections et les façons de
+travailler validées **survivent à la session** au lieu d'être à répéter. Tu écris
+dans la mémoire fichier du projet (le mécanisme `MEMORY.md` + `memory/`), pas dans
+le dépôt.
+
+Procède en trois temps, et ARRÊTE-TOI après le 1ᵉʳ :
+
+## 1. Proposer (puis STOP)
+- Relis la session : qu'est-ce qui a bien fonctionné, qu'est-ce qui a frotté, et
+  quelle correction ou préférence le développeur a exprimée ?
+- Propose **1 à 3 entrées** `feedback` candidates, chacune résumée en une ligne.
+  Pas plus : on garde le signal, pas le bruit.
+- Pour chaque candidate, vérifie d'abord s'il existe déjà une entrée qui la
+  couvre (lis `MEMORY.md`) — si oui, propose de **mettre à jour** plutôt que de
+  dupliquer.
+- **STOP.** Attends que le développeur valide, amende ou retire des entrées.
+
+## 2. Écrire (après validation)
+Pour chaque entrée validée, crée un fichier dans `memory/` au format mémoire :
+
+```markdown
+---
+name: <slug-kebab-case>
+description: <résumé en une ligne, sert au rappel>
+metadata:
+  type: feedback
+---
+
+<le fait : ce qui a marché / la correction.>
+**Pourquoi :** <la raison, le gain.>
+**Comment l'appliquer :** <règle actionnable la prochaine fois.>
+```
+
+- Lie les entrées connexes avec `[[autre-nom]]`.
+- Ajoute le pointeur dans `MEMORY.md` : `- [Titre](fichier.md) — accroche.`
+
+## 3. Clôturer
+Récapitule en une ligne par entrée écrite (ou « rien à retenir » si la session
+n'a rien produit de durable). N'invente pas de feedback pour remplir.

claude-code-starter-kit/.claude/commands/sync.md

@@ -0,0 +1,28 @@
+---
+description: Amorce de contexte — restitue l'état du projet et l'intention présumée
+---
+
+Amorce de contexte en début de session. But : éviter de te faire ré-expliquer où
+on en est. Tu **lis seulement** et tu restitues — tu ne modifies rien.
+
+## 1. Lire l'état présent
+- Le journal des décisions : `DECISIONS.md` (les dernières entrées surtout).
+- L'état git : branche courante, `git status` (travail en cours non commité),
+  `git log --oneline -5` (commits récents).
+- Le cas échéant, les PR ouvertes (`gh pr list`) si pertinent.
+
+## 2. Restituer (court)
+En **trois lignes maximum**, sans détailler le diff :
+- **Où on en est** : branche, ce qui est commité vs en cours, dernière décision.
+- **Ce que je crois que tu veux faire** : l'intention probable de la session,
+  déduite du travail en cours.
+- **Point d'attention** s'il y en a un (travail non commité qui traîne, branche
+  en retard sur la branche d'intégration, décision laissée ouverte).
+
+## 3. Faire valider
+Termine par une question fermée : « C'est bien ça, ou je me trompe ? » Attends la
+correction du développeur avant d'entamer quoi que ce soit. Ne propose pas de
+plan ici — `/sync` cadre le **présent**, pas la tâche à venir (ça, c'est `/brief`).
+
+> Alternative : ce cadrage pourrait être automatisé via un hook `SessionStart`.
+> On a préféré une commande explicite pour rester maître du moment et du coût.