diff --git a/.claude/commands/retro.md b/.claude/commands/retro.md new file mode 100644 index 0000000..e705031 --- /dev/null +++ b/.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: +description: +metadata: + type: feedback +--- + + +**Pourquoi :** +**Comment l'appliquer :** +``` + +- 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. diff --git a/.claude/commands/sync.md b/.claude/commands/sync.md new file mode 100644 index 0000000..90403df --- /dev/null +++ b/.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. diff --git a/DECISIONS.md b/DECISIONS.md index 7ba046f..f6ab667 100644 --- a/DECISIONS.md +++ b/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é diff --git a/claude-code-starter-kit/.claude/commands/retro.md b/claude-code-starter-kit/.claude/commands/retro.md new file mode 100644 index 0000000..e705031 --- /dev/null +++ b/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: +description: +metadata: + type: feedback +--- + + +**Pourquoi :** +**Comment l'appliquer :** +``` + +- 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. diff --git a/claude-code-starter-kit/.claude/commands/sync.md b/claude-code-starter-kit/.claude/commands/sync.md new file mode 100644 index 0000000..080a246 --- /dev/null +++ b/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.