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

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:

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