_Assistant_Lead_Tech/skills/capitalisation-triage/SKILL.md

name, description

name

description

capitalisation-triage

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/<domaine>/(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/<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

Produire trois sections, une par décision. Omettre une section si aucune entrée dans la catégorie. Le texte final intégrable n'apparaît pas dans le rapport — il est produit lors de l'exécution (option 1) ou sur demande (option 2).

Légende confiance : 🟢 HIGH / 🟡 MEDIUM / 🔴 LOW

INTEGRER_KNOWLEDGE

Un tableau par domaine (backend, frontend, workflow, etc.), trié par flux puis fichier. La colonne Domaine est remplacée par le sous-en-tête de section.

🔧 Backend

Projet	Flux	Fichier	Titre court	Patch	Nouveauté	Confiance
…	patterns/risques	…	…	ajout/remplacement/fusion	NOUVEAU/COMPLEMENT/DOUBLON_SEMANTIQUE	🟢/🟡/🔴

🖥️ Frontend

Projet	Flux	Fichier	Titre court	Patch	Nouveauté	Confiance

⚙️ Workflow

Projet	Flux	Fichier	Titre court	Patch	Nouveauté	Confiance

(autres domaines si applicable : 🎨 UX, 🔁 n8n, 📦 Product)

📁 À déplacer vers CLAUDE.md

Projet	Titre court	Section	Confiance
…	…	Leçons apprises/Points sensibles	🟢/🟡/🔴

🗑️ Rejetées

Projet	Titre court	Motif
…	…	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>