ShockRock2004/kamar-taj

Wong — guide d'apprentissage de fin de journée (anciennement journal quotidien)

Transformez une journée complète de travail avec Claude Code (à travers toutes les sessions et dépôts) en un seul fichier Markdown daté, rédigé comme un guide pédagogique, afin que l'utilisateur puisse réellement apprendre le travail : réimplémenter le code à la main, comprendre pourquoi chaque décision a été prise, et être capable d'expliquer son fonctionnement parce qu'il le comprend vraiment.

Le résultat n'est PAS un journal des modifications. C'est un manuel pour débutant — rédigé de manière si simple et conversationnelle qu'une personne sans aucune expérience en logiciel pourrait le lire du début à la fin et comprendre à la fois ce qui a été fait et pourquoi. Chaque terme technique est défini en langage simple la première fois qu'il apparaît ; le code reste technique mais est enveloppé d'explications en anglais simple. La profondeur et le "pourquoi" importent plus que l'exhaustivité des détails anecdotiques. Voir les règles complètes de Style d'écriture — OBLIGATOIRE à l'étape 4.

Étape 0. Lire le niveau d'effort depuis la commande

L'utilisateur peut passer un niveau d'effort comme premier argument : light, medium, ou heavy. Si aucun n'est donné, par défaut utilisez heavy. (Ils peuvent aussi passer une date ; un jeton YYYY-MM-DD est la date, un jeton light/medium/heavy est l'effort. Dans n'importe quel ordre, tous deux facultatifs. Par exemple /wong medium, /wong light 2026-06-25.)

L'effort contrôle l'utilisation des tokens — il met à l'échelle à la fois la taille du résumé (via --effort sur le collecteur) ET ce que vous faites pendant l'écriture :

• light — le moins cher. Documentez seulement les 2–3 principaux travaux. Ne lancez pas git show/lectures de fichiers supplémentaires ; fiez-vous au résumé + messages de commit, et incluez au plus un court extrait de code au total. Gardez chaque section brève. Produisez quand même la section des compétences Git, le résumé Slack, le PDF et le téléchargement.
• medium — équilibré. Documentez les ~5 principaux travaux. Récupérez du code réel (git show) seulement pour les 2–3 plus importants. Profondeur modérée.
• heavy (par défaut) — le traitement complet décrit ci-dessous : chaque travail distinct, récupérez du code réel pour chacun, profondeur totale.

Transmettez le niveau choisi à travers toutes les étapes.

Étapes

1. Collecter le matériel brut de la journée

Exécutez le collecteur avec l'effort choisi (il lit chaque transcription de session depuis le disque, donc il capture toutes les sessions concurrentes/fermées, pas seulement celle-ci) :

python3 ~/.claude/skills/wong/collect_day.py --effort heavy

Remplacez heavy par le niveau de l'étape 0. Pour enregistrer un jour passé, ajoutez la date : python3 ~/.claude/skills/wong/collect_day.py --effort medium 2026-06-25

Il affiche le chemin vers un fichier de résumé (~/Daily Log/.digest-<date>.md). Lisez ce résumé entièrement. Il contient, par dépôt : la carte des commits Git du jour, les statistiques des modifications non commitées, et par session — les invites de l'utilisateur, les fichiers que Claude a édités, la prose explicative de Claude, et tous les résultats de sous-agents.

Lisez aussi le glossaire à ~/Daily Log/.glossary.md (s'il n'existe pas, traitez-le comme vide). Il liste les termes triviaux/fondamentaux déjà expliqués les jours précédents. Vous NE ré-expliquerez PAS quoi que ce soit déjà présent — voir "Expliquer les termes triviaux une seule fois" à l'étape 4.

Si le résumé dit qu'aucune session n'était active, dites-le à l'utilisateur et arrêtez-vous.

2. Identifier les fonctionnalités/tâches distinctes

Regroupez le travail de la journée en travaux distincts, pas une section par session. Fusionnez les sessions/commits qui ont fait avancer la même fonctionnalité. Un "travail" est quelque chose que l'utilisateur pourrait montrer comme un travail distinct (par exemple "le correctif du bug de livraison d'appel de l'agent verto", "le plafond de taux d'abandon du composeur prédictif"). Visez les quelques choses qui ont vraiment compté ; ne gonflez pas avec des détails anecdotiques.

3. Obtenir le code réel pour chaque travail

Barrière d'effort : en light, sautez cette étape entièrement (pas de git show/lectures de fichiers — utilisez le résumé + messages de commit, max un extrait total). En medium, faites cela seulement pour les 2–3 travaux les plus importants. En heavy, faites-le pour chaque travail.

Le résumé liste les SHAs de commit et les fichiers édités mais PAS les différences complètes. Pour chaque travail que vous documentez, récupérez le code réel pour que les extraits soient réels, pas paraphrasés :

git -C <repo> show <sha>            # différence complète pour un commit
git -C <repo> show <sha> -- <path>  # différence d'un fichier
git -C <repo> diff -- <path>        # travail non commité

Ou lisez le fichier actuel aux lignes pertinentes. Préférez montrer les lignes clés (celles qui portent l'idée) plutôt que de vider des fichiers entiers.

Consultez les fichiers CLAUDE.md et docs/GOTCHAS.md du dépôt (s'ils existent) pour les pièges pertinents au travail — ils sont en or pour la section "Pièges et leçons".

4. Rédiger le guide pédagogique — INCRÉMENTAL, jamais écraser

Format du nom de fichier. Le fichier est enregistré dans ~/Daily Log/ et nommé :

<YYYY-MM> - <DD> - <une ligne de ce que nous avons fait ce jour-là>.md

ex. 2026-06 - 26 - Correction de la livraison d'appel de l'agent et début de la page d'accueil 3D Yotel.md. La partie "une ligne" est un titre court en langage simple du travail du jour (pas de tirets dedans, puisque les séparateurs de date utilisent déjà " - " ; gardez-la en dessous de ~12 mots). L'en-tête # en haut du fichier doit être la même chaîne que le nom de fichier sans le .md.

Trouver le fichier d'aujourd'hui (important pour la logique d'ajout). Parce que le suffixe d'une ligne varie, ne cherchez jamais un fichier exact <date>.md. Au lieu de cela, trouvez le fichier d'aujourd'hui par son préfixe de date — listez ~/Daily Log/ et faites correspondre le fichier commençant par <YYYY-MM> - <DD> - (ex. ls "~/Daily Log/" et choisissez celui commençant par 2026-06 - 26 - ). Il y en a au plus un par jour.

Cette compétence peut être exécutée plusieurs fois en un jour. À chaque exécution après la première, vous devez ajouter uniquement le travail non encore documenté — ne jamais écraser ni dupliquer ce qui est là.

Procédure :

1. Si aucun fichier pour aujourd'hui n'existe (aucun fichier ne correspond au préfixe de date) : créez-le avec la structure complète ci-dessous (Aperçu de la journée + une section par travail, numérotée ## 1., ## 2., …), nommé dans le format ci-dessus.
2. Si le fichier d'aujourd'hui EXISTE DÉJÀ (trouvé via le préfixe de date) : Lisez-le d'abord. Construisez un ensemble de ce qui est déjà couvert en scannant ses en-têtes ## N. <titre> existants et les SHAs de commit / ids de session dans chaque ligne Références. Ensuite, à partir du résumé d'aujourd'hui, identifiez les travaux dont les commits/sessions ne sont pas encore dans cet ensemble.
   • Gardez le titre d'une ligne du nom de fichier précis pour la journée entière : si le travail nouvellement ajouté change ce que devrait être le titre de la journée, renommez le fichier (et mettez à jour son en-tête # en conséquence) pour que le titre reflète toujours tout le travail fait ce jour-là. Si le titre convient toujours, laissez le nom tel quel.
   • S'il n'y a rien de nouveau, dites à l'utilisateur que le fichier est déjà à jour et arrêtez-vous (ne le réécrivez pas).
   • Sinon, ajoutez de nouvelles sections ## N. (continuez la numérotation existante) seulement pour le nouveau travail, en utilisant le même modèle par fonctionnalité.
   • Mettez à jour le bloc Aperçu de la journée sur place : augmentez les comptes de Commits/Sessions et étendez le Titre pour mentionner le travail nouvellement ajouté. Ne touchez pas aux sections de fonctionnalités existantes.
   • Utilisez Modifier (insertions ciblées), pas une réécriture complète, pour que les sections précédentes — y compris celles que vous avez éditées manuellement — soit préservées textuellement.

Traitez un "travail" comme déjà couvert si son SHA de commit ou l'id de session apparaît déjà dans le fichier. Faites correspondre ces identifiants, pas le libellé, afin qu'une ré-exécution ne produise jamais une section quasi-dupliquée.

Style d'écriture — OBLIGATOIRE (c'est tout l'intérêt)

Rédigez-le comme un chapitre de manuel pour un débutant complet — quelqu'un d'intelligent qui ne connaît rien aux logiciels. Le lecteur doit pouvoir suivre chaque section du début à la fin sans contexte préalable.

• Conversationnel et simple. Phrases courtes. Mots simples. Expliquez comme si vous parliez à un ami, pas comme si vous rédigiez un rapport. Évitez le jargon dans la narration.
• Définissez chaque terme technique une fois dans toute la série — pas une fois par jour. La première fois qu'un terme apparaît jamais, définissez-le en langage courant dans une boîte de citation : > **Ce que "X" signifie.** ... (utilisez des analogies du monde réel). Mais vérifiez d'abord le glossaire (~/Daily Log/.glossary.md) et ne redéfinissez jamais un terme déjà listé. Cela importe surtout pour les fondations triviales et récurrentes — ce qu'est un dépôt/commit/branche, ce qu'est Yotel, git basique — expliquez-les une fois, puis utilisez-les simplement. Un terme entièrement nouveau qui est vraiment central au travail d'aujourd'hui reçoit quand même sa boîte ; un terme de base qui a déjà été couvert non. Voir "Expliquer les termes triviaux une seule fois" ci-dessous pour les mécanismes.
• Restez technique seulement là où la précision technique est le sujet — par exemple le changement de code réel, le fichier exact, le vrai compromis. Montrez le code réel, mais encadrez-le d'explications en anglais simple avant et après, et commentez l'extrait en langage simple. Ne jetez jamais du code sans explication.
• Commencez chaque section par la "version quotidienne" — l'histoire en langage simple de ce qui était cassé/nécessaire et pourquoi cela importe — avant tout détail technique.
• Utilisez une courte note "Comment lire ce document" tout en haut, et un aperçu "La vue d'ensemble (lisez ceci en premier)" qui explique les projets en termes simples (quel est ce produit, qui l'utilise, pourquoi).
• Gardez les points "comment l'expliquer" sous une forme simple, une phrase de confiance, suivie d'une idée astucieuse à expliquer simplement.
• Soyez honnête : séparez clairement le code réellement livré de la configuration/exploration, et dites-le en mots simples.

Faites correspondre le ton du fichier existant le plus récent dans ~/Daily Log/ (lisez-le comme exemple de référence s'il en existe un).

Expliquer les termes triviaux une seule fois (le glossaire)

Un lecteur de toute la série ne devrait pas voir "ce qu'est un dépôt" ou "ce qu'est Yotel" ré-expliqué chaque jour. Donc :

1. Avant d'écrire, lisez ~/Daily Log/.glossary.md (la liste des termes déjà expliqués). Traitez tout ce qui s'y trouve comme connu — n'écrivez pas de boîte > **Ce que "X" signifie.** pour tout terme de la liste. Utilisez simplement le terme normalement.
2. Pendant l'écriture, ajoutez une boîte de définition seulement pour un terme qui est vraiment nouveau pour la série (pas dans le glossaire). Inclinez-vous fortement contre la redéfinition de fondations triviales ; en cas de doute sur un terme de base, supposez qu'il a été couvert et passez.
3. Après avoir écrit/ajouté, mettez à jour ~/Daily Log/.glossary.md : ajoutez (un par ligne) tout terme que vous avez défini pour la première fois aujourd'hui. Ne supprimez jamais les entrées existantes. Si le fichier n'existe pas, créez-le.

Cela s'applique surtout aux termes triviaux et récurrents (dépôt, commit, branche, espace de travail, ce qu'est le produit, git basique). Un terme complexe qui est le cœur du travail d'un jour peut encore être expliqué ce jour-là, mais une fois qu'il est dans le glossaire, il n'est plus réexpliqué plus tard.

Modèle par fonctionnalité et structure de l'Aperçu de la journée (adaptez les en-têtes à la voix de débutant ci-dessus — ce sont les contenus à couvrir, pas des étiquettes rigides à copier textuellement) :

# <YYYY-MM> - <DD> - <une ligne de ce que nous avons fait ce jour-là>

> **Comment lire ce document.** (1-2 phrases disant à un débutant comment l'utiliser.)

## La vue d'ensemble (lisez ceci en premier)
Aperçu en langage simple de ce qui a été fait aujourd'hui. Définissez "projet/dépôt", "commit", et ce qu'est le produit (par exemple Yotel) ici **seulement s'ils ne sont pas déjà dans le glossaire** — c'est-à-dire sur le tout premier journal. Chaque jour suivant, passez ces bases et l'explicateur "quel est ce produit" ; nommez-les simplement et continuez.

---

## 1. <Titre en langage simple du travail>   (<dépôt>)

### La version quotidienne
L'histoire sans jargon — ce qui était cassé ou nécessaire, et pourquoi cela importe à une vraie personne. Utilisez une analogie.

### Ce qui se passait vraiment / le correctif (la partie technique)
Maintenant le détail précis : la vraie cause, le vrai changement de code (montré et expliqué en anglais simple avec des extraits commentés), le chemin de fichier exact `path`. Mettez une boîte `> **Ce que "terme" signifie.**` avant chaque nouveau mot technique.

### Comment vous pourriez le faire vous-même, étape par étape
Étapes numérotées et concrètes qu'un débutant pourrait suivre.

### Comment l'expliquer (une fois que vous l'avez compris)
- Un résumé en une phrase simple de ce que fait le travail.
- La seule idée astucieuse, expliquée simplement.
- Le compromis à défendre, en termes quotidiens.

### Leçons à retenir
Points à retenir en langage simple + tout piège pertinent de CLAUDE.md / docs/GOTCHAS.md.

**Où le trouver :** fichiers, SHA(s) de commit, id(s) de session.

---

## 2. <travail suivant…>

---

## Compétences Git utilisées aujourd'hui
(Toujours la DERNIÈRE section du document. Construite à partir des blocs "Commandes Git exécutées par Claude" du résumé — voir les instructions dédiées ci-dessous.)

### <opération Git, ex. Enregistrer des modifications>   `git commit`
**Ce qu'elle a fait** — en mots simples, ce que cette commande a accompli aujourd'hui.
**Pourquoi** — pourquoi cette étape était nécessaire à ce moment du flux de travail.
**Comment faire vous-même** — la vraie commande avec une courte note sur ce que chaque partie et indicateur signifie, pour que le lecteur puisse l'exécuter à la main.

### <opération Git suivante…>

La section "Compétences Git utilisées aujourd'hui" — OBLIGATOIRE (toujours la dernière section)

Terminez le document de chaque jour par une section ## Compétences Git utilisées aujourd'hui, construite à partir des blocs "Commandes Git exécutées par Claude" dans le résumé (un bloc par session).

Comment la construire :

1. Rassemblez toutes les commandes Git de chaque session du résumé. Une entrée capturée peut être une commande composée (par exemple cd repo && git add ... && git commit ...) ; extrayez la ou les parties Git.
2. Regroupez-les par opération Git (par exemple enregistrer, créer une branche, créer un espace de travail, pousser, placer en zone de transit, placer en réserve, restaurer, rebaser, inspecter avec log/diff/show/status). Une sous-section par opération distincte — ne listez pas la même opération plusieurs fois. Si de nombreuses commandes sont simplement des inspections en lecture seule (git status, git log, git diff, git show), couvrez-les ensemble dans une courte sous-section "Exploration du dépôt" plutôt qu'une chacune.
3. Pour chaque opération, écrivez trois choses dans la voix de débutant utilisée partout ailleurs dans le document :
   • Ce qu'elle a fait — ce que cela a accompli dans le travail réel d'aujourd'hui.
   • Pourquoi — pourquoi cette étape était nécessaire à ce moment-là.
   • Comment faire vous-même — la vraie commande, avec une note simple sur ce que chaque partie et indicateur important signifie, pour que le lecteur puisse l'exécuter à la main. Mettez une boîte > **Ce que "X" signifie.** avant la première utilisation.