L’érosion par le bas, deux skills contre l’atrophie des compétences

Il y a quelque temps, @vinceflibustier a publié un fil qui décrit un métier que je n’exerce pas, et un mécanisme que je reconnais parfaitement. Il commence comme ça :

Un collègue vous envoie un rapport d’analyse…généré par IA.

Vous ne le lisez pas (soyons honnêtes, personne ne lit 34 pages un mardi à 15h). Vous le collez dans une IA pour avoir le résumé.

Puis vous demandez à la même IA de produire la synthèse que votre directeur vous a réclamée.

Vous relisez en diagonale, vous changez deux mots pour vous sentir utile, et hop, envoyé.

Le rapport de départ était déjà généré par une IA. Le directeur collera la synthèse dans une IA pour en avoir le résumé. D’où la conclusion du circuit :

Donc concrètement, on a deux machines qui discutent entre elles. Et au milieu, il y a vous. Un câble. Un câble en viande. Payé pour faire du ctrl+C / ctrl+V entre deux modèles de langage.

Ce qui rend le fil juste, ce n’est pas la formule. C’est ce qu’il en tire :

Perso, ce qui me fait peur ce n’est pas l’IA. C’est la vitesse à laquelle on accepte de devenir le tuyau. Parce qu’une fois que vous êtes juste un tuyau, la question que se pose votre boîte n’est plus « comment on le forme ? », c’est « pourquoi on paie le tuyau ? ».

Ce circuit, je le connais des deux bouts. Je développe, et je passe une bonne partie de mes journées dans un terminal. Mais je dirige aussi de la technique, ce qui veut dire recevoir des documents et des synthèses, en produire, en transmettre. Je n’en suis pas à la caricature du fil, et je ne crois pas y aller. Je travaille en revanche avec des gens à qui elle pourrait arriver, ce qui suffit à ne pas trouver la description exagérée.

Ce qui m’a surpris, c’est que la version qui me concernait le plus n’était pas celle-là. Elle était dans le terminal, et elle était mieux camouflée.

La version développeur, et son alibi

Le circuit tient en cinq temps.

Je formule une intention en langage naturel. L’agent produit un diff. Je ne lis pas le diff, je lance les tests. Les tests passent, je commite. Six mois plus tard, ce code casse en production. Je l’ouvre, je ne le reconnais pas, je le colle à l’agent en demandant pourquoi ça plante.

Deux machines discutent, l’agent et le code. Au milieu, quelqu’un qui appuie sur Entrée, puis sur « commit ».

La suite de tests verte est l’anesthésiant

Le col blanc du fil sait confusément qu’il n’a pas lu le rapport. Une gêne subsiste, même étouffée. Le développeur, lui, dispose d’une preuve objective que ça fonctionne : la suite est verte, la CI est au vert, le déploiement est passé.

Cette preuve est réelle. Elle n’est pas un artifice, elle atteste quelque chose de vrai sur le comportement du programme. Et elle ne dit strictement rien sur ce que j’ai compris.

C’est cette dissociation qui rend la version développeur du phénomène plus difficile à voir que celle du rapport de 34 pages. Le rapport n’a pas d’alibi. Le diff, si : il marche. On peut passer des mois à livrer du code fonctionnel qu’on ne saurait pas réécrire, et rien dans le tableau de bord ne clignote.

Déléguer et abdiquer ne se distinguent pas au moment de demander

Il serait commode de tracer la ligne à l’entrée : telle tâche se délègue, telle autre non. Ça ne marche pas. La même demande peut produire les deux résultats.

Demander à un agent de libérer un port occupé, c’est de la délégation saine : la tâche est mécanique, le temps gagné est réel, il n’y a aucune vertu à taper la commande soi-même. Ne pas savoir, le mois suivant, quelle commande il a lancée, c’est autre chose.

La différence ne se joue pas au moment de demander, mais au moment de recevoir. Ce n’est pas la délégation qui pose problème, c’est ce qu’on fait de la réponse : la lire, ou l’encaisser.

La compétence ne s’effondre pas, elle s’érode par le bas

On ne perd pas l’architecture d’un coup. Personne ne se réveille un matin incapable de concevoir un système.

On perd d’abord la syntaxe exacte d’un rebase interactif. Puis la raison pour laquelle tel flag existe dans la configuration. Puis la capacité à diagnostiquer une erreur sans la coller quelque part. Chaque perte est individuellement ridicule, et rationnellement acceptable : personne ne devrait mémoriser la syntaxe d’un rebase interactif, c’est exactement le genre de chose qu’une machine retient mieux que moi.

C’est le cumul qui coûte. Non pas parce que ces éléments valent quelque chose isolément, mais parce que c’est avec eux qu’on construit le jugement. Diagnostiquer, c’est reconnaître une forme déjà vue. Si rien n’a été vu, il n’y a rien à reconnaître.

La sortie de secours a un présupposé

Le fil ne se contente pas de décrire le problème, il indique l’issue :

Ce qui vous sauve, c’est le moment où vous vous arrêtez. Où vous vous demandez si le truc est vrai. S’il est pertinent. S’il répond vraiment à la question posée. Le moment où vous virez le paragraphe qui sonne bien mais qui ne veut rien dire. Le moment où vous dites « non, cette conclusion est fausse, moi j’y étais, sur le terrain, je connais le sujet ».

C’est juste, et c’est là que je bloque. Ce moment a un présupposé : que le terrain existe quelque part en vous.

On ne peut pas dire « moi j’y étais » d’un terrain où l’on n’est jamais allé. On ne peut pas contredire une IA sur un sujet qu’on lui a intégralement sous-traité. Le moment d’arrêt n’est pas un acte de volonté, c’est une conséquence : il survient parce qu’une connaissance résiste, parce que quelque chose ne colle pas avec ce qu’on sait. Si rien n’a été retenu, il n’y a rien qui résiste, et l’arrêt n’a pas lieu.

La suite de cet article raconte une tentative d’outiller ce moment-là. Pas de réduire l’usage des agents, ce serait absurde et je n’en ai aucune envie. De faire en sorte qu’il en reste quelque chose.

Un port occupé

Le déclencheur est dérisoire, et je tiens à ce qu’il le reste.

Un agent me signale qu’un port TCP est toujours occupé par un serveur de développement lancé plus tôt dans la journée, puis oublié. Il sait diagnostiquer et libérer le port en une commande. Il le fait. Le serveur redémarre. On passe à autre chose.

Je ne saurais pas le refaire seul le mois prochain.

Le constat qui a suivi n’est pas « j’aurais dû chercher moi-même ». J’ai bien fait de déléguer, c’est exactement le genre d’interruption qu’un agent doit absorber. Le constat est ailleurs : la connaissance a existé pendant trente secondes, dans une fenêtre de terminal, et elle a disparu avec la session.

Elle a été produite, elle était juste, elle m’était destinée, et il n’en reste rien. Ni la commande, ni surtout le modèle mental qui la justifie, à savoir qu’un port est tenu par un processus et non par un projet.

C’est à cette échelle que l’érosion se produit. Jamais sur les gros sujets, où l’on reste vigilant parce que l’enjeu est visible. Toujours sur les micro-résolutions qu’on ne juge pas dignes d’attention, et qui constituent l’essentiel d’une journée de travail.

Deux skills, et pourquoi deux

J’ai écrit deux skills. Comme le terme n’est pas universel, une définition avant tout le reste.

Un skill est un fichier SKILL.md. Il contient un frontmatter avec un nom et une description, et un corps en Markdown. La description n’est pas de la documentation : c’est elle que l’agent lit pour décider s’il doit activer le skill. Le corps, lui, est le prompt chargé dans l’agent au moment où le skill se déclenche.

Pas de code, pas de build, pas de dépendance. Un document qui contraint un comportement. On le dépose dans un dossier, il est utilisable.

/add-knowledge capture une connaissance acquise en session : une fiche ajoutée à un fichier thématique, plus une ligne dans un index global.

/check-knowledge interroge plus tard sur ces fiches, et tient à jour dans l’index un état de révision à trois niveaux, neuf, fragile, acquis, avec une date.

Le second existe parce que le premier ne suffit pas. Capturer sans jamais relire produit un dépotoir, pas une compétence. C’est exactement le piège que le fil décrit : un document que personne n’a lu en entier. Un vault de fiches jamais rouvertes est une bibliothèque d’ignorance bien rangée. J’aurais simplement déplacé le problème d’un terminal vers un dossier.

La destination est un vault Obsidian, parce que j’en tiens un depuis plusieurs années et que je n’allais pas m’en fabriquer un second. Mais rien dans les deux skills ne dépend d’Obsidian : ils lisent et écrivent des fichiers Markdown dans une arborescence. Les seules conventions empruntées sont les liens [[wiki]] et le frontmatter. Qui range ses notes autrement adaptera en changeant quelques lignes.

Les décisions de conception

C’est la partie qui m’a demandé le plus de discussion, et plusieurs arbitrages sont allés contre mon intuition de départ.

Quand déclencher la capture

Trois portes d’entrée plutôt qu’une. L’invocation explicite, quand je tape la commande ou demande de retenir quelque chose. La proposition spontanée, quand l’agent vient de résoudre un problème non trivial, de répondre à une question du type « comment on fait ça ? », ou constate que je bute une seconde fois sur la même chose. Et le bilan de fin de session, qui ramasse ce qui n’a pas été capturé en chemin.

La raison de la deuxième porte tient en une phrase : le moment où l’on est soulagé qu’un problème soit réglé est exactement celui où l’on pense le moins à le documenter. On veut revenir à ce qu’on faisait. Compter sur ma discipline à cet instant précis, c’est compter sur la seule chose qui vient de faire défaut.

Le coût est assumé : quelques propositions non pertinentes. Le skill est écrit pour proposer en une phrase et enchaîner immédiatement si la réponse est non. Un agent qui insiste devient un agent qu’on désactive.

Le bilan de fin de session est plafonné à dix candidats, et la liste sert à trier, pas à traiter en lot. Une liste de quarante items n’est pas une aide à la décision, c’est une raison de fermer la fenêtre.

Qui formule la connaissance

C’est le vrai nœud. Trois approches étaient possibles, et les trois se défendent.

L’agent rédige tout, je valide. C’est fluide, donc on capture beaucoup, et le volume compte. Mais la fiche est alors la compréhension de l’agent, pas la mienne. Dans trois semaines, l’interrogation portera sur des mots que je n’ai jamais prononcés. C’est l’interface de viande appliquée à ma propre mémoire : deux machines qui se parlent, mon vault et l’agent, et moi qui valide au milieu.

L’agent me fait reformuler avant d’écrire quoi que ce soit. Pédagogiquement, c’est la bonne réponse. Pratiquement, c’est le meilleur moyen de tuer l’outil : si chaque note demande un effort de rédaction, on cesse de noter. Et un outil qu’on n’utilise pas ne protège de rien.

L’agent écrit en silence. Aucune friction, capture maximale, et rien qui entre dans la tête. C’est un presse-papier avec une arborescence, pas un second cerveau.

Le compromis retenu répartit selon la nature de ce qui est écrit. L’agent rédige le corps technique, symptôme, diagnostic, cause, action, vérification, piège, parce que c’est du factuel et qu’il le fera plus exactement que moi. La liste de ces champs n’est pas fermée : il peut en nommer un autre quand aucun ne convient, mais le skill l’en dissuade, parce qu’un vocabulaire qui s’élargit produit des fiches qui ne se ressemblent plus. Mais il pose une seule question, sur la ligne « à retenir », le modèle mental, avec mes mots :

En une ou deux phrases, avec tes mots : qu’est-ce qu’il faut retenir de ça ?

Une question, pas un interrogatoire. Le skill précise explicitement de ne pas enchaîner. Et si ma reformulation contient une erreur, l’agent la corrige et signale la correction en une ligne sous la fiche, parce que c’est exactement là que l’apprentissage se joue.

Le raisonnement derrière tout ça : une fiche qu’on n’a pas formulée soi-même ne résout pas le problème, elle déplace l’ignorance dans un fichier.

Ce qui se passe quand je ne réponds pas

C’est le point du dispositif dont je suis le plus satisfait, et il tient en trois lignes du skill.

Si je ne réponds pas à la question, si je décline, ou si je réponds autre chose qu’une reformulation, l’agent n’insiste pas et ne repose pas la question. Il écrit la fiche quand même, avec la ligne « à retenir » de sa plume, explicitement marquée comme telle.

Et ce marquage a une conséquence : à la révision suivante, ces fiches remontent en priorité, avant même les autres fiches jamais révisées. Ce sont celles que je n’ai pas formulées, donc pas digérées.

Autrement dit, l’évitement est traité comme une donnée, pas comme un échec. Je n’ai pas voulu répondre : c’est légitime, j’étais pressé, ça arrive. Mais la faiblesse est enregistrée au lieu d’être masquée, et elle revient. C’est le seul endroit du dispositif qui fonctionne ainsi, et c’est probablement ce qui l’empêche de dériver vers la troisième approche, celle où l’agent écrit en silence.

Détail d’implémentation qui a son importance : ce marqueur n’est pas dans l’index, il est dans la fiche. Pour le voir, le skill de révision doit ouvrir des fichiers. Il le fait, mais avec un plafond, les quinze premières fiches neuf listées. Au-delà, il sélectionne sans le marqueur. Une priorisation qui exige de tout lire n’est pas une priorisation, c’est un scan.

Où vit l’état de révision

Dans l’index global, pas dans chaque fiche. Un seul fichier à relire pour décider quoi réviser, et un seul endroit à écrire après chaque question.

Trois niveaux et une date. Pas de courbe d’oubli, pas d’intervalles calculés, pas de facteur de facilité. Un seuil unique : une fiche acquis n’est réinterrogée qu’après plus de trente jours.

C’est volontairement rustique. Le vault est un endroit que j’ouvre aussi moi-même, à la main, pour lire mes notes. Un état de révision doit y rester compréhensible à l’œil nu. Le jour où l’état devient un calcul que seul l’agent sait interpréter, le dispositif est devenu une boîte noire de plus, et j’aurai reproduit le problème que je cherchais à traiter.

Les questions ne sont pas figées

Chaque fiche embarque une à trois paires question/réponse, rédigées au moment de la capture. Mais le skill d’interrogation s’autorise explicitement à ne pas s’y tenir : reformuler, demander le pourquoi plutôt que le comment, ou croiser deux fiches d’un même thème.

Sans ça, on mémorise la formulation de la question, pas la réponse. C’est le défaut classique des jeux de cartes figés : au bout de quelques passages, on reconnaît la carte avant de l’avoir lue.

Deux règles encadrent l’exercice : jamais la réponse dans l’énoncé, ni indice ni commande citée ; et si je sèche, l’agent donne la réponse complète. Une révision n’est pas un examen.

Une boucle de retour

Si je réponds faux parce que la fiche est confuse, incomplète ou datée, et non parce que j’ai oublié, le skill le dit et propose de la corriger, après validation.

C’est ce qui empêche la base de fossiliser une mauvaise explication. Une fiche fausse qu’on révise consciencieusement est pire que pas de fiche du tout : elle installe l’erreur.

C’est aussi la seule écriture que le skill d’interrogation s’autorise en dehors de l’index. Le reste du temps, il modifie exactement deux cellules par question, la date de révision et le niveau de maîtrise. Il ne réordonne rien, n’ajoute ni ne supprime de ligne.

Une contrainte d’architecture où le DRY ne s’applique pas

Les deux skills partagent des formats : le gabarit de fiche, celui de l’index. Chacune les recopie intégralement. Le lecteur qui parcourra l’annexe verra les mêmes blocs deux fois, ainsi que des plafonds chiffrés réénoncés en fin de fichier alors qu’ils figurent déjà plus haut.

C’est volontaire, et la raison tient à la manière dont un prompt est chargé. Un skill est chargé seul dans le contexte d’un agent. Il ne peut pas importer l’autre, il n’y a pas de résolution de dépendances, pas d’étape de build qui assemblerait des fragments. Factoriser les blocs communs dans un troisième fichier rendrait chaque skill incomplète à l’exécution : l’agent recevrait une référence vers quelque chose qu’il ne lira jamais.

La répétition en fin de fichier obéit à la même logique. Un prompt long se dilue : les instructions du milieu pèsent moins que celles de la fin. Réénoncer les contraintes critiques en clôture n’est pas une négligence de rédaction, c’est un choix de placement.

Le prix est réel, et il faut l’énoncer : toute évolution du format doit être répercutée des deux côtés, et rien ne détecte la dérive automatiquement. Pas de test, pas de compilateur, pas de lint. Deux fichiers texte qui doivent rester d’accord par la seule vigilance.

La démonstration n’a pas tardé : en relisant les deux fichiers pour écrire cet article, j’ai trouvé une définition partagée qui avait divergé d’une copie à l’autre. Elle est corrigée depuis. Mais elle a été trouvée à l’œil, en relecture, et rien n’aurait signalé qu’elle s’était mise à diverger.

La fabrication, et ce qu’elle a rattrapé

Les deux skills ont été produites par un cycle : conception dialoguée, puis spécification écrite, puis plan d’implémentation, puis exécution par des sous-agents, avec une revue indépendante après chaque étape et une revue finale de l’ensemble.

Il y a une ironie et je ne vais pas la contourner : j’ai écrit un outil contre la délégation aveugle en déléguant l’écriture à des agents.

La réponse tient dans la différence entre les deux situations. Chaque diff a été relu par un agent indépendant du premier et arbitré par moi, y compris quand les deux agents étaient en désaccord, chaque décision étant consignée. Ce n’est pas du ctrl+C / ctrl+V.

Mais c’est une nuance à défendre, pas à décréter. Un dispositif de revue peut très bien devenir un rituel : on ouvre le rapport, on voit « aucun problème bloquant », on valide. La différence n’est pas dans l’existence de la revue, elle est dans le fait de trancher soi-même les conflits, ce qui suppose d’avoir compris les deux positions. C’est le même critère que plus haut : la délégation ne pose pas problème, ce qu’on fait de la réponse, si.

Le passage le plus instructif est celui-ci : les revues ont trouvé deux défauts qui échappaient au protocole de vérification prévu par le plan lui-même.

Une règle de sécurité définie par le mauvais critère

Le vault contient des notes que j’ai écrites moi-même, avant tout ça, et qui n’ont rien à voir avec le format des fiches. La règle qui les protège était formulée par l’emplacement : sont en lecture seule les notes rangées dans des sous-dossiers.

Or le vault contenait deux cas que cette formulation ne couvrait pas. Une note posée à la racine, et un fichier Markdown situé exactement là où un fichier thématique se serait trouvé. Ni l’un ni l’autre n’était protégé. Un agent pouvait légitimement écrire dedans, en respectant la règle à la lettre.

La correction a remplacé le critère d’emplacement par un critère vérifiable : est un fichier thématique celui dont le nom est le titre d’une section de l’index, ou celui que l’agent crée lui-même. Tout autre fichier Markdown du vault est une note préexistante, en lecture seule.

Le défaut de la première version n’était pas d’être fausse, mais de décrire une intention plutôt qu’un test. « Rangée dans un sous-dossier » suppose que l’organisation reflète le statut. Elle ne le reflétait pas.

Un bug protégé par son propre test

Celui-ci est plus retors, et c’est celui qui vaut d’être raconté.

Aucune des deux skills ne disait à l’agent d’aller chercher la date du jour. Le seul repère disponible était la date figurant dans les exemples du gabarit. Un agent pouvait donc parfaitement la recopier au lieu de la calculer, et il n’aurait rien fait d’illégitime : c’est le seul modèle qu’on lui donnait.

Le test de validation prévu par le plan devait tourner le jour même où ces exemples avaient été écrits. Il serait donc passé parfaitement. Vert, sans réserve, sur un comportement faux.

Le bug ne serait apparu qu’à la deuxième session, et pas sous forme d’erreur. Sous forme de dates fausses dans le fichier qui décide quoi réviser. Une fiche marquée révisée hier alors qu’elle ne l’a jamais été, un seuil de trente jours calculé sur une date inventée. Une corruption silencieuse de l’état, dans un dispositif dont l’état est la seule chose qui compte.

La correction est banale : les deux skills disent maintenant, à trois endroits chacune, que la date s’obtient avec date +%F et ne se recopie ni du gabarit ni de mémoire. Ce qui est intéressant n’est pas la correction, c’est la manière dont le défaut se cachait.

Ce que ces deux cas ont en commun

C’est peut-être la conclusion la plus transportable de tout ça : un protocole de test rédigé en même temps que la chose qu’il vérifie hérite de ses angles morts.

Le plan connaissait la règle « les sous-dossiers sont protégés », donc il a vérifié que les sous-dossiers étaient protégés. Le plan avait sous les yeux un gabarit daté du jour, donc il a prévu un test qui tournait ce jour-là. Dans les deux cas, le test valide la représentation que l’auteur se fait du problème, pas le problème.

C’est vrai d’un humain qui travaille seul. C’est plus vrai encore quand la même session produit le code, le plan et le test, parce que rien n’introduit d’écart entre les trois. Ce qui a rattrapé ces deux défauts n’est pas la rigueur du protocole, c’est le fait qu’un relecteur n’ayant pas participé à sa rédaction soit passé derrière.

Ce que ça ne fait pas

Il faut lister ça honnêtement, plutôt que de conclure sur une victoire.

Les deux skills n’ont pas été éprouvées en usage réel. Elles viennent d’être écrites. Ce que vous venez de lire est un raisonnement de conception et un compte rendu de revue, pas un retour d’expérience. Le premier vrai contact avec l’usage corrigera probablement des choses que je crois solides.

Il n’existe aucune donnée sur l’efficacité pédagogique du dispositif. L’hypothèse « faire reformuler aide à retenir » est un pari raisonnable, appuyé sur des méthodes anciennes et documentées. Ce n’est pas un résultat que j’aurais mesuré, et je ne le présente pas autrement.

Un troisième skill serait nécessaire, pour reprendre et compléter d’anciennes notes qui n’ont pas le format attendu. Il n’existe pas. En attendant, ces notes sont en lecture seule, et le mécanisme se contente de pouvoir les faire réviser sans jamais y toucher.

Et le dispositif ne protège de rien si on ne l’utilise pas. C’est le problème connu de cette famille d’outils : proposer un remède à l’érosion de la discipline qui exige de la discipline. Les propositions spontanées et le bilan de fin de session sont là pour réduire la dépendance à ma volonté, pas pour l’annuler. Je n’ai aucune raison de croire que ça suffira, et je le saurai dans quelques mois.

Ce qu’on pourrait y mettre d’autre

Le cas du port occupé est celui qui a déclenché tout ça. On peut en imaginer d’autres, du même calibre, que je n’ai pas encore capturés :

• La syntaxe exacte d’un rebase interactif, celle qu’on refait chercher tous les six mois avec la même hésitation sur l’ordre des arguments.
• La différence entre deux mécanismes d’authentification qu’on reconfond à chaque intégration, parce qu’on les configure une fois par an.
• La raison d’être d’un flag de compilation hérité, présent dans un projet depuis si longtemps que plus personne ne sait ce qu’il empêche de casser.

Ce sont trois exemples imaginés, pas des fiches existantes. Ils ont en commun d’être trop petits pour qu’on décide d’y consacrer un effort d’apprentissage, et assez fréquents pour que leur absence coûte, année après année, plus cher que ce que leur capture aurait coûté.

Ce que je vise, au fond

Je ne cherche pas à déléguer moins. Je délègue beaucoup, ça marche, et je n’ai pas l’intention de revenir en arrière par principe.

Ce que je cherche à préserver, c’est la capacité à dire « non, cette conclusion est fausse ». Elle ne se décrète pas au moment où on en a besoin. Elle se constitue avant, par petits dépôts, à des moments où elle ne sert à rien et où rien n’oblige à s’arrêter.

Deux fichiers Markdown ne garantissent pas ça. Mais ils rendent le dépôt possible, et ils obligent à y revenir. C’est un objectif modeste, à la mesure du problème qui l’a déclenché : un port occupé, un mardi après-midi.

Annexe : les deux fichiers

Un skill n’est rien d’autre que ce fichier. Déposer le premier dans skills/add-knowledge/SKILL.md et le second dans skills/check-knowledge/SKILL.md suffit à les rendre utilisables : il n’y a rien à compiler, rien à installer, aucune dépendance.

Une seule ligne est à éditer dans chaque fichier avant usage : le chemin du dossier cible, marqué <CHEMIN_VERS_TON_VAULT>/Connaissances, à remplacer par le chemin réel de votre vault. Tout le reste fonctionne tel quel.

Les répétitions que vous allez voir, gabarits dupliqués entre les deux fichiers, plafonds chiffrés réénoncés en clôture, sont les choix de conception expliqués plus haut. Ne les factorisez pas.

skills/add-knowledge/SKILL.md

---
name: add-knowledge
description: À utiliser pour capturer dans le vault Obsidian une connaissance acquise pendant une session — méthode de résolution d'un problème, commande utile, notion mal maîtrisée — sous forme de fiche thématique interrogeable plus tard. Déclenche ce skill quand l'utilisateur tape « /add-knowledge », ou demande de « noter ça », « retenir ça », « ajouter cette connaissance ». Propose-le aussi spontanément, sans qu'on te le demande, juste après avoir résolu un problème non trivial, répondu à une question du type « comment on fait ça ? », ou constaté que l'utilisateur bute une seconde fois sur la même chose — et lors d'un bilan de fin de session, pour ramasser ce qui n'a pas été capturé en chemin.
---

# Add Knowledge

Tu transformes une résolution en apprentissage.

Quand un problème est résolu au cours d'une session, la connaissance disparaît avec elle : ni la commande, ni le modèle mental qui la justifie ne survivent. Ton rôle est de fixer cette connaissance dans le vault Obsidian de l'utilisateur — mais surtout de la lui faire **formuler**, parce qu'une fiche qu'il n'a pas écrite ne fait que déplacer son ignorance dans un fichier.

## Emplacement

Dossier cible, fixe :

```
<CHEMIN_VERS_TON_VAULT>/Connaissances
```

Le chemin contient des espaces : cite-le systématiquement en shell.

**S'il est absent, arrête-toi et dis-le.** Ne crée jamais cette arborescence ailleurs, ne devine pas un autre vault.

Structure :

```
Connaissances/
  _INDEX.md                    <- sommaire + état de révision
  Une note.md               <- note préexistante à la racine, LECTURE SEULE
  Développement/
    Réseau.md                  <- fichier thématique incrémental
    GIT/                       <- notes préexistantes, LECTURE SEULE
  IA/
  Prise de notes/
    Une autre note.md     <- note préexistante, LECTURE SEULE
```

**Tu n'écris que dans `_INDEX.md` et dans les fichiers thématiques.** Un **fichier thématique** est un fichier vers lequel pointe le lien du **titre** d'une section `##` de `_INDEX.md` (ces titres ont la forme `## Thème / [[Chemin/Fichier]]`), ou que tu crées toi-même. Le titre de la section « Notes autonomes » ne contient aucun lien : les fichiers listés dans son tableau restent des notes préexistantes. **Tout autre `.md` du vault est une note préexistante, en lecture seule** — y compris les `.md` posés à la racine de `Connaissances/` (`Une note.md`) ou directement dans un dossier de thème (`Prise de notes/Une autre note.md`). Dans le doute, demande.

Les notes préexistantes sont référençables depuis l'index, jamais modifiées. Les reformater est le travail d'un autre skill.

## Quand te déclencher

Trois portes d'entrée, un seul parcours ensuite.

1. **Invocation explicite** — l'utilisateur tape `/add-knowledge` ou te demande de retenir quelque chose.
2. **Proposition spontanée** — tu proposes toi-même la capture, en une phrase, quand :
   - un problème non trivial vient d'être résolu (une erreur diagnostiquée, une commande trouvée après tâtonnement) ;
   - l'utilisateur a posé une question du type « comment on fait ça ? » et a obtenu sa réponse ;
   - il bute une seconde fois sur quelque chose de déjà rencontré.

   Propose, n'impose pas : une phrase, et tu enchaînes si la réponse est non.
3. **Bilan de fin de session** — quand l'utilisateur clôt la session, liste les connaissances candidates repérées en chemin. **10 candidats maximum.** La liste sert à trier ; elle n'autorise pas le traitement en lot.

## Méthode

Pour chaque connaissance, dans cet ordre :

1. **Isole une connaissance.** Une seule. En mode bilan, présente d'abord la liste numérotée, laisse l'utilisateur choisir, puis traite ses choix un par un.

2. **Lis `_INDEX.md`** avant toute autre chose. Il te donne les thèmes existants et te permet de détecter un doublon. Si une fiche proche existe déjà, **propose de l'enrichir** plutôt que d'en créer une seconde — et dis laquelle.

3. **Pose la question de reformulation.** Une seule, exactement dans cet esprit :

   > En une ou deux phrases, avec tes mots : qu'est-ce qu'il faut retenir de ça ?

   C'est le cœur du skill. N'en pose pas d'autres, n'enchaîne pas sur un interrogatoire.

   Si l'utilisateur ne répond pas, décline, ou répond par autre chose qu'une reformulation, n'insiste pas et ne repose pas la question : rédige un `À retenir` de ta plume, marqué `_(rédigé par l'agent)_`, et signale-le dans la ligne de confirmation finale.

   **En enrichissement, ne pose pas cette question** : le `À retenir` de la fiche existante reste tel quel. Une fiche n'a qu'un seul `À retenir`.

4. **Rédige la fiche** au gabarit ci-dessous.

   **Nouvelle fiche** :
   - le `À retenir` reprend la formulation de l'utilisateur. Si elle contient une erreur, corrige-la **et signale la correction explicitement** sous la fiche, en une ligne — c'est là que l'apprentissage se joue ;
   - le corps technique (symptôme, diagnostic, commandes, vérification, piège) est de ta plume : c'est du factuel, autant qu'il soit exact ;
   - rédige 1 à 3 paires Q/R de révision.

   **En enrichissement**, tu ne rédiges que ce qui s'ajoute : le complément de corps technique, de ta plume, et les paires Q/R nouvelles. Le `À retenir` et la ligne de contexte d'origine restent tels quels — les limites d'écriture sont à l'étape 6.

5. **Présente la fiche entière** et attends la décision : valider, corriger, annuler.

6. **Écris**, uniquement si validé.

   **Nouvelle fiche** :
   - ajoute la section **à la fin** du fichier thématique. Ne réordonne rien : l'index est la vue navigable ;
   - crée le fichier thématique s'il n'existe pas, avec son frontmatter ;
   - ajoute la ligne d'index, maîtrise `neuf`.

   **En enrichissement** : complète la section existante (ajoute au corps technique, ajoute des paires Q/R sans dépasser 3 au total), sans réécrire le `À retenir` ni la ligne de contexte d'origine. **N'ajoute pas de ligne d'index** — elle existe déjà ; ne touche ni à `Capturée`, ni à `Revue`, ni à `Maîtrise`. Signale-le à l'utilisateur : la fiche a changé, sa maîtrise enregistrée ne reflète plus tout à fait son contenu.

7. **Confirme en une ligne** : titre de la fiche et fichier de destination — le chemin du fichier porte déjà le thème.

## Choix du thème

Réutilise un fichier thématique existant dès qu'il convient. N'en crée un nouveau que si aucun ne correspond clairement **et** que le sujet justifie un regroupement (au moins 2-3 fiches attendues à terme). Sinon, place la fiche dans le fichier thématique existant le plus proche — un **fichier thématique** au sens ci-dessus, jamais une note préexistante.

Créer un **nouveau dossier de thème racine** demande l'accord explicite de l'utilisateur.

Respecte les conventions du vault : accents et espaces dans les noms (`Développement`, `Prise de notes`), tags hiérarchiques (`Dev/Réseau`).

## Gabarit de fiche

```markdown
---
Titre: Réseau
Tags:
  - Dev/Réseau
Créée le: 2026-08-27
---

# Réseau

## Libérer un port TCP occupé

**À retenir** — Un port est tenu par un *processus*, pas par un projet.
Tant que le process tourne, le port reste pris, même si j'ai fermé
l'onglet et oublié le projet.

**Symptôme** — `address already in use` au démarrage du serveur.
**Diagnostic** — `lsof -i :8791` → PID + nom du process.
**Action** — `kill <PID>`, puis `kill -9 <PID>` s'il résiste.
**Vérification** — `lsof -i :8791` ne renvoie plus rien.
**Piège** — si un watcher relance le serveur, le port se rouvre aussitôt :
couper le watcher d'abord.

**Révision**
- Q — Quelle commande donne le processus qui tient le port 8791 ?
  R — `lsof -i :8791`
- Q — Pourquoi un port peut-il rester pris après avoir fermé le projet ?
  R — Le process tourne toujours ; le port appartient au process.

_Capturée le 2026-08-27 — contexte : serveur PHP d'un projet local._
```

Règles de format :

- Le frontmatter est **au niveau du fichier thématique**, pas de la fiche. Tu ne l'écris qu'à la création du fichier.
- Une fiche = une section `##`. **Son titre est unique dans le fichier** : c'est l'ancre de lien. Si le titre existe déjà, c'est un doublon : n'ouvre pas une seconde section, complète la section existante par le parcours d'enrichissement.
- `**À retenir**` est en tête et **obligatoire**.
- `Symptôme`, `Diagnostic`, `Cause`, `Action`, `Vérification`, `Détail`, `Piège` sont **facultatifs**. Une connaissance conceptuelle garde `À retenir`, une explication et `Révision`. **N'écris jamais un champ vide.** La liste n'est pas fermée : si aucun de ces sept noms ne convient à la connaissance, tu peux en nommer un autre — un ou deux mots, en gras, suivis d'un tiret cadratin, comme les autres. N'en invente un que par nécessité, pas par confort : plus le vocabulaire s'élargit, moins les fiches se ressemblent.
- `Révision` : 1 à 3 paires, format `- Q — …` puis `  R — …`.
- La ligne finale en italique rappelle la date et le contexte d'origine. Le frontmatter `Créée le` et cette date sont au format `AAAA-MM-JJ`, obtenu avec `date +%F`.
- Si l'utilisateur n'a pas répondu à la question de reformulation, a refusé d'y répondre, ou a répondu par autre chose qu'une reformulation, écris `**À retenir** — _(rédigé par l'agent)_ …`.

## Gabarit d'index

`Connaissances/_INDEX.md` :

```markdown
# Index des connaissances

_Maintenu par /add-knowledge et /check-knowledge. Une ligne = une fiche._

## Développement / [[Développement/Réseau]]

| Connaissance | Capturée | Revue | Maîtrise |
| --- | --- | --- | --- |
| [[Développement/Réseau#Libérer un port TCP occupé]] | 2026-08-27 | — | neuf |

## Notes autonomes (hors système, en lecture seule)

| Note | Revue | Maîtrise |
| --- | --- | --- |
| [[Développement/GIT/Une note importée]] | — | neuf |
```

Règles :

- **Liens sans alias dans les tableaux.** `[[cible]]`, jamais `[[cible|libellé]]` : le `|` serait lu comme un séparateur de colonne et casserait la cellule. C'est l'erreur la plus facile à commettre ici.
- Une section `##` par fichier thématique, sections dans l'ordre alphabétique.
- Maîtrise à la création : toujours `neuf`. Colonne `Revue` : `—`.
- Les dates sont au format `AAAA-MM-JJ`, valeur absente `—`. **Obtiens la date du jour avec `date +%F` — ne la recopie pas du gabarit et ne l'écris pas de mémoire.**
- Les colonnes `Revue` et `Maîtrise` appartiennent à `/check-knowledge`. Tu les initialises, tu ne les fais pas évoluer.
- Crée `_INDEX.md` avec son en-tête s'il n'existe pas.
- Le tableau « Notes autonomes » sert à faire réviser les notes préexistantes. Tu n'y ajoutes une ligne **qu'à la demande explicite de l'utilisateur**, jamais spontanément : aucune étape de la méthode n'y conduit. La ligne se crée avec `Revue` à `—` et maîtrise `neuf`, et n'entraîne **aucune écriture dans la note elle-même**.

## Contraintes

- **Une connaissance à la fois.** Pas de batch, même en mode bilan.
- **N'invente rien.** Ne documente que ce qui a réellement eu lieu dans la conversation. Une commande qui n'a pas été exécutée est signalée comme non vérifiée, ou tu demandes.
- **Aucune écriture sans validation explicite.**
- Ne modifie jamais une note préexistante.
- N'efface jamais une fiche. Enrichir ≠ remplacer.
- Si le vault est absent ou inaccessible, arrête-toi et dis-le.

## Sortie obligatoire

Réponds en français. Avant d'écrire une fiche, présente exactement ce bloc :

---

**Connaissance** : _titre de la fiche_
**Fichier** : `Développement/Réseau.md` _(existant / **nouveau**)_
**Nouveau dossier de thème racine** : `Nom du dossier/` — **ton accord explicite est requis** _(cette ligne uniquement s'il faut en créer un)_
**Action** : nouvelle fiche / enrichissement de « _titre existant_ »

```markdown
_la fiche complète, au gabarit_
```

_Correction apportée à ta formulation_ : _(une ligne, uniquement s'il y en a une)_

→ **Valider, corriger ou annuler ?**

---

Avant d'inscrire une note préexistante au tableau « Notes autonomes » — à la demande explicite de l'utilisateur uniquement — présente exactement ce bloc, plus court :

---

**Note préexistante** : `Développement/GIT/Une note importée.md`
**Action** : inscription au tableau « Notes autonomes » de `_INDEX.md` — aucune écriture dans la note

`| [[Développement/GIT/Une note importée]] | — | neuf |`

→ **Valider, corriger ou annuler ?**

---

Après écriture, une seule ligne de confirmation.

Nouvelle fiche :

`✓ « Libérer un port TCP occupé » → Développement/Réseau.md — index à jour (neuf)`

Si le `À retenir` est de ta plume, ajoute ` — À retenir rédigé par l'agent` en fin de ligne.

Enrichissement :

`✓ « Libérer un port TCP occupé » complétée → Développement/Réseau.md — aucune ligne d'index ajoutée, maîtrise inchangée (elle ne reflète plus tout à fait la fiche)`

## Règle finale

**Une connaissance à la fois. 10 candidats maximum en bilan de fin de session.** Tu poses **une seule** question de reformulation. Tu n'écris rien sans validation explicite. Tu n'écris que dans `_INDEX.md` et dans les fichiers thématiques : tu ne touches jamais aux notes préexistantes. En enrichissement, tu n'ajoutes **aucune** ligne d'index. Les dates viennent de `date +%F`, jamais du gabarit. Dans les tableaux de l'index, les liens sont **sans alias**.

skills/check-knowledge/SKILL.md

---
name: check-knowledge
description: À utiliser pour interroger l'utilisateur sur les connaissances capturées dans son vault Obsidian et vérifier ce qu'il a réellement retenu. Déclenche ce skill quand il tape « /check-knowledge », ou demande « interroge-moi », « teste-moi », « fais-moi réviser », « est-ce que j'ai retenu ? » — éventuellement en précisant un thème (« interroge-moi sur le réseau ») ou un nombre de questions. Ne le déclenche pas de toi-même : réviser se décide, ça ne s'impose pas au milieu d'un travail.
---

# Check Knowledge

Tu vérifies ce que l'utilisateur a réellement retenu — pas ce qui est écrit dans son vault.

Une fiche relue n'est pas une fiche sue. Ton rôle est de poser des questions dont la réponse ne se trouve pas sous les yeux, d'évaluer sans complaisance, et de tenir à jour ce qui est acquis et ce qui glisse.

## Emplacement

Dossier cible, fixe :

```
<CHEMIN_VERS_TON_VAULT>/Connaissances
```

Le chemin contient des espaces : cite-le systématiquement en shell.

**S'il est absent, ou si `_INDEX.md` n'existe pas, arrête-toi et dis-le** — il n'y a rien à réviser, et c'est `/add-knowledge` qui crée l'index.

## Session

Par défaut **10 questions, une à la fois**. L'utilisateur peut préciser :
- un **thème** (« interroge-moi sur le réseau ») → restreins la sélection à ce fichier thématique. Si le thème nommé est un **dossier racine** (« interroge-moi sur le développement »), restreins-la à tous les fichiers thématiques qu'il contient. Si le nom est ambigu, demande lequel des deux ;
- un **nombre** (« 3 questions ») → respecte-le ;
- **arrêter en cours de route** → le récapitulatif porte alors sur les questions déjà posées.

S'il reste moins de fiches disponibles que de questions demandées, dis-le et pose ce qu'il y a. Ne repose pas deux fois la même fiche dans une session.

## Méthode

1. **Lis `_INDEX.md`** et sélectionne les fiches à demander, dans cet ordre de priorité :
   1. maîtrise `neuf` (jamais révisée, ou remise à zéro après une réponse fausse) — et parmi elles, d'abord celles dont le `À retenir` est marqué `_(rédigé par l'agent)_` : ce sont celles que l'utilisateur n'a pas formulées, donc pas digérées. Ce marqueur n'est pas dans l'index : pour le voir, ouvre les fiches `neuf` — elles seules, pas tout le vault, et **au plus les 15 premières listées dans l'index**. Au-delà, sélectionne sans le marqueur ;
   2. maîtrise `fragile` ;
   3. maîtrise `acquis` dont la colonne `Revue` date de **plus de 30 jours**.

   Si les trois catégories sont vides, dis-le : tout est à jour, il n'y a rien à réviser.

2. **Lis la fiche** correspondante dans son fichier thématique, pour toi seul.

   Si la ligne vient du tableau **« Notes autonomes »**, il ne s'agit pas d'une fiche : lis la note préexistante en entier. Elle n'a ni gabarit, ni `À retenir`, ni bloc `Révision`.

3. **Pose la question sans afficher la fiche.** Pars des paires Q/R du bloc `Révision`, mais ne t'y enferme pas : reformule, demande le *pourquoi* plutôt que le *comment*, ou croise deux fiches d'un même thème. Sinon l'utilisateur mémorise la formulation de la question, pas la réponse.

   Pour une **note autonome**, il n'y a pas de Q/R préparées : formule toi-même la question à partir de ce que tu viens de lire, sur ce que la note a de central. Une seule, comme pour une fiche.

   **Ne donne jamais la réponse dans l'énoncé.** Pas d'indice, pas de commande citée, pas de choix multiple sauf s'il le demande.

4. **Attends la réponse.** Une question à la fois. N'enchaîne pas.

5. **Évalue** en comparant à la fiche : ce qui est juste, ce qui manque, ce qui est faux. Factuel, sur la réponse — jamais sur la personne. S'il sèche, donne la réponse complète : une révision n'est pas un examen.

6. **Mets à jour l'index** :

   | Réponse | Nouvelle maîtrise |
   | --- | --- |
   | juste et complète | `acquis` |
   | approximative ou partielle | `fragile` |
   | fausse, ou « je ne sais pas » | `neuf` |

   Plus la date du jour dans la colonne `Revue`. Une fiche `acquis` répondue faussement redescend donc à `neuf`.

7. **Boucle de retour.** Si la réponse était fausse *parce que la fiche est confuse, incomplète ou datée* — pas parce qu'il a oublié — dis-le et propose de la corriger. **Attends sa validation avant d'écrire quoi que ce soit dans la fiche.** C'est ce qui empêche le vault de fossiliser une mauvaise explication. La correction respecte le gabarit de fiche ci-dessous.

   **Une note autonome n'est jamais corrigée**, même avec validation : signale la faiblesse à l'utilisateur et n'y touche pas. La reformater est le travail d'un autre skill.

8. **Enchaîne** la question suivante.

## Gabarit de fiche

Tu ne rédiges pas de fiche, mais l'étape 7 t'autorise à en corriger une. Le format ci-dessous est celui de `/add-knowledge`, reproduit à l'identique : une correction s'y conforme.

```markdown
---
Titre: Réseau
Tags:
  - Dev/Réseau
Créée le: 2026-08-27
---

# Réseau

## Libérer un port TCP occupé

**À retenir** — Un port est tenu par un *processus*, pas par un projet.
Tant que le process tourne, le port reste pris, même si j'ai fermé
l'onglet et oublié le projet.

**Symptôme** — `address already in use` au démarrage du serveur.
**Diagnostic** — `lsof -i :8791` → PID + nom du process.
**Action** — `kill <PID>`, puis `kill -9 <PID>` s'il résiste.
**Vérification** — `lsof -i :8791` ne renvoie plus rien.
**Piège** — si un watcher relance le serveur, le port se rouvre aussitôt :
couper le watcher d'abord.

**Révision**
- Q — Quelle commande donne le processus qui tient le port 8791 ?
  R — `lsof -i :8791`
- Q — Pourquoi un port peut-il rester pris après avoir fermé le projet ?
  R — Le process tourne toujours ; le port appartient au process.

_Capturée le 2026-08-27 — contexte : serveur PHP d'un projet local._
```

Règles de format :

- Le frontmatter est **au niveau du fichier thématique**, pas de la fiche. Tu ne l'écris qu'à la création du fichier.
- Une fiche = une section `##`. **Son titre est unique dans le fichier** : c'est l'ancre de lien. Si le titre existe déjà, c'est un doublon : n'ouvre pas une seconde section, complète la section existante par le parcours d'enrichissement.
- `**À retenir**` est en tête et **obligatoire**.
- `Symptôme`, `Diagnostic`, `Cause`, `Action`, `Vérification`, `Détail`, `Piège` sont **facultatifs**. Une connaissance conceptuelle garde `À retenir`, une explication et `Révision`. **N'écris jamais un champ vide.** La liste n'est pas fermée : si aucun de ces sept noms ne convient à la connaissance, tu peux en nommer un autre — un ou deux mots, en gras, suivis d'un tiret cadratin, comme les autres. N'en invente un que par nécessité, pas par confort : plus le vocabulaire s'élargit, moins les fiches se ressemblent.
- `Révision` : 1 à 3 paires, format `- Q — …` puis `  R — …`.
- La ligne finale en italique rappelle la date et le contexte d'origine. Le frontmatter `Créée le` et cette date sont au format `AAAA-MM-JJ`, obtenu avec `date +%F`.
- Si l'utilisateur n'a pas répondu à la question de reformulation, a refusé d'y répondre, ou a répondu par autre chose qu'une reformulation, écris `**À retenir** — _(rédigé par l'agent)_ …`.

## Gabarit d'index

C'est le fichier que tu lis pour choisir, et le seul que tu écris de ta propre initiative. La **seule autre** écriture autorisée est la correction d'une fiche, à l'étape 7, après validation explicite. Une note préexistante n'est jamais écrite, même validée.

```markdown
# Index des connaissances

_Maintenu par /add-knowledge et /check-knowledge. Une ligne = une fiche._

## Développement / [[Développement/Réseau]]

| Connaissance | Capturée | Revue | Maîtrise |
| --- | --- | --- | --- |
| [[Développement/Réseau#Libérer un port TCP occupé]] | 2026-08-27 | — | neuf |

## Notes autonomes (hors système, en lecture seule)

| Note | Revue | Maîtrise |
| --- | --- | --- |
| [[Développement/GIT/Une note importée]] | — | neuf |
```

Tu modifies **une cellule `Revue` et une cellule `Maîtrise`** par question, rien d'autre. Tu ne réordonnes pas les lignes, tu n'en ajoutes pas, tu n'en supprimes pas.

## Sortie obligatoire

Réponds en français.

Pour poser une question :

---

**Question 3/10** — _Développement / Réseau_

_l'énoncé, sans indice_

---

Après la réponse de l'utilisateur :

---

**Verdict** : juste / approximatif / faux

_Ce qui était juste_ : _(une ligne)_
_Ce qui manquait_ : _(une ligne, si applicable)_

**Index** : « Libérer un port TCP occupé » → `acquis` (2026-08-27)

---

En fin de session :

---

## Récapitulatif

- Questions posées : N
- Monté d'un niveau : _liste_
- Descendu d'un niveau : _liste_
- Inchangé : N
- À revoir bientôt : _les fiches passées en `neuf` ou `fragile`_
- Fiches corrigées : _liste, ou « aucune »_

---

## Contraintes

- **Une question à la fois.** Attends la réponse avant la suivante.
- **Jamais la réponse dans la question.**
- **10 questions** par défaut par session, sauf nombre précisé par l'utilisateur.
- Une fiche `acquis` n'est réinterrogée qu'après **plus de 30 jours** sans révision.
- Ne modifie **jamais** le corps d'une fiche sans validation explicite.
- Ne touche jamais au contenu d'une note préexistante, même avec validation. Un **fichier thématique** est un fichier vers lequel pointe le lien du **titre** d'une section `##` de `_INDEX.md` (ces titres ont la forme `## Thème / [[Chemin/Fichier]]`). Le titre de la section « Notes autonomes » ne contient aucun lien : les fichiers listés dans son tableau restent des notes préexistantes. **Tout autre `.md` du vault est une note préexistante, en lecture seule** — y compris les `.md` posés à la racine de `Connaissances/` (`Une note.md`) ou directement dans un dossier de thème (`Prise de notes/Une autre note.md`). Dans le doute, demande.
- Les dates sont au format `AAAA-MM-JJ`, valeur absente `—`. **Obtiens la date du jour avec `date +%F` — ne la recopie pas du gabarit et ne l'écris pas de mémoire.**
- Dans les tableaux de l'index, les liens sont **sans alias** : `[[cible]]`, jamais `[[cible|libellé]]`, car le `|` casse la cellule. Quand tu réécris une ligne d'index, préserve le lien tel quel.
- Ne modifie que les colonnes `Revue` et `Maîtrise`. Les colonnes `Connaissance` et `Capturée` appartiennent à `/add-knowledge`.
- Les seules valeurs de maîtrise admises sont `neuf`, `fragile`, `acquis`.

## Règle finale

**Une question à la fois, et jamais la réponse dans la question.** 10 questions par défaut, et plus de 30 jours avant de réinterroger une fiche `acquis`. Tu n'ouvres au plus que **les 15 premières fiches `neuf`** listées dans l'index. Tu ne modifies que les colonnes `Revue` et `Maîtrise` de l'index. Tu ne corriges une fiche qu'avec validation explicite, et tu ne corriges **jamais** une note préexistante. Les dates viennent de `date +%F`, jamais du gabarit. Les liens dans les tableaux sont **sans alias**.