_Assistant_Lead_Tech/skills/capitalisation-triage/SKILL.md

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

Retourner un rapport court avec un bloc par proposition:

```md
## <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:

```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 <project_name>
```