--- name: capitalisation-triage description: Analyse et trie les propositions de `95_a_capitaliser.md` pour décider si elles doivent être intégrées dans la base globale `Lead_tech` ou déplacées vers le `CLAUDE.md` du projet source. Utiliser ce skill quand il faut: (1) détecter les doublons avec `knowledge/`, (2) filtrer ce qui est réellement global et réutilisable, (3) préparer des propositions d’intégration propres par fichier cible, et (4) router les apprentissages trop spécifiques vers la mémoire projet. --- # Objectif Décider, pour chaque `FILE_UPDATE_PROPOSAL` de `95_a_capitaliser.md`, l’une des issues suivantes: - `INTEGRER_KNOWLEDGE`: à intégrer dans `knowledge/` ou un fichier global racine - `A_DEPLACER_CLAUDE_PROJET`: pertinent mais trop spécifique au projet - `REJETER`: bruit, redondance, ou formulation non exploitable # Entrées à lire systématiquement 1. `95_a_capitaliser.md` 2. `knowledge//(patterns|risques)/README.md` correspondant au sujet 3. Le fichier cible indiqué dans chaque proposition 4. `_projects.conf` 5. `70_templates/projet_CLAUDE.md` 6. `10_conventions_redaction.md` # Workflow opératoire 1. Extraire les blocs `FILE_UPDATE_PROPOSAL` de `95_a_capitaliser.md`. 2. Pour chaque bloc, identifier: - `project_name` - `target_file` - idée centrale (1 phrase) - signal technique principal (bug, anti-pattern, pattern, décision) 3. Vérifier l’existence d’un doublon dans la base: - d’abord dans `target_file` - puis dans les fichiers voisins du même domaine (via le `README.md` d’index) 4. Classer le niveau de nouveauté: - `DOUBLON_EXACT`: déjà documenté explicitement - `DOUBLON_SEMANTIQUE`: même règle exprimée autrement - `COMPLEMENT`: ajoute une nuance utile à une règle existante - `NOUVEAU`: absent de la base 5. Évaluer la portée: - `GLOBAL`: réutilisable inter-projets - `PROJET`: dépend trop du contexte local 6. Décider le routage final (`INTEGRER_KNOWLEDGE`, `A_DEPLACER_CLAUDE_PROJET`, `REJETER`). 7. Reformuler tous les textes retenus pour respecter les conventions de rédaction actives. # Règles de décision (obligatoires) ## 1) Filtre doublon (priorité absolue) Si `DOUBLON_EXACT` ou `DOUBLON_SEMANTIQUE` sans nouvelle mitigation concrète: `REJETER`. Si doublon partiel avec amélioration exploitable (ex: condition manquante, contre-exemple utile): `COMPLEMENT` possible vers `INTEGRER_KNOWLEDGE`. ## 2) Test de globalité Classer `GLOBAL` seulement si la proposition respecte au moins 3 critères: - décrit un mécanisme technique générique (pas une feature nommée) - s’applique à plusieurs repos/projets du même stack - reste valable hors contexte temporel local - réduit clairement un risque de bug/régression - propose une mitigation actionnable en review/dev Sinon classer `PROJET`. ## 3) Routage des infos spécifiques Si `PROJET` mais pertinent: router vers `CLAUDE.md` du projet source, section: - `Leçons apprises` (par défaut) - ou `Points sensibles` si risque récurrent et critique Résoudre le chemin projet via `_projects.conf`. Sur Linux NUC, destination attendue: `/srv/projects//CLAUDE.md`. Sur macOS, destination attendue: `/Volumes/TeraSSD/Projets_Dev//CLAUDE.md`, ou demander une confirmation si le projet est introuvable. Si le projet est introuvable ou sans `CLAUDE.md`, produire une proposition prête à coller et le signaler explicitement. # Heuristiques de spécificité projet Indicateurs forts `PROJET`: - noms de routes, écrans, composants, modules internes nommés - dépendance à une version précise d’un outil non généralisée - wording produit/UI local (langue, copy, labels métier) - apprentissage valable uniquement pour une architecture locale Indicateurs forts `GLOBAL`: - piège structurel du framework - invariant de robustesse (erreur, contrat, navigation, session, etc.) - règle de validation applicable en code review partout # Conformité rédactionnelle (obligatoire avant proposition finale) Avant de proposer l'intégration effective: - Vérifier la langue: documentation en français, identifiants de code en anglais. - Respecter la structure du fichier cible (sections, style, niveau de détail). - Préférer une rédaction factuelle, courte, orientée risque/mitigation. - Éviter les formulations vagues ou non testables. - Harmoniser le vocabulaire avec les entrées déjà présentes dans le fichier cible. # Format de sortie attendu Retourner un rapport court avec un bloc par proposition: ```md ## — Décision : Confiance : Justification : - Nouveauté : - Portée : - Motif principal : <1 phrase> Action proposée : - Si INTEGRER_KNOWLEDGE : - Fichier : - Patch logique : - Texte final proposé : - Si A_DEPLACER_CLAUDE_PROJET : - Projet : - Fichier : - Section : - Texte final proposé : - Si REJETER : - Raison : ``` # Contraintes de qualité - Ne jamais inventer un fichier cible absent de la taxonomie Lead_tech. - Ne jamais promouvoir en global une règle purement locale. - Préférer une reformulation courte, testable, orientée mitigation. - Si une proposition est mal formulée mais utile, la réécrire au lieu de la rejeter. # Sortie décisionnelle utilisateur (obligatoire) Après le rapport de tri, toujours proposer un menu d'action: ```md Choix d'action : 1. Suivre les recommandations : intégrer les entrées retenues + purger `95_a_capitaliser.md` pour les éléments traités. 2. Ajuster avant intégration : appliquer mes modifications sur les entrées ciblées, puis me re-soumettre la version finale. 3. N'intégrer que les entrées `INTEGRER_KNOWLEDGE` (sans déplacement projet pour l'instant). 4. N'intégrer aucune entrée : conserver le rapport uniquement. ``` Si l'utilisateur choisit l'option 2, demander les modifications ciblées et réémettre une proposition consolidée avant tout patch. # Commandes utiles (optionnel) ```bash # lire la base en ciblant le domaine find knowledge -maxdepth 3 -type f | sort # ouvrir le fichier projet depuis son nom scripts/resolve-project-path.sh ```