nvk/llm-wiki : compiler un wiki depuis ses propres recherches

Le problème : des sessions d'agents qui ne laissent rien derrière elles

Une session de recherche avec un agent produit beaucoup de matière et aucun artefact durable. Les sources consultées, les pistes écartées, les conclusions intermédiaires restent dans un historique de conversation qui se perd au changement de contexte. llm-wiki prend le problème par l'autre bout : au lieu d'indexer un corpus existant, il compile le wiki à partir du travail de recherche lui-même. Le README résume la promesse en une phrase, « LLM-compiled knowledge bases for any AI agent », et la détaille en une chaîne d'opérations : capture d'idées brutes, recherche et mise en forme, puis promotion explicite de briefs approuvés vers des Projects de livraison. Le public visé est donc précis. Il s'agit de développeurs ou de chercheurs qui travaillent en solo ou en petite équipe sur quelques sujets suivis dans la durée, et qui utilisent déjà un agent en ligne de commande comme outil principal. Une personne qui cherche un moteur de recherche documentaire pour une base existante de plusieurs milliers de fichiers n'est pas la cible.

De la collecte à la compilation : ce que fait réellement la chaîne

Le dépôt expose deux notions structurantes. Les Ideas sont des notes brutes, les Projects des livrables. Entre les deux, une étape de promotion explicite : le README insiste sur le fait que les briefs approuvés sont promus « explicitly », ce qui signifie qu'aucune note ne devient un projet par simple accumulation. Le sous-commandes visibles dans le README dessinent le flux : `@wiki research` lance une investigation sur un sujet, `@wiki collect` alimente un catalogue de collecteurs avec un argument `--wiki` qui nomme la base cible, `@wiki ingest` prend une URL et l'intègre, `@wiki audit` contrôle un projet nommé. La compilation produit des fichiers Markdown, et le projet se déclare Obsidian-compatible : le format de sortie est donc du texte lisible par un humain, pas une base opaque. La version v0.18.0 a ajouté `/wiki:portfolio`, une vue en lecture seule qui liste séparément les Ideas canoniques et les Projects actifs, distingue les projets promus des projets créés directement, et conserve les Concepts comme connaissance de support. Le changelog précise que cette vue évite les topics fourre-tout, les enregistrements dupliqués, la lignée inférée et les caches périmés. C'est un choix de conception défendable : mieux vaut une vue partielle et fiable qu'une vue complète qui invente des liens.

Installer selon le runtime : trois chemins, trois niveaux d'intégration

Claude Code dispose du chemin le plus court, une commande unique : `claude plugin install wiki@llm-wiki`. Codex passe par un marketplace : `codex plugin marketplace add nvk/llm-wiki` puis `codex plugin add wiki@llm-wiki`. Le README fournit aussi un script de bootstrap pour un checkout local, `./scripts/bootstrap-codex-plugin.sh --scope user --verify`, et une variante manuelle avec un chemin absolu. La mise à jour se fait par `codex plugin marketplace upgrade llm-wiki` suivi de la réinstallation du plugin. OpenCode fonctionne différemment : il n'y a pas de plugin mais un fichier d'instructions déclaré dans `opencode.json`, avec une URL brute vers `SKILL.md` récupérée à chaque démarrage de session. Deux points méritent l'attention. D'abord, la distinction entre `$wiki-query` et `@wiki` : le premier est une compétence de lecture seule qui, selon le README, « never activates implicitly » et ne modifie jamais les fichiers du wiki, le second est le point d'entrée complet de recherche et de maintenance, susceptible d'être déclenché par du langage naturel. Ensuite, les hooks de session : ils ne sont pas nécessaires au fonctionnement de la compétence, et Codex demande de les examiner et de les approuver via `/hooks` si l'on veut la capture automatique. Refuser ce point coûte la mémoire de session, pas l'accès aux requêtes.

Adaptateurs privés : la partie qui ne se trouve pas dans le dépôt public

C'est le point le plus mal compris du projet, et le README y consacre plusieurs entrées de changelog. À partir de la v0.19.0, llm-wiki introduit un registre d'adaptateurs explicitement approuvés, locaux à la machine, avec un contrat JSON portable nommé `llm-wiki-adapter/v1`, des poignées de main par manifeste, des portées de chemins, des environnements nettoyés et des artefacts vérifiés par hachage. La v0.20.0 étend cela aux écritures distantes gouvernées : listes d'autorisation de ressources exactes, effets de lecture et d'écriture déclarés, approbation liée à un hachage de plan précis, clés d'idempotence et reçus privés. Puis la v0.21.3 annonce une transition : le matériel de workflow propre à un fournisseur est remplacé dans les sources actuelles par un routage piloté par manifeste et ne vit plus que dans l'adaptateur privé correspondant. La v0.22.0 ajoute que les adaptateurs enregistrés déclarent une intention neutre et des routes par URL exacte, et que le plugin public découvre la route avant l'ingestion sans embarquer l'authentification, le navigateur ou la récupération d'un fournisseur. Conséquence pratique : si vous lisez le dépôt public en espérant y trouver les recettes d'ingestion d'un site particulier, vous ne les trouverez pas. Le framework est public, les paquets de spécialistes personnels ne sont « not bundled or published ». Ce n'est pas une cachotterie, c'est une frontière assumée, mais elle déplace une partie du travail d'intégration vers vous.

Requêtes, profondeurs et mémoire de session

Le README liste plusieurs profondeurs de requête et un mode de recherche par thèse, sans détailler dans l'extrait fourni la sémantique exacte de chaque niveau. Je ne peux donc pas dire ce qui distingue concrètement une profondeur d'une autre, ni quel coût en appels de modèle chacune représente. Ce qui est documenté, en revanche, c'est la commande `@wiki feedback list --unpromoted`, qui liste les retours non encore promus, et `@wiki session status`, qui expose l'état de la mémoire de session. La désactivation existe aussi, via `@wiki session disable`, présentée comme un opt-out. Cette commande mérite d'être signalée : la capture de session est le mécanisme par lequel le wiki s'enrichit sans intervention manuelle, et c'est aussi celui qui écrit le plus de contenu dans votre espace de travail. La v0.24.3 s'intitule « Privacy-Sensitive Log Retraction », ce qui indique que la rétractation de journaux sensibles a été traitée comme un problème à part entière dans la ligne v0.24. Le changelog ne précise pas la portée exacte de cette rétractation dans l'extrait disponible, donc prudence : vérifiez dans le code ce qui est supprimé, ce qui est masqué et ce qui subsiste.

Checkpoints et exports : la gouvernance des écritures

La v0.24.0 ajoute l'export de checkpoints de connaissance sous `docs/knowledge/<slug>/`, avec création et rafraîchissement en dry-run d'abord, vérification en lecture seule et import borné. Le changelog mentionne une couverture exacte des sources et des sections, des omissions explicitement listées, une minimisation sémantique de la vie privée, un scellement déterministe, des dérogations attestées et une garde contre les sorties trop maigres. La phrase la plus importante de cette entrée est la dernière : « Checkpoint writes never authorize commit, publication, or import. » Autrement dit, produire un checkpoint n'engage rien. C'est une séparation nette entre génération et publication, et elle a un coût : quelqu'un doit relire et décider. Pour un usage individuel, cette lourdeur peut sembler disproportionnée. Pour un usage où le wiki alimente de la documentation publique, elle est cohérente avec le reste du projet, qui traite chaque écriture hors du wiki local comme une opération à approuver. La v0.24.2, « Safe Index Contract Repair », suggère par son titre qu'un contrat d'index a dû être réparé, ce qui rappelle que ces garanties sont récentes et que la ligne v0.24 a bougé vite.

Alternatives et cas où l'outil est le mauvais choix

L'alternative la plus directe n'est pas un autre plugin, c'est un pipeline maison : un dossier de notes Markdown, un script d'ingestion, et un index plein texte comme ripgrep ou un index de recherche locale. La différence d'approche est nette. Un pipeline maison vous laisse choisir le schéma, la granularité du découpage et la politique de mise à jour, et ne dépend d'aucun runtime d'agent. llm-wiki apporte à la place une structure de topics, une distinction Ideas/Projects, une vue portfolio et des modes de requête intégrés à l'agent. Vous payez cette structure en couplage : le wiki est compilé par un LLM, donc la qualité du corpus dépend du modèle utilisé et du prompt de compilation, deux paramètres que le projet ne fige pas. Le README note d'ailleurs que le profil OpenCode est « sync- and budget-tested, but not tied to one model ». C'est honnête et c'est aussi un avertissement : le comportement peut varier d'un modèle à l'autre. Autre limite : le projet est explicitement orienté topic unique par wiki, avec un argument `--wiki` pour nommer la base. Si votre besoin est de retrouver une phrase exacte dans un corpus de plusieurs milliers de PDF hétérogènes, un moteur d'indexation classique sera plus rapide à mettre en place et plus prévisible. Enfin, la dépendance à un fournisseur d'agent est réelle : les commandes diffèrent entre Claude Code, Codex et OpenCode, et le README traite séparément les problèmes de sandbox, par exemple le besoin d'accès lecture-écriture à `$HOME/.codex` lorsque Codex tourne sous `nono`.

Maintenance, licence et ce qu'il faut vérifier avant d'adopter

Le rythme de publication est élevé. Trois versions en cinq jours autour de la fin août 2026 (v0.24.2, v0.24.3, v0.24.4), et une ligne v0.24 qui a introduit les checkpoints, retiré des journaux sensibles et réparé un contrat d'index. Un tel rythme signifie deux choses : le projet est activement maintenu, et les détails d'API peuvent bouger entre deux mises à jour. La commande de mise à jour Codex réinstalle le plugin depuis le marketplace, ce qui vous place sur la dernière version par défaut plutôt que sur une version épinglée. Si vous intégrez llm-wiki dans un flux de travail reproductible, prévoyez de noter la version utilisée. La licence est MIT, ce qui autorise la réutilisation et la modification avec conservation de l'avis de licence ; je ne donne pas d'avis juridique au-delà de ce constat, et les implications dépendent de ce que vous redistribuez. Un dernier point de vérification : le README indique que le plugin public ne contient plus le matériel de workflow propre aux fournisseurs depuis la v0.21.3, et que les paquets de spécialistes personnels ne sont pas publiés. Avant de bâtir une chaîne d'ingestion sur ce dépôt, lisez le contrat `llm-wiki-adapter/v1` et vérifiez ce que vous devrez écrire vous-même.

Conclusion éditoriale

Adoptez llm-wiki si vous accumulez déjà des sessions d'agents sur un sujet unique et que vous voulez un corpus Markdown relisible hors de l'outil. Ne l'adoptez pas si vous cherchez un RAG clé en main sur des milliers de documents hétérogènes : le projet est orienté capture et compilation par topic, pas recherche vectorielle à grande échelle. Avant d'installer, vérifiez deux choses : la version exacte publiée sur le dépôt, car la ligne v0.21 a redistribué le matériel spécifique aux fournisseurs vers des adaptateurs privés, et le contenu de l'index après un premier `@wiki ingest`, puisque c'est ce fichier qui détermine ce que vos requêtes retrouveront réellement.

Sources officielles

1. License: MIT
2. nvk/llm-wiki on GitHub
3. Project website
4. README
5. Releases