hériter-style-legacy

Hériter le Style Legacy

Empêche la dérive stylistique du code généré par IA dans les projets legacy en scannant le codebase à la recherche de conventions implicites selon 4 dimensions méta-architecturales, en résolvant les conflits avec l'utilisateur un par un, et en cristallisant le consensus dans un fichier .ai-style-rules.md exécutable. Totalement agnostique en matière de langage et de framework.

Quand Activer

• L'utilisateur tape /inherit-legacy-style
• L'utilisateur mentionne l'intégration de l'IA dans un projet legacy écrit à la main
• L'utilisateur craint que le code généré par IA ne « dérive » des conventions existantes du projet
• L'utilisateur souhaite extraire et codifier les règles de codage implicites de son projet

Quand Utiliser

Utilisez cette compétence lorsque vous devez préserver le style d'un projet legacy et empêcher la dérive stylistique générée par l'IA. Voir Quand Activer ci-dessus pour les conditions de déclenchement.

Prérequis

• Git (recommandé ; les projets sans Git utilisent les horodatages des fichiers en mode incrémental)
• Accès en lecture/écriture à la racine du projet (génère .ai-style-rules.md et éventuellement CLAUDE.md)

Flux de Travail

Étape 0 — Mode de Détection Automatique

Vérifiez silencieusement la présence de .ai-style-rules.md à la racine du projet :

Fichier existe ?	Mode
Non	Branche A — Analyse complète initiale
Oui	Branche B — Vérification incrémentale

Annoncez le mode en une ligne et poursuivez — ne demandez jamais à l'utilisateur de choisir.

Branche A — Analyse Complète Initiale

1. Mesurer l'échelle, choisir un niveau de scan

git ls-files | grep -cE '\.(js|ts|jsx|tsx|vue|py|go|rs|java|kt|rb|php|cs|swift|c|cpp|h)$'

Niveau	Fichiers sources	Stratégie
Petit	≲ 50	Lecture complète de chaque source
Moyen	50–500	Couche infrastructure = lecture complète ; couche métier = échantillon de 2–3 par dimension
Grand	≳ 500	Échantillonnage strict + limite de budget ; d'abord un résumé --stat, puis lectures ciblées

2. Scannage selon 4 dimensions

1. Anatomie du Fichier — ordre de déclaration dans le fichier (imports → types → logique principale → helpers → export)
2. État et Flux de Contrôle — conventions de nommage pour l'état asynchrone, la pagination, les indicateurs
3. Infrastructure — emplacement des utilitaires transversaux (intercepteurs, formateurs, middleware)
4. Gestion des Erreurs — try/catch vs intercepteur global vs retour Result ; habitudes de vérification de nullité

3. Appliquer la réduction de bruit par seuil de signal

Avant d'interrompre l'utilisateur, évaluez la force du signal :

• Signal faible → auto-suppression : minorité <5 % ET nombre <10 → la majorité gagne, la minorité va dans les DONTs
• Signal fort → questionner : répartition quasi-égale, ou divergence sémantique sur une dimension centrale
• Exception petit projet : sources ≲50, « 3 contre 2 » n'est PAS une majorité → questionner

4. Résoudre les conflits un par un (Protocole de Questionnement)

Pour chaque conflit à signal fort, présentez EXACTEMENT UNE question avec 4 options :

Preuve : pathA utilise le style X, pathB utilise le style Y AVERTISSEMENT : Risque : mélanger les deux fragmente le style du projet Choisissez : 1 suivre X 2 suivre Y 3 c'est une évolution, mettre à jour les règles 4 J'ai une nouvelle règle

Suspendre jusqu'à ce que l'utilisateur réponde, puis passer au conflit suivant. N'empilez jamais les questions.

5. Générer .ai-style-rules.md avec trois sections obligatoires :

• [Fichiers d'Or] — chemins d'exemples réels annotés avec ce qu'ils démontrent
• [Règles de Nommage et de Contrôle d'État] — conventions concrètes et vérifiables
• [DONTs] — anti-patrons qui ne doivent pas se propager

6. Installer le hook persistant

Demandez à l'utilisateur la force de l'application (utilisez AskUserQuestion) :

Option	Mécanisme
1 Hook doux (recommandé)	Écrire une référence @.ai-style-rules.md dans le fichier CLAUDE.md du projet
2 Hook dur	Hook doux + Hook `PreToolUse[Write
3 Pas de hook	Conserver le fichier de règles ; l'utilisateur s'y réfère manuellement

Branche B — Vérification Incrémentale

1. Lire le fichier .ai-style-rules.md existant ; s'il contient une empreinte de commit, git diff <last_hash> HEAD --stat pour identifier le delta
2. Lire les modifications Git récentes (git log -3 --stat → inspecter les fichiers suspects à la demande)
3. Pour les diffs surdimensionnés (>des centaines de fichiers) : résumé --stat uniquement + échantillonner les plus gros changements
4. Comparer le nouveau code avec les règles enregistrées → les conflits passent par le Protocole de Questionnement
5. Ajouter un journal d'évolution à la fin de .ai-style-rules.md (ne jamais écraser les anciennes règles)

Application par Tâche

Lorsque .ai-style-rules.md est dans le contexte (chargé via CLAUDE.md), chaque tâche d'écriture de code doit commencer par une déclaration de conformité dans la chaîne de raisonnement, nommant l'exemplaire suivi et les DONTs évités.

Comment ça Marche

Cette compétence détecte automatiquement s'il s'agit d'une exécution initiale ou incrémentale via la présence de .ai-style-rules.md :

• Première fois (Branche A) — Mesure l'échelle du projet, scanne le codebase selon 4 dimensions méta-architecturales (Anatomie du Fichier, État et Flux de Contrôle, Infrastructure, Gestion des Erreurs), applique la réduction de bruit par seuil de signal pour supprimer les conflits faibles, résout les conflits à signal fort un par un avec l'utilisateur, génère .ai-style-rules.md avec Fichiers d'Or / Règles de Nommage / DONTs, et propose des hooks d'application optionnels.
• Incrémentale (Branche B) — Lit les règles existantes, vérifie les diffs Git récents pour de nouveaux modèles ou des conflits, exécute le même protocole de questionnement un par un pour chaque conflit trouvé, et ajoute des journaux d'évolution sans écraser les règles existantes.
• Application par Tâche — Lorsque le hook est activé via CLAUDE.md, chaque tâche d'écriture de code commence par une déclaration de conformité nommant l'exemplaire suivi et les DONTs évités.

Spécification de Sortie

• .ai-style-rules.md à la racine du projet (avec empreinte de commit + niveau d'échelle dans l'en-tête)
• Éventuellement CLAUDE.md avec une référence @.ai-style-rules.md
• Journaux d'évolution ajoutés sous forme d'entrées ### [YYYY-MM-DD] Journal d'Évolution du Style

Anti-Patrons

• ÉCHEC : Ne PAS sauter l'étape de mesure d'échelle — échantillonner un projet de 30 fichiers « l'affame » ; scanner intégralement un dépôt de 5 000 fichiers explose le temps
• ÉCHEC : Ne PAS empiler plusieurs questions de conflit à la fois — le questionnement est strictement un par un
• ÉCHEC : Ne PAS écraser les anciennes règles en mode incrémental — toujours ajouter des journaux d'évolution
• ÉCHEC : Ne PAS par défaut au « hook dur » sans demander — la force de l'application est le choix de l'utilisateur
• ÉCHEC : Ne PAS juger la syntaxe ou la qualité de la pile technique — cette compétence aligne uniquement la méta-architecture
• ÉCHEC : Ne PAS copier les bogues des fichiers d'exemple — réutiliser la structure, signaler les défauts

Bonnes Pratiques

• Annoncez le mode détecté (première fois vs incrémental) et le niveau d'échelle en une ligne avant le scan
• Pour les grands projets, lisez d'abord les résumés --stat, puis des lectures ciblées sur les fichiers suspects
• Laissez le seuil de signal gérer le bruit — une divergence de nommage 843 contre 8 doit se résoudre automatiquement sans interruption de l'utilisateur
• En cas de doute sur la force du signal, penchez-vous vers la demande
• Le hook doux CLAUDE.md (@.ai-style-rules.md) est généralement suffisant ; le hook dur seulement si l'utilisateur souhaite une application mécanique

Compétences Associées

• init — initialiser un nouveau CLAUDE.md avec une documentation du codebase
• code-review — passer en revue les diffs pour la correction et les problèmes de style
• simplify — passer en revue le code pour détecter les opportunités de réutilisation et de simplification

Exemples

1. Première intégration

   • Utilisateur : « Aidez-moi à intégrer l'IA dans cette ancienne base de code sans changer son style. »
   • Action : Exécuter la Branche A analyse complète → mesurer l'échelle → scanner les 4 dimensions → questionner les conflits → générer .ai-style-rules.md → proposer la force du hook (doux/dur/aucun).

2. Mise à jour incrémentale après des changements d'équipe

   • Utilisateur : « Nous avons ajouté un nouveau module ; conservez les règles de style existantes intactes. »
   • Action : Exécuter la Branche B vérification incrémentale → comparer les deltas Git avec les règles enregistrées → questionner les nouveaux conflits → ajouter un journal d'évolution sans écrasement.

3. Application des DONTs via CLAUDE.md

   • Utilisateur : « Assurez-vous que tout nouveau code reste cohérent avec les règles du projet. »
   • Action : Hook doux installé → .ai-style-rules.md chargé automatiquement à chaque session → chaque tâche d'écriture de code commence par une déclaration de conformité, en réutilisant les motifs des exemplaires et en évitant les DONTs.