Learning Opportunities - Une compétence pour favoriser le développement intentionnel des compétences dans Claude Code et Codex

• Une compétence pour Claude Code et Codex qui aide, pendant le codage agentique, à développer non seulement le projet mais aussi l’expertise de l’utilisateur
• Après des travaux d’architecture comme la création de nouveaux fichiers, la modification de schémas ou le refactoring, Claude propose un exercice d’apprentissage optionnel de 10 à 15 minutes
• Les exercices s’appuient sur des techniques issues de la science de l’apprentissage, comme la prédiction, la génération, la pratique de rappel et la répétition espacée, et créent des exemples à moitié résolus à partir du travail réel de l’utilisateur sur son projet
• Conçu pour atténuer des problèmes que peuvent provoquer les outils de codage IA, comme l’acceptation passive du code généré, l’illusion de maîtrise, les longues sessions intensives, le manque de métacognition et la diminution de l’auto-évaluation
• Claude pose des questions du type : « Voulez-vous faire un court exercice d’apprentissage sur ce sujet ? Cela prend environ 10 à 15 minutes », puis lance un exercice interactif si l’utilisateur accepte
• Le principe de conception central est que Claude ne répond pas à ses propres questions et attend l’entrée de l’utilisateur, afin de créer un mode de réflexion et d’exploration distinct du codage agentique rapide
• Les types d’exercices incluent prédiction → observation → réflexion, génération → comparaison, suivi de chemin d’exécution, prédiction de débogage, explication à un nouveau développeur et vérification par rappel de contenus de sessions précédentes
• Les conditions de suppression actuellement proposées sont de ne pas reproposer d’opportunité d’apprentissage si l’exercice a déjà été refusé dans la session, ou si deux exercices ont déjà été terminés dans la même session
• Dans Codex, on peut l’ajouter à la marketplace avec codex plugin marketplace add https://github.com/DrCatHicks/learning-opportunities.git, avec learning-opportunities, learning-opportunities-auto et orient inclus
• Dans Claude Code, il faut d’abord l’ajouter via la marketplace des plugins Claude Code, puis installer /plugin install learning-opportunities@learning-opportunities et redémarrer pour l’activer
• learning-opportunities-auto est un hook optionnel pour Linux et macOS qui permet à Claude d’envisager une proposition d’exercice après un commit git ; Windows est aussi pris en charge avec une configuration supplémentaire
• La compétence orient crée un fichier orientation.md lors de l’apprentissage d’un nouveau dépôt et fournit des leçons recommandées fondées sur la recherche en compréhension de programmes et en exploration de codebase
• Recommandé avec Learning-Goal, une compétence présentée comme aidant à définir des objectifs d’apprentissage interactifs semi-structurés avec la méthode MCII
• Pour les expérimentations en équipe, il est possible d’utiliser MEASURE-THIS.md, qui fournit des questions d’enquête validées, un guide d’interprétation des résultats, un modèle de « team boast » à partager avec la direction, ainsi qu’un rappel dans Claude.md sur la rigueur statistique
• Distribué sous licence Creative Commons Attribution 4.0 International License

[GN⁺]

Avis Hacker News

• Je ne connais pas très bien les Skills, mais en regardant le dépôt, ça donne l’impression qu’il y a beaucoup de code et de texte décoratifs par rapport au simple court prompt dans un script bash exécuté après le commit
  L’essentiel semble être : comme l’utilisateur vient de faire un commit, s’il y a un nouveau fichier, un changement de schéma, une décision d’architecture, un refactoring ou un pattern inhabituel, proposer un exercice d’apprentissage de 10 à 15 minutes

  • Les Skills sont utiles pour décrire de façon standard des workflows répétables, économiser le contexte grâce à une divulgation progressive, partager des prompts, et encapsuler les parties peu utilisées mais non déterministes dans des procédures déterministes comme des scripts
    Conceptuellement, il faut les voir non pas comme une magie créée par d’autres qu’on réutilise, mais comme un logiciel qu’on fait grandir progressivement https://alexhans.github.io/posts/series/evals/building-agent...
    Les harnais de codage ont souvent déjà un skill d’agent SkillBuilder, donc c’est facile à créer et à faire évoluer en continu
    Je recommande d’en fabriquer soi-même selon ses propres difficultés, et il y a aussi un exemple simple montrant comment des évaluations peuvent suffire à faire monter significativement la précision de l’automatisation https://alexhans.github.io/posts/series/evals/sketch-to-text...
  • La plupart de ces outils finissent au fond par être encore un fichier Markdown injecté dans le prompt, et vu la manière dont fonctionnent les grands modèles de langage, c’est une structure tout à fait normale
    Donc j’aurais envie de recommander à chacun de se fabriquer son propre outil du même genre avec Claude. Au début, ça consomme des tokens, mais ensuite, avec son propre outil, on peut fortement réduire les tokens et les appels nécessaires pour les tâches vraiment utiles
    On peut aussi verrouiller davantage les appels d’outils pour plus de sûreté, rendre le travail de l’agent relançable, et réduire les modes d’échec. Ça évite aussi de brûler des tas de tokens à essayer de reconstituer jusqu’où l’agent était allé si le laptop s’éteint en plein travail

• J’ai été surpris de voir que certains Skills n’indiquent même pas de procédure précise ni de choses à faire, et se contentent surtout d’un amorçage façon discours de motivation pour pousser le modèle à produire un meilleur texte sur une tâche donnée
  Le frontend design skill utilisé par Claude, par exemple, revient presque à lui demander de choisir de bonnes polices et de garder un design cohérent, sans donner de consignes concrètes sur quelles polices employer ni comment construire la palette de couleurs ou la mise en page
  https://github.com/anthropics/claude-code/blob/main/plugins/...

• Les agents d’écriture de code peuvent créer une dette répétitive. Si on accepte les résultats d’un assistant de code sans vérifier s’ils sont corrects, on perd sa connaissance de sa propre codebase
  Les fichiers de contexte comme CLAUDE.md, les protocoles de migration ou d’authentification ne fonctionnent bien que si on les comprend suffisamment pour les mettre à jour correctement
  Il m’est déjà arrivé d’accepter aveuglément pendant deux heures du code produit par un agent, puis de me retrouver incapable de créer un nouveau fichier de contexte parce que j’avais oublié comment fonctionnait la codebase. Cette dette de compétence n’apparaît pas dans les diff, mais elle se révèle au moment où il faut guider l’agent

  • Je me demande si ce n’est pas plus récursif que répétitif
    Quand on fait un gros changement fonctionnel, mieux vaut d’abord se mettre d’accord avec l’agent, dans le chat, sur le problème métier qu’on cherche à résoudre avant de lui faire écrire du code. Ça ressemble à une réunion avec un prestataire externe pour clarifier ce qu’on veut
    Ensuite, avec l’agent, on rédige un document de conception en puces hiérarchisées dans un vrai fichier .md, en le laissant en générer et modifier l’essentiel, mais en examinant de près les problèmes et les décisions ambiguës afin que les décisions de conception soient déjà tranchées à ce stade
    Puis on lui fait transformer la spécification de conception en squelette d’un ensemble de tests de spécification BDD, qu’il remplit ensuite pendant l’implémentation
    Pendant la phase d’implémentation, on peut ajouter, modifier ou supprimer des tests unitaires et d’intégration, mais il faut garder fixes le fichier de spécification de conception et la structure des tests BDD qui en dérive. Avant la fin, les tests BDD doivent être remplis avec la logique correspondant à leurs libellés et tous doivent passer
    Si le projet est très gros, on peut relancer des sprints qui répètent le processus : définir de nouvelles exigences métier, modifier la conception, ajouter un lot BDD, etc. Ou bien, entre les étapes 2 et 3, on peut découper la conception en jalons et ne créer des éléments BDD que pour le jalon en cours, puis les traiter
    En gros, l’idée est d’utiliser une approche en cascade avec les LLM. Si tout le processus tient en moins d’une heure, le waterfall peut même être assez confortable
    Le point essentiel, c’est qu’à la fin du projet ou du jalon, il faut demander à l’agent d’expliquer dans le chat le code qu’il a écrit, en lui interdisant d’expliquer ce qui apparaissait déjà dans la conception
    On peut alors transformer les explications des parties surprenantes en commentaires de code, et le résultat ressemble à des commentaires qu’un humain aurait réellement écrits, pas à des commentaires formels et inutiles

• Sans benchmarks ni évaluations, comment savoir que ça donne de meilleurs résultats que /create-skill ? Des tests naïfs ne suffisent pas pour inspirer confiance

  • J’ai l’impression qu’ici on parle plutôt du développement des compétences chez l’humain. C’est une fonctionnalité qui fournit des occasions d’apprentissage à l’utilisateur
    Il est dit que quand on termine un travail d’architecture, Claude propose de manière facultative un exercice de 10 à 15 minutes fondé sur des principes scientifiques d’apprentissage. Il utilise des techniques comme la prédiction, la génération, la pratique du rappel et la répétition espacée, avec des exemples à moitié complétés tirés de son propre projet
    Le nom prête à confusion
  • On dirait un état où l’on est tellement imprégné de LLM que le moindre terme associé déclenche une réaction pavlovienne
  • C’est bien d’avoir mentionné les évaluations, mais là je me demande ce qui est utilisé ou recherché en ce moment. Est-ce que c’est développé maison, ou est-ce qu’un framework d’évaluation existant est utilisé ?

• Pour ceux qui ne sont pas encore tombés dans ce terrier de lapin, les Skills sont des fichiers Markdown structurés qui expliquent comment traiter une tâche de portée limitée
  Par exemple, si vous écrivez des endpoints d’API d’une certaine façon, vous décrivez cette procédure dans un skill. Plus tard, si l’agent juge ce skill pertinent pour le contexte courant du chat, il le charge et exécute ce qui y est indiqué
  C’est similaire à un appel d’outil, sauf qu’il ne s’agit pas d’une fonction appelable, mais d’instructions sur la manière d’accomplir ce « skill »
  Au moins dans Cline, que j’utilise, on peut définir des Skills au niveau global ou local au projet

  • Les Skills ont aussi un en-tête frontmatter, dont une partie est partagée tôt dans le contexte, un peu comme un fichier CLAUDE.md
    D’après ce que j’ai entendu ici, le chargement d’un skill peut avoir un impact distinct sur le contexte, par exemple en persistant après la compression
    Si plusieurs skills sont chargés, ils peuvent rester chargés de façon permanente dans la session
    Je trouve que ça va bien avec les subagents. Le subagent peut charger un skill, faire le travail, puis ne présenter que le résultat ; l’agent orchestrateur n’a alors pas besoin de connaître son contenu

• Je ne vois pas très bien ce qu’est exactement l’adaptive dynamic textbook approach. Il me faudrait un exemple
  En revanche, l’idée qu’en acceptant du code généré et en écrivant moins soi-même on saute le traitement actif nécessaire à la construction de la compréhension, ça me paraît tout à fait juste

• Je ne comprends pas pourquoi on se donne tant de mal pour produire ce genre de super idées sans fournir de lien vers une démo ou un exemple de sortie. C’est un schéma qu’on voit tous les jours sur HN
  Pour voir à quoi ce skill ressemble en pratique, il faut vraiment le télécharger et l’exécuter soi-même ? Je n’en ai pas envie

  • Pour l’instant, l’usage des skills me paraît bien moins stable que des instructions explicites dans AGENTS.md
    Je comprends l’idée d’éviter le gonflement du contexte en n’ajoutant pas de skill quand il n’est pas pertinent, mais sans instruction explicite dans AGENTS.md, rien ne garantit que l’agent utilisera le skill. Du coup, ça ne diffère plus tellement d’un fichier Markdown référencé quelque part
    En créant https://www.agentkanban.io, un tableau de travail intégré à GitHub Copilot, j’ai beaucoup expérimenté pour savoir où placer les instructions
    Une structure à un niveau sous AGENTS.md a plutôt bien marché. Comme il fallait que l’agent récupère de façon fiable les ID propres à chaque tâche, j’ai fini par adopter une approche où un INSTRUCTION.md vit dans un fichier géré par l’outil, ce qui permet aussi de réduire la pollution de AGENTS.md
    J’ai aussi testé les Skills, mais ils étaient ignorés trop souvent, et il était donc plus difficile de faire fonctionner l’outil avec autant de fiabilité qu’avec mon approche actuelle
  • Il y a déjà SKILL.md, donc il suffit de le lire pour voir ce qu’il fait

• J’aime vraiment beaucoup l’idée. J’ai déjà demandé à Claude de prendre des manuels open source et de la documentation pour fabriquer à la volée un support pédagogique
  Je me demande si ce skill pourrait être étendu à un domaine plus général d’apprentissage et d’application, ou s’il est vraiment spécialisé dans le code

• Les réactions ici sont intéressantes, mais la plupart passent à côté de l’essentiel, je trouve
  Pour moi, l’enseignement important consiste à voir comment les autres utilisent les Skills et à apprendre de cela. Hier, je regardais le cours de Matt Pocock sur l’usage des agents, et il montrait des Skills en utilisant un skill « grill-me » pour faire évoluer un document d’exigences produit
  Je ne vais probablement pas faire exactement comme lui, mais ça m’a donné des idées sur ma propre façon de produire des exigences puis de les implémenter
  Comme le disent les ingénieurs d’Anthropic, Claude ressemble à un ingénieur talentueux mais qui manque de spécialisation. Les Skills sont les dossiers et fichiers qui lui donnent cette spécialisation
  Une autre chose apprise chez Pocock, c’est que plus le contexte ou la taille en tokens s’allonge, plus les réponses tendent à devenir stupides. Les Skills sont donc une autre manière de présenter le problème au LLM sous une forme comprimée et d’obtenir une réponse optimisée
  Claude a aussi des traits de comportement. Si quelqu’un construit des skills de manière répétée, il y a de fortes chances qu’ils se transplantent mal chez d’autres utilisateurs, parce que chacun parle à Claude différemment
  C’est pour ça que j’hésite à partager mon dossier de skills avec des collègues. À la place, je préfère montrer en démo ce que j’ai créé pour qu’ils voient ce qui est possible et trouvent leur propre workflow
  La vraie valeur est d’observer comment d’autres construisent avec Claude, puis de les imiter à sa manière. C’est un peu comme quand on apprend à programmer : on recopie le code du livre de Kernighan et Ritchie sur le C, on le modifie pour comprendre son fonctionnement, puis on l’adapte ensuite à ses propres objectifs
  Une autre raison pour laquelle je mentionne les traits de comportement, c’est que l’auteur est psychologue, et je trouve intéressant qu’il interagisse probablement avec Claude d’une manière assez différente de celle d’un programmeur
  À ce sujet, j’ai appris que l’auteur et plusieurs experts d’autres domaines ont quitté Twitter depuis longtemps, donc je pense installer bsky ou Mastodon pour les suivre. Il me semble important d’observer comment des experts non programmeurs utilisent les LLM

• C’est une bonne idée, alors j’ai exploré un peu le sujet ce matin
  En utilisant trop l’IA, j’ai vraiment eu une forte impression de fuite des cerveaux, et même si ce n’est pas une solution complète, je pense que faire quelques exercices par jour peut déjà aider pas mal