Ghosteken/agent-harness

Enseigner

Aperçu

Une simple explication répond à une question ; l'enseignement est une relation qui persiste à travers les sessions et nécessite un endroit pour conserver l'état. Cette compétence traite le répertoire courant comme un espace de travail d'enseignement : un énoncé de mission expliquant pourquoi le sujet est important pour cet apprenant, un enregistrement de ce qu'il a déjà appris, et une séquence de leçons courtes et ciblées conçues pour tenir dans la mémoire de travail et reliées à la mission. Remarque : le catalogue de compétences de ce dépôt est par ailleurs limité aux flux de travail d'ingénierie — cette compétence est l'exception délibérée, pour un utilisateur qui souhaite un tuteur continu plutôt qu'un collaborateur d'ingénierie.

Quand l'utiliser

• L'utilisateur demande à être instruit, tutoré ou coaché sur un sujet qu'il a l'intention d'apprendre sur plusieurs sessions, pas une réponse unique.
• Un espace de travail d'enseignement existe déjà dans le répertoire courant (MISSION.md, learning-records/, etc. sont présents) et l'utilisateur souhaite le continuer.
• PAS pour une question unique "explique-moi X" sans intention continue — répondez-y simplement.
• PAS pour enseigner un sujet de génie logiciel déjà couvert par ce catalogue (ex : un framework, un modèle de test) — ces sujets sont mieux servis par la compétence d'ingénierie appropriée, qui peut citer les sources officielles directement.

Processus

1. Établir l'espace de travail

Vérifiez la présence de MISSION.md, RESOURCES.md, NOTES.md, ./learning-records/, ./lessons/, ./reference/ et ./assets/ dans le répertoire courant. S'ils n'existent pas, il s'agit d'un nouvel espace de travail — avant toute autre chose, demandez pourquoi l'utilisateur souhaite apprendre ce sujet et ce qu'il compte en faire, puis écrivez la réponse dans MISSION.md. Chaque leçon ultérieure sera ancrée dans cette mission ; enseigner sans mission produit des leçons qui semblent abstraites et déconnectées de ce dont l'apprenant a réellement besoin.

2. Distinguer connaissance, compétence et sagesse

Déterminez lequel des trois ce sujet nécessite principalement :

• Connaissance — faits et concepts, mieux acquis à partir de sources externes de haute qualité. Ne vous fiez jamais à la mémoire paramétrique pour cela ; suivez les sources dans RESOURCES.md et citez-les dans chaque leçon, car la fiabilité d'une leçon vient de l'endroit où ses affirmations peuvent être vérifiées.
• Compétence — durabilité et flexibilité, construites par un effort de récupération, pas par une lecture passive. Un sujet axé sur la compétence (une pratique physique, une technique interactive) nécessite des boucles de pratique, pas plus de lecture.
• Sagesse — ne vient que de l'interaction réelle en dehors de la leçon. Lorsqu'une question nécessite cela, répondez ce que vous pouvez, mais orientez vers une communauté réelle (forum, groupe local, classe) plutôt que de prétendre qu'une leçon peut la remplacer. Respectez-le si l'utilisateur ne souhaite pas de suggestion de communauté.

3. Trouver la zone proximale de développement de l'apprenant

Avant d'écrire une leçon, lisez les ./learning-records/ existants pour voir ce qui a déjà été couvert et les questions ouvertes qui subsistent, et vérifiez MISSION.md pour savoir vers quoi l'apprenant travaille finalement. Choisissez la prochaine leçon de manière à ce qu'elle soit "juste assez" difficile — pas un réchauffé de quelque chose de déjà solide, et pas plusieurs étapes en avance sur ce qui a été construit. Si l'utilisateur nomme quelque chose de spécifique qu'il veut apprendre, enseignez cela ; sinon, déduisez la prochaine étape appropriée à partir des enregistrements et de la mission.

4. Écrire une leçon

Une leçon est un fichier autonome et étroitement ciblé dans ./lessons/, enseignant une seule chose liée à la mission, assez court pour être terminé rapidement (la mémoire de travail est petite — un gain tangible par leçon, pas un survol). Citez une source primaire pour le sujet — celle de la plus haute confiance trouvée, pas la première — et terminez par une invitation à poser des questions de suivi. Construisez à partir de composants partagés dans ./assets/ (une feuille de style, un widget de quiz, un aide-mémoire de diagramme) plutôt que d'un style unique par leçon — la réutilisation est la valeur par défaut, et un nouveau composant réutilisable doit aller dans ./assets/ dès la première fois qu'une deuxième leçon le dupliquerait autrement.

Pour les leçons d'acquisition de compétences (pas celles d'acquisition de connaissances), intégrez la pratique de récupération, l'espacement et l'interleaving — la difficulté souhaitable est ce qui transforme une sensation éphémère de "j'ai compris" en quelque chose qui est toujours là la semaine suivante. Pour les leçons d'acquisition de connaissances, faites l'inverse : minimisez la difficulté incidente, car la charge de mémoire de travail est l'ennemie de la compréhension de premier passage.

5. Capturer le matériel de référence séparément des leçons

Si le sujet produit du contenu de référence réutilisable (un glossaire, une antisèche, une référence de syntaxe, une routine), écrivez-le dans ./reference/ — les leçons sont rarement revisitées, mais le matériel de référence l'est, il doit donc être l'essence compressée et de consultation rapide de ce qui a été enseigné, pas une copie du texte de la leçon. Une fois qu'un glossaire existe, restez cohérent avec ses termes dans chaque leçon ultérieure.

6. Enregistrer un enregistrement d'apprentissage lorsque quelque chose de non évident se produit

Après une session où quelque chose qui mérite d'être retenu a été appris ou la mission elle-même a changé, écrivez (ou ajoutez) une entrée numérotée ./learning-records/000N-<nom>.md — l'équivalent d'un enregistrement de décision d'architecture pour la propre compréhension de l'apprenant. C'est ce qui permet à une session ultérieure de trouver la véritable zone proximale de développement au lieu de deviner à partir de zéro. Si la mission change, mettez à jour MISSION.md et enregistrez le changement comme un enregistrement d'apprentissage — confirmez d'abord le changement avec l'utilisateur.

Rationalisations courantes

Rationalisation	Réalité
"Je connais déjà ce sujet, je n'ai pas besoin de sources externes"	La connaissance paramétrique devient obsolète et n'est pas vérifiable par l'apprenant — suivez et citez des sources réelles dans RESOURCES.md indépendamment de la confiance dans le souvenir.
"Une leçon longue et complète est plus efficace"	La mémoire de travail est petite ; une leçon qui tente de couvrir trop de choses produit un passage superficiel sur tout plutôt qu'une solide maîtrise d'une chose.
"L'utilisateur se souviendra de cela parce que ça avait du sens sur le moment"	C'est de la fluidité, pas de la force de rétention — la difficulté souhaitable (récupération, espacement, interleaving) est ce qui le fait coller, et l'ignorer produit une illusion de maîtrise.
"Je peux sauter la mission et simplement enseigner le sujet"	Sans mission, il n'y a aucun moyen de juger ce que l'apprenant devrait faire ensuite ou pourquoi une leçon donnée est importante — établissez-la d'abord, même brièvement.
"Je peux répondre moi-même de manière définitive à cette question de sagesse"	La sagesse vient de la pratique du monde réel, pas d'une leçon. Répondez raisonnablement, puis orientez vers une communauté réelle à moins que l'utilisateur n'ait dit qu'il n'en veut pas.

Signaux d'alarme

• Une leçon écrite sans citation de source primaire
• Une leçon qui ne se rattache à rien dans MISSION.md
• Un contenu d'acquisition de compétences enseigné de la même manière que le contenu d'acquisition de connaissances (pas de pratique de récupération, pas d'espacement)
• Une nouvelle leçon dupliquant le style ou les composants qu'une leçon précédente a déjà construits, au lieu d'extraire une ressource partagée
• Un enregistrement d'apprentissage jamais écrit après une session qui a clairement modifié la compréhension de l'apprenant ou la mission elle-même
• Traiter une question unique "explique X" comme si elle nécessitait la mise en place d'un espace de travail d'enseignement complet

Vérification

• MISSION.md existe et reflète pourquoi l'apprenant veut réellement ce sujet, confirmé avec lui
• La leçon qui vient d'être produite est limitée à une chose tangible, cite une source primaire et est enregistrée sous ./lessons/
• La leçon correspond à la zone proximale de développement de l'apprenant, vérifiée par rapport à ./learning-records/ avant de l'écrire
• Les leçons d'acquisition de compétences incluent une boucle de récupération/pratique ; les leçons d'acquisition de connaissances minimisent la difficulté incidente
• Les composants réutilisables ont été extraits ou ajoutés à ./assets/ plutôt que dupliqués en ligne
• Un enregistrement d'apprentissage a été écrit si la session a révélé quelque chose de non évident ou a modifié la mission