karpathy-llm-wiki : un wiki markdown que l'agent entretient à votre place

Le problème visé : arrêter de reconstruire le contexte à chaque question

Le README pose la distinction de façon nette. Dans une approche RAG, la connaissance reste dans des fragments bruts et des embeddings, et la synthèse se produit au moment de la requête. Dans un LLM wiki, la connaissance vit dans des pages markdown curées, et la synthèse se produit pendant l'ingestion puis lors de la maintenance. Le projet cible donc un cas précis : un corpus personnel ou d'équipe assez stable pour qu'il vaille la peine d'écrire une page, mais assez vivant pour que les liens entre pages deviennent le vrai actif. Le public visé est celui qui utilise déjà Claude Code, Cursor ou Codex au quotidien et qui veut que son agent travaille sur un socle documentaire plutôt que de repartir de zéro à chaque échange. Le README résume la répartition des rôles ainsi : l'LLM tient le wiki, l'humain choisit les sources et pose les questions. C'est une répartition explicite, et elle implique que vous acceptez de ne plus éditer les pages à la main.

Trois opérations, une arborescence en deux dossiers

L'architecture tient dans deux répertoires. raw/ contient les sources, décrites comme immuables, rangées par sujet avec un nom de fichier daté du type 2026-04-03-source-article.md. wiki/ contient les pages compilées, également par sujet, plus deux fichiers transverses : index.md, table des matières globale, et log.md, journal d'opérations en ajout seul. Les trois opérations annoncées sont Ingest, Query et Lint. Ingest collecte une source dans raw/, la trie, puis crée ou met à jour les articles concernés, ou se contente de journaliser l'opération quand rien n'est nouveau. Query cherche dans le wiki et répond avec des citations pointant vers les pages markdown. Lint vérifie l'intégrité de l'index, les liens et la santé générale, avec correction automatique et signalement des problèmes restants. Le point intéressant est qu'une source peut toucher plusieurs pages et renforcer des liens croisés, ce qui est présenté comme le mécanisme qui fait composer le wiki dans le temps. Le README ne détaille pas le format exact des entrées de log.md ni la manière dont les contradictions sont enregistrées ; il indique seulement qu'elles peuvent l'être.

Installation et première ingestion

L'installation tient en une commande, reprise telle quelle dans le README : npx add-skill Astro-Han/karpathy-llm-wiki. Elle vaut pour Claude Code, Cursor et OpenCode. Pour Codex CLI, la documentation demande de copier le contenu dans .agents/skills/karpathy-llm-wiki/. Pour tout autre outil conforme au standard agentskills.io, il faut copier SKILL.md, references/ et scripts/ dans le répertoire de compétences de l'outil. L'usage se fait ensuite en langage naturel, pas en ligne de commande. Le README donne trois exemples : « Ingest this article: https://example.com/attention-is-all-you-need », puis « What do I know about attention mechanisms? », puis « Lint my wiki ». Les sources acceptées sont les pages web, les articles scientifiques, les billets de blog, les PDF, les fichiers markdown et texte, et le texte collé ; tout est converti en markdown sous raw/ avant compilation. Aucune clé de configuration n'apparaît dans le matériel fourni, et aucune release n'est répertoriée : vous installez donc l'état courant de la branche main.

Ce que le projet refuse de construire, et pourquoi c'est discutable

La section Design Boundaries est la plus intéressante du dépôt, parce qu'elle argumente ses refus. Pas de suivi de fraîcheur par hash des sources, au motif que raw/ est immuable et qu'un hash protégerait contre un événement impossible. Pas de citations persistées par numéro de ligne : le README affirme que chaque erreur de fidélité observée était du type « valeur absente de la source », qu'un grep sur le fichier entier attrape, et que l'annotation ralentit assez les agents pour qu'ils contournent la règle. Pas de scores numériques de confiance ou de qualité, qualifiés de fausse précision sans calibration. Pas de dates de revue par article, pas de décroissance fondée sur la fréquence d'accès, pas de machine à rétracter les mauvaises sources, pas de hooks ni d'exécutions planifiées, pas de recherche vectorielle ou de graphe, pas d'ontologie de relations typées. Sur ce dernier point, l'argument est que la sémantique d'un lien vit dans la prose qui l'entoure. Ces refus sont cohérents entre eux, mais ils déplacent la charge sur vous : sans hook ni planification, la maintenance ne se déclenche que si quelqu'un demande un lint. Et l'affirmation sur les erreurs de fidélité repose sur les journaux d'un seul mainteneur, ce que le README présente lui-même comme une observation, pas comme une mesure.

Le lint comme seul garde-fou, et ses angles morts

Puisque le projet écarte les dates de revue et les scores, toute la santé du wiki repose sur Lint : intégrité de l'index, liens cassés, références croisées périmées. C'est un choix défendable pour un wiki de quelques dizaines de pages, où une passe globale coûte peu. Il a une limite évidente : un lint détecte ce qui est structurellement incohérent, pas ce qui est devenu faux. Une page dont la source a été contredite par une publication plus récente restera valide au sens des liens et de l'index tant que personne ne l'ingère. Le README ne décrit aucun mécanisme de détection de contradiction automatique ; il indique que les sources peuvent enregistrer des contradictions, ce qui suppose que l'agent les repère au moment de l'ingestion. Autre angle mort : le README ne mentionne aucun test automatisé ni intégration continue dans le matériel fourni. La fiabilité du lint dépend donc de la qualité de SKILL.md et de scripts/, que vous devez lire avant de faire confiance au résultat.

Pourquoi pas un RAG, ou un wiki personnel classique

Le README oppose le modèle wiki au RAG sur trois axes : où vit la connaissance, quand la synthèse se fait, et à quoi chaque approche convient. Un RAG reste meilleur pour la récupération large sur de grands corpus, et le projet le reconnaît : la recherche vectorielle est écartée tant que le wiki tient dans 50K à 100K tokens, avec la consigne d'ajouter de l'outillage de recherche seulement quand le rappel se dégrade de façon mesurable. La différence pratique est donc une question de taille et de coût. Sur un petit corpus curé, un grep plus une lecture donnent un résultat traçable jusqu'à la page markdown, ce qu'un pipeline d'embeddings ne garantit pas sans travail supplémentaire. L'autre alternative citée est le wiki personnel ordinaire, qui dépend de l'édition manuelle. La différence n'est pas le format, c'est qui écrit : ici, l'agent met à jour résumés, liens et entrées d'index. Le corollaire est que vous perdez la main sur la formulation des pages, et que la qualité de ce que vous relisez dépend du modèle que vous branchez.

Coût de maintenance et licence

Le coût réel n'est pas dans le code mais dans les tokens consommés à chaque ingestion et à chaque lint, puisque l'agent lit et réécrit des pages markdown. Le README ne donne aucune estimation de ce coût. Il donne en revanche des chiffres d'usage attribués à une base maintenue quotidiennement depuis avril 2026 : 94 articles répartis dans 13 répertoires thématiques, 99 sources ingérées, 87 entrées de journal sur les sept derniers jours. Ces chiffres décrivent une base d'une personne, pas une charge d'équipe, et le dépôt ne publie ni release ni historique de versions permettant de juger la stabilité de l'API de la compétence. Le projet est sous licence MIT, ce qui autorise la réutilisation et la modification, y compris dans un contexte commercial, à condition de conserver l'avis de licence ; le dépôt ne contient pas de mention de garantie au-delà de ce que la MIT implique, et rien dans le matériel fourni ne précise la licence des exemples ou des sources ingérées. Pour un fork interne, la question à trancher est donc moins juridique que pratique : qui relit les pages quand l'agent se trompe.

Conclusion éditoriale

À adopter si vous accumulez déjà des sources markdown hétérogènes et voulez que l'agent tienne l'index, les liens croisés et le journal à votre place. À éviter si vous cherchez un moteur de recherche sémantique sur un gros corpus, ou si vous voulez des scores de confiance chiffrés : le README les refuse explicitement. Avant d'installer, ouvrez SKILL.md, references/ et scripts/ pour vérifier ce que l'agent exécute réellement sur vos fichiers, et testez l'ingestion sur une source unique avant de migrer une base existante.

Sources officielles

1. Astro-Han/karpathy-llm-wiki on GitHub
2. Issues
3. License: MIT
4. README