LLM Wiki Distiller

Que fait LLM Wiki Distiller ?

Idée centrale

Maintenir une base de connaissances personnelle destinée à être utilisée par un grand modèle de langage : consigner ce que l'utilisateur a appris, ce qui compte pour lui, ce qu'il a remarqué, ce qu'il a sauvegardé, ce qu'il oublie toujours, et ce qu'il souhaite que les futurs modèles retiennent. Ne pas recopier des connaissances encyclopédiques générales ; privilégier le point de vue personnel de l'utilisateur, les chemins d'origine, les informations postérieures à la date de coupure du modèle, et le contexte personnel réutilisable.

La racine de la base est fixée en quatre dossiers + trois fichiers racine (index.md / log.md / pending.md) :

1. raw/ : matériaux bruts, pièces jointes et boîte de réception à traiter.
2. wiki/ : entrées distillées maintenues par le LLM.
3. _staging/ : propositions temporaires pour traitement parallèle par lots (le dossier reste, le contenu est transitoire — supprimé après intégration).
4. review/ : rapports de révision (archivés par mois dans review/YYYY-MM/, le plus récent servant également de curseur de révision).

Toute création, modification, suppression, archivage ou révision substantielle doit mettre à jour simultanément index.md et log.md.

Plan des ressources

Ce fichier ne fait que router. Après avoir déterminé le mode, lisez immédiatement le mode correspondant ; celui-ci vous indiquera ensuite quelles reference/schema lire.

• modes/quick.md : ajout, modification, archivage, suppression rapides sans passer par la boîte de réception.
• modes/distill.md : traitement des raw/inbox/ ou d'autres matériaux bruts et distillation formelle.
• modes/review.md : révision, vérification de l'état, propositions de fusion ; chaque cycle produit un rapport daté.
• modes/search.md : recherche et résumé en lecture seule, sans écriture.
• modes/integrate.md : en orchestration parallèle, l'orchestrateur consolide en une seule passe les propositions de plusieurs sous-agents « capture-only » (unique scripteur, série).
• references/raw.md : dossier raw, classification des sources, pièces jointes, traitement des doublons.
• references/wiki.md : typologie des pages wiki, limites, règles d'écriture.
• schemas/common.md : champs YAML généraux, listes de vocabulaire contrôlé, dates et statuts.
• schemas/raw.md : pointeurs markdown bruts, métadonnées de source, règles de référencement des pièces jointes.
• schemas/wiki.md : frontmatter et structure du corps pour chaque type de page wiki.
• schemas/root.md : format de index.md, log.md, pending.md.
• schemas/report.md : emplacement, frontmatter et structure du corps du rapport de révision (le rapport le plus récent sert de curseur de révision).
• schemas/proposal.md : format de proposition temporaire pour le flux capture-only → integrate en orchestration parallèle.

Ne lisez pas toutes les ressources d’un coup. Suivez les étapes du mode choisi.

Étape 0 : Vérification du répertoire racine de la base

Avant d’utiliser un mode, assurez-vous que le répertoire de travail actuel est bien la racine de la base. Effectuez uniquement une vérification idempotente légère, sans lire d’autres références/schémas.

Considérez le répertoire actuel comme une base existante s’il correspond à au moins 2 catégories de signaux :

• Présence d’un dossier raw/ contenant inbox/, attachment/, dropzone/ ou d’autres sous-dossiers bruts.
• Présence d’un dossier wiki/ contenant concept/, entity/, summary/, scrap/ ou d’autres sous-dossiers wiki.
• Présence d’au moins 2 fichiers racine parmi index.md, log.md, pending.md.

Traitement :

• Au moins 2 catégories : poursuivre vers la porte de mode.
• 0 catégorie, répertoire vide ou presque : demander à l’utilisateur s’il souhaite initialiser une base dans ce répertoire ou fournir un chemin existant.
• 0-1 catégorie, répertoire manifestement autre projet : stopper et demander le chemin de la base ; ne pas créer raw/, wiki/ dans ce projet.
• Si l’utilisateur fournit explicitement un chemin dans sa requête, basculer sur ce chemin puis refaire la vérification.

Porte de mode

Choisir un mode parmi quatre selon l’intention de l’utilisateur, sans exiger qu’il prononce le nom du mode :

1. L’utilisateur veut réviser/maintenir une base existante : « fais une revue », « vérifie les contradictions », « exécute un check de santé » → lire modes/review.md.
2. L’utilisateur veut seulement chercher/demander/résumer du contenu existant, sans ajout ni modification → lire modes/search.md.
3. L’utilisateur veut ajouter, modifier, archiver ou supprimer, mais sans traiter des matériaux bruts inbox/raw → lire modes/quick.md.
4. L’utilisateur veut traiter raw/inbox/, des coupures, des longs textes, des conversations, des réseaux sociaux, des PDF, des transcriptions vidéo, des projets GitHub ou d’autres matériaux bruts → lire modes/distill.md.

En cas d’incertitude, privilégier le jugement : si l’utilisateur demande une écriture mais que la source n’est pas encore organisée → distillation ; requête pure → recherche ; maintenance de la base → révision.

Complément pour orchestration parallèle : Le mode distillation a une variante capture-only (chaque sous-agent ne prend qu’une seule entrée, écrit uniquement son propre résumé + raw + proposition _staging/<id>.md, sans toucher aux pages partagées) couplée au mode integrate (l’orchestrateur consolide plusieurs propositions en une seule passe). Les contraintes sont rédigées dans la section « mode d’exécution » de modes/distill.md ; quand et comment répartir les sous-agents est décidé par le fichier CLAUDE.md du projet appelant, pas par cette compétence.

Règles dures partagées

• Considérez le wiki comme une « mémoire compilée », pas un entrepôt de textes originaux. Conservez les chemins sources, ne recopiez pas l’intégralité du texte original dans le wiki.
• YAML original_url : ne mettez que des URL externes principales, pour ouvrir rapidement une page web, une vidéo, un billet, un article, la page d’accueil d’un projet, etc. ; n’autorisez que http:// ou https://. Les fichiers .md locaux, les chemins raw/..., wiki/summary/..., les chemins de pièces jointes, les chemins absolus/relatifs, les liens internes Obsidian et les documents locaux mentionnés dans une conversation ne doivent jamais être écrits dans original_url ; s’il n’y a pas d’URL externe, laissez un tableau vide []. Chemins raw, pages résumé et preuves internes : rédigez dans le corps de l’article sous ## Sources ou related. Les compléments de recherche, documents d’arrière-plan, lectures complémentaires : rédigez à la fin du corps sous ## Sources, n’insérez pas dans le frontmatter. N’utilisez pas le champ sources dans le YAML du wiki.
• Les connaissances antérieures au 2025-01-01 sont par défaut traitées succinctement, sauf si elles sont importantes pour l’utilisateur, rares ou constituent la base de sa pensée. Les connaissances postérieures au 2025-01-01 peuvent être traitées avec plus d’importance, car elles peuvent combler les lacunes post-datées du modèle, mais toujours selon le critère de l’utilité, pas de l’exhaustivité.
• Utilisez des dates absolues. Dans les faits persistants, n’écrivez pas seulement « hier », « aujourd’hui », « récemment » sans préciser la date absolue.
• Distinguez faits, inférences, préférences et signaux faibles. Les signaux faibles ne sont pas directement écrits comme des faits stables.
• En cas de conflit entre une nouvelle source et une page ancienne, conservez les deux points de vue, les sources et les dates, marquez le conflit, ne l’écrasez pas silencieusement.
• Avant d’écrire, recherchez les doublons de pages, les titres similaires, les alias, les URL sources et les phrases clés.
• Par défaut, ne supprimez jamais physiquement une connaissance ; archivez, marquez comme obsolète, remplacez tout en conservant l’historique. Confirmez avant toute suppression réelle.
• Pour les conclusions sensibles, à fort impact, médicales/juridiques/financières, ou définissant l’identité, si les preuves sont floues, demandez d’abord à l’utilisateur avant d’écrire.
• Distinguez le « travail de jugement » du « travail mécanique » : le jugement (choix de distillation, décision de fusion, évaluation de l’importance ou de la suppression) doit être effectué directement par l’agent après compréhension sémantique, sans déléguer à un script — c’est la valeur de cette compétence, les scripts n’ont pas de jugement. Le travail mécanique (filtrage basé sur des règles claires, comptage, renommage, conversion de format, et éventuellement recherche locale, indexation, base vectorielle pour les grandes bases) peut et doit être réalisé en priorité avec des outils en ligne de commande ou des scripts.
• Pour les opérations mécaniques, privilégiez les méthodes qui n’obligent pas à lire le fichier entier dans le contexte de l’agent (grep/sed/awk/script unique, exécution aveugle), et vérifiez le résultat par comptage et diff (wc -l, grep -c, git diff --stat), plutôt que de lire le fichier complet ou d’en afficher tout le contenu — on économise des tokens pour un résultat aussi fiable. Seules les opérations nécessitant du jugement (par exemple décider lors d’une révision si une entrée doit être conservée ou supprimée) nécessitent d’abord la lecture complète.
• N’incluez pas de fichiers d’orchestration d’agent. Les éventuels fichiers AGENTS.md, CLAUDE.md ou stratégies de sous-agents sont gérés par le projet utilisateur.