Growth Log Pattern Extraction

Sélectionné par Skill Harbor : une méthodologie qui corrige l'échec le plus courant des journaux d'apprentissage, écrire « bug corrigé dans X » et appeler ça de la croissance. Un vrai journal de croissance extrait le pattern pour le reconnaître la prochaine fois. Trois règles gouvernent chaque entrée. Règle 1, les échecs battent les réussites : un bug de deux heures enseigne plus que trois fonctionnalités qui ont marché du premier coup, écrivez donc le pattern (cookie de session SameSite passé à Lax par défaut dans Chrome 128+, pattern : toujours définir SameSite=None; Secure explicitement) pas l'événement. Règle 2, le principe Bole : avant d'écrire, cherchez dans les entrées existantes la même cause racine ; même cause racine avec symptômes différents se fusionne, ne se duplique jamais. Règle 3, chaque entrée doit être transférable : si vous ne pouvez pas écrire « la prochaine fois que je vois [signal], je vais [action] », vous n'avez pas encore extrait le pattern. Le modèle fait 4 à 8 phrases sur les sections Contexte, Cause racine, Le Pattern et Liens, avec quatre types d'entrées (Échec, Méthodologie, Découverte de pattern, Changement de capacité) et une checklist qualité couvrant la discipline du titre, la phrase transférable, la spécificité du signal et la recherche de doublons. Il s'associe au hook Stop delivery-gate : le hook impose qu'un fichier d'apprentissage ait été touché aujourd'hui, ce skill garantit que le contenu vaut la peine d'être gardé. Fonctionne avec tout système de notes : fichiers Markdown, Notion, Obsidian, texte brut. Par @affaan-m, listé ici avec crédit à son créateur. Tiré du dépôt affaan-m/ECC (MIT). Bémols honnêtes : ne journalisez que quand un pattern émerge (débogage, reprise, rollback, décision non évidente) ; écrire une entrée pour chaque commit trivial produit du bruit, et sauter la phrase transférable produit un journal intime. Skill Harbor ne vérifie jamais le code, examinez-le vous-même avant usage.