6.4 KiB
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 dansknowledge/ou un fichier global racineA_DEPLACER_CLAUDE_PROJET: pertinent mais trop spécifique au projetREJETER: bruit, redondance, ou formulation non exploitable
Entrées à lire systématiquement
95_a_capitaliser.mdknowledge/<domaine>/(patterns|risques)/README.mdcorrespondant au sujet- Le fichier cible indiqué dans chaque proposition
_projects.conf70_templates/projet_CLAUDE.md10_conventions_redaction.md
Workflow opératoire
- Extraire les blocs
FILE_UPDATE_PROPOSALde95_a_capitaliser.md. - Pour chaque bloc, identifier:
project_nametarget_file- idée centrale (1 phrase)
- signal technique principal (bug, anti-pattern, pattern, décision)
- 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.mdd’index)
- Classer le niveau de nouveauté:
DOUBLON_EXACT: déjà documenté explicitementDOUBLON_SEMANTIQUE: même règle exprimée autrementCOMPLEMENT: ajoute une nuance utile à une règle existanteNOUVEAU: absent de la base
- Évaluer la portée:
GLOBAL: réutilisable inter-projetsPROJET: dépend trop du contexte local
- Décider le routage final (
INTEGRER_KNOWLEDGE,A_DEPLACER_CLAUDE_PROJET,REJETER). - 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 sensiblessi risque récurrent et critique
Résoudre le chemin projet via _projects.conf.
Sur Linux NUC, destination attendue: /srv/projects/<project_name>/CLAUDE.md.
Sur macOS, destination attendue: /Volumes/TeraSSD/Projets_Dev/<project_name>/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:
## <DATE — PROJET> — <titre court>
Décision : <INTEGRER_KNOWLEDGE | A_DEPLACER_CLAUDE_PROJET | REJETER>
Confiance : <HIGH | MEDIUM | LOW>
Justification :
- Nouveauté : <DOUBLON_EXACT | DOUBLON_SEMANTIQUE | COMPLEMENT | NOUVEAU>
- Portée : <GLOBAL | PROJET>
- Motif principal : <1 phrase>
Action proposée :
- Si INTEGRER_KNOWLEDGE :
- Fichier : <chemin exact>
- Patch logique : <ajout/remplacement/fusion>
- Texte final proposé : <version courte prête à intégrer>
- Si A_DEPLACER_CLAUDE_PROJET :
- Projet : <nom>
- Fichier : <chemin CLAUDE.md résolu ou attendu>
- Section : <Leçons apprises | Points sensibles>
- Texte final proposé : <version projet>
- Si REJETER :
- Raison : <doublon/bruit/non-actionnable>
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:
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)
# 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 <project_name>