mxchen-xyz/knowledge-graph-skill-zh

Générateur de graphes de connaissances par lots

📌 Historique des versions

Version	Date	Changements
2.2.0	2026-09-02	Mise à niveau complète des gros projets : ① Stratégie de mise à niveau des fiches squelettes — déclenchée en masse lorsque l'utilisateur signale "trop de sections à compléter / règles trop simples", avec répartition parallèle des sous-agents par domaine + supervision par l'agent principal (grep du nombre restant de à compléter) ; reprise en cas de blocage. ② Les labels des nœuds mermaid ne doivent pas contenir de parenthèses imbriquées (cause n°1 d'échec de rendu) + script de correction regex en masse. ③ Les chemins relatifs inter-modules des sous-agents sont sujets aux erreurs (../..), la vérification finale doit inclure un test de double liage. ④ Mise à jour des statistiques de la mise à niveau et du README.
2.1.0	2026-09-01	Correction importante de la normalisation des chemins wiki Obsidian : Les liens wiki [[...]] d'Obsidian ne supportent pas les chemins relatifs ../ (../ est interprété comme un nom de note, rendant le lien non cliquable). Ils doivent tous être convertis en chemins complets depuis la racine du coffre (`[[domaine/module/fonctionnalité.md
2.0.0	2026-08-24	Correction de la compatibilité double liage Obsidian : Le 5e lot ajoute la validation "pas de syntaxe à points + validation du chemin relatif lien par lien", garantissant que le coffre généré est navigable dans Obsidian.
1.0.0	Version initiale	Capacité de base : stratégie de génération par lots (5 lots : L1+L2 squelette → L3 index des modules → fiches fonctionnelles critiques → fiches squelettes du reste → vérification globale de la qualité).

Aperçu

Ingénierie des connaissances pour les projets à grande échelle. Lorsqu'un projet possède un code/documentation complet, plus de 50 nœuds fonctionnels et nécessite la génération unique d'un coffre de connaissances de plusieurs centaines de nœuds, la stratégie par lots permet une production efficace en évitant la surcharge de sortie unique. Tout le contenu des fichiers doit respecter les spécifications des templates définies dans le skill business-knowledge-graph-generator (references/templates.md).

Quand utiliser

• Projets volumineux avec plus de 50 fonctionnalités.
• Structure complète du répertoire du code + contenu des fichiers de code principaux disponibles (peut être fourni par lots).
• Nécessité de générer un coffre de connaissances complet de plusieurs centaines de nœuds en une seule fois.

Entrée requise : fournir la structure complète du répertoire du code + le contenu des fichiers de code principaux (peut être fourni par lots).

Stratégie de traitement par lots

Lorsque le nombre de fonctionnalités dépasse 50, traiter en 5 lots dans l'ordre suivant :

Premier lot : squelette L1 + L2 (structure globale) — ~6 à 20 fichiers attendus

1. Générer knowledge/_index.md (vue d'ensemble L1).
2. Pour chaque domaine, générer <domaine>/_index.md (carte du domaine L2).
3. Contrôle qualité : vérifier que tous les domaines et modules sont couverts, sans oubli.

Deuxième lot : index des modules L3 (liste des fonctionnalités) — ~20 à 50 fichiers attendus

1. Pour chaque module, générer <domaine>/<module>/_index.md (carte du module L3).
2. Contrôle qualité : vérifier que la liste des fonctionnalités de chaque module est complète et que toutes les fonctionnalités sont nommées.

Troisième lot : fiches fonctionnelles hautement prioritaires (processus critiques) — ~20 à 30 fichiers attendus

1. Identifier les fonctionnalités principales du système (les 20% les plus utilisées, comme connexion, commande, paiement).
2. Générer pour ces fonctionnalités des fiches L4 complètes (avec processus, règles, événements, dépendances, emplacement du code).
3. Contrôle qualité : les processus critiques incluent les branches d'exception ; les emplacements de code sont précis jusqu'au numéro de ligne.

Quatrième lot : fiches squelettes des autres fonctionnalités — ~50 à 200+ fichiers attendus

1. Générer des fiches minimales pour les fonctionnalités restantes (au moins Frontmatter + description de la fonctionnalité + règles de base).
2. Marquer état: à compléter pour une amélioration manuelle ultérieure.
3. Contrôle qualité : toutes les fonctionnalités disposent d'un fichier .md correspondant, sans oubli.

Cinquième lot : vérification globale de la qualité et mise à jour de l'index

1. Vérifier que tous les double-liages sont des chemins relatifs compatibles Obsidian ([[../module/fonctionnalité.md|alias]]), sans syntaxe à points ([[domaine.module.fonctionnalité]]).
2. Parcourir et valider : pour chaque lien, après résolution relative au fichier courant, le fichier .md cible doit exister.
3. Marquer tous les liens pendants, générer une liste de corrections.
4. Mettre à jour les statistiques dans _index.md de chaque niveau (nombre de modules, nombre de fonctionnalités).
5. Générer knowledge/README.md comme guide d'utilisation.

Règles de priorité

Priorité	Critère	Exemple de fonctionnalité
Critique	Utilisé quotidiennement dans > 80% des scénarios, lié à la sécurité financière	Connexion, commande, paiement, remboursement
Important	Utilisé quotidiennement dans 30%~80% des scénarios, lié à la gestion des données	Consultation de commande, suivi logistique, modification d'informations
Général	Fonctionnalités d'administration, opérations peu fréquentes, configuration	Gestion des catégories de produits, consultation des logs, génération de rapports

Exigences de sortie

1. Sortie par lot. Après chaque lot, signaler la progression et attendre la confirmation de l'utilisateur avant de passer au lot suivant.
2. À chaque lot, lister le fichier de ce lot.
3. Après le troisième lot (fonctionnalités critiques), faire une pause et attendre que l'utilisateur spécifie le prochain domaine prioritaire.
4. Tout le contenu des fichiers doit respecter les spécifications des templates définies dans business-knowledge-graph-generator/references/templates.md.

Format de rapport par lot

## Lot X terminé ✅

**Nombre de fichiers générés** : XX
**Domaines concernés** : DomaineA, DomaineB
**Liste des fichiers** :

- knowledge/DomaineA/_index.md
- knowledge/DomaineA/ModuleA/_index.md
- ...

**Prochain lot prévu** : Générer les fiches fonctionnelles critiques du domaine XXX

Veuillez confirmer si l'on continue ?

Remarques importantes

• Livraison par lots : Si le projet dépasse 100 fonctionnalités, terminer d'abord les squelettes L1 et L2, puis descendre progressivement au L3, et enfin générer les L4 en masse.
• Limite de lecture du code : Si le code est trop volumineux, demander à l'utilisateur de fournir d'abord 5 à 10 fichiers clés des modules principaux ; le reste peut être décrit uniquement par la structure des répertoires.
• Complément manuel : Le skill génère 80% du contenu (structure, processus, cadre des règles), mais les informations spécifiques sur les incidents passés et les responsables doivent être ajoutées manuellement par l'utilisateur.

Expériences pratiques (projet jetlinks, 2026-09-01)

1. Les liens Obsidian doivent utiliser le chemin absolu depuis la racine du coffre, sans extension .md (le plus important) : Les liens wiki Obsidian ne supportent pas les chemins relatifs ../ (../ est interprété comme un nom de note), et ne supportent pas non plus l'extension .md ([[Note.md]] est interprété comme une note nommée "Note.md" au lieu de "Note", rendant le lien non cliquable). Tous les liens doivent être écrits [[domaine/module/fonctionnalité|alias]] (depuis la racine knowledge/, sans .md). Dans les diagrammes mermaid, utiliser des nœuds texte (A[fonctionnalité] --> B[fonctionnalité]), interdire la syntaxe [[...]].
2. Dégradation en cas de limite de débit 429 des sous-agents : Lors d'exploration/génération de masse, les sous-agents peuvent déclencher une limitation de fréquence (429). Dans ce cas, dégrader en passant à la session principale : utiliser Glob/Grep pour localiser tous les @RequestMapping et annotations de méthodes HTTP des contrôleurs (précis jusqu'au numéro de ligne), puis écrire fichier par fichier.
3. Les scripts de contrôle qualité doivent ignorer les blocs de code : Les exemples de "normalisation des liens" dans les fiches L4 sont souvent écrits dans des blocs de code en backticks. Les expressions régulières de qualité doivent d'abord exclure le contenu de `...` et des blocs mermaid , sinon les exemples seront à tort signalés comme des liens pendants.
4. Mécanisme de réécriture du nombre de fonctionnalités : Le nombre de fonctionnalités par module dans l'index L2 est estimé ; après génération du L3, utiliser les valeurs réelles. Au 5e lot, un script met automatiquement à jour les colonnes de statistiques L2 et les statistiques de taille L1.
5. Utiliser des scripts pour la génération par lots : Pour le quatrième lot (100+ fiches squelettes), utiliser un script Python pour extraire les noms, types et descriptions des fonctionnalités à partir du tableau de l'index L3 via des expressions régulières, et les écrire en masse. Cela garantit la cohérence des noms et des liens, est plus efficace et moins sujet aux erreurs que l'écriture fichier par fichier.

Expériences pratiques (mise à niveau complète d'un grand projet, 2026-09-02)

6. Mise à niveau des fiches squelettes déclenchée en masse, sans attendre que l'utilisateur les cite : Si l'utilisateur se plaint que les sections "à compléter" ou les règles sont trop simples, déclencher une mise à niveau complète. Répartir par domaine, toutes les fiches squelettes sont mises à niveau vers le niveau de détail complet (voir les "critères de détail des fiches L4" du skill business).
7. Sous-agents parallèles répartis par domaine + supervision par l'agent principal : Envoyer un sous-agent par domaine (le prompt intègre un exemple de template, la règle absolue mermaid, et les exigences d'inspection du code). L'agent principal vérifie périodiquement avec grep -rl "état: à compléter" <domaine> | wc -l le nombre restant. Si un sous-agent reste bloqué (aucun nouveau fichier produit depuis un certain temps), l'agent principal reprend la main et complète le travail, sans attendre.
8. Les labels des nœuds mermaid ne doivent pas contenir de parenthèses imbriquées (cause n°1 d'échec de rendu) : L'apparition de () dans [..]/{..} d'un nœud flowchart (ex : A[Foo(x)]) provoque l'erreur "Expecting SQE, DOUBLECIRCLEEND...". Supprimer les parenthèses des signatures de fonctions ou les remplacer par des espaces. Correction en masse : expression régulière ciblant uniquement les blocs mermaid, remplaçant [label(args)] par [label args] (suppression des parenthèses, transformation des virgules en espaces).
9. Les chemins relatifs inter-modules des sous-agents sont sujets aux erreurs : Lorsqu'un sous-agent écrit un lien entre modules, les erreurs de niveau ../.. sont fréquentes (par exemple, pour pointer de gestionTransactions/journauxTransactions/ vers donnéesMarché/gestionFavoris/, le chemin correct est ../../donnéesMarché/gestionFavoris/_index.md et non ../gestionFavoris/). La vérification finale doit exécuter un script de validation des double-liages, listant les liens rompus à corriger un par un.
10. Triple vérification finale : Après la mise à niveau, exécuter ① script d'intégrité des double-liages (parcourt tous les .md, analyse les [[...]] en chemins relatifs et vérifie l'existence de la cible) ② analyse des parenthèses dans les blocs mermaid ③ comptage des résidus à compléter (grep -rl "état: à compléter" | wc -l doit être 0). Mettre à jour les statistiques du README avant la livraison.

Guide opérationnel pour la mise à niveau des fiches squelettes par lots

Lorsque knowledge/ contient déjà de nombreuses fiches squelettes à mettre à niveau :

1. Compter les restants : grep -rl "état: à compléter" knowledge/*/ | wc -l   (par domaine)
2. Envoyer des sous-agents parallèles par domaine (chaque prompt doit inclure : chemin absolu de l'exemple de template,
   règle absolue mermaid, exigence d'inspection du code "au moins 1-2 noms de fonctions réels + numéros de ligne,
   si non trouvé, marquer 'à localiser', ne pas inventer", format de rapport de sortie)
3. L'agent principal vérifie périodiquement : find les fichiers avec mtime récent / grep le nombre restant de à compléter ;
   en cas de blocage, reprendre la main
4. Vérification finale : script de validation des double-liages + analyse des parenthèses mermaid + comptage des à compléter à zéro
5. Mettre à jour les statistiques du README et les nombres des _index de chaque couche

Ressources

• business-knowledge-graph-generator/references/templates.md : Spécifications des templates L1~L4 (à respecter impérativement)