mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-06 21:41:42 +02:00
fc0bec0e2b
- backend/risques/nestjs : guard multi-statut READ_METHODS avant statut - backend/patterns/nestjs : fusionner lastSeenAt dans la réconciliation - backend/risques/contracts : pas de process.env dans services/helpers - backend/risques/nextjs : self-request Server Action + EXDEV atomic write - backend/risques/prisma : champ enum-like stocké en String - frontend/risques/general : Alert.prompt iOS-only - frontend/risques/tests : 3 anti-patterns (helpers copiés, test indirect, test façade) - workflow/risques/story-tracking : 2 entrées (hors périmètre, File List approximative) - skill capitalisation-triage : nouveau format de rapport (tableaux par domaine) - 95_a_capitaliser.md : purgé
190 lines
6.9 KiB
Markdown
190 lines
6.9 KiB
Markdown
---
|
||
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>
|
||
```
|