Maîtrise de l'Apprentissage

Que fait Maîtrise de l'Apprentissage ?

Maîtrise de l'Apprentissage fait agir Codex comme un apprenti sérieux avant d'agir comme un expert. Utilisez-la pour étudier le domaine, l'écosystème, les sources et les modèles d'implémentation avant de planifier ou de modifier du code.

Règle Fondamentale

Ne passez pas directement à l'implémentation lorsque la tâche dépend de connaissances du domaine que Codex n'a pas ancrées dans des sources actuelles. Produisez d'abord un Learning Brief. Utilisez ensuite ce brief comme base pour le plan, la conception, les tests ou l'implémentation.

Décision de Déclenchement

Utilisez cette compétence lorsque l'une de ces conditions est vraie :

• L'utilisateur demande de construire dans un domaine, un framework, un domaine de recherche, un protocole, une norme ou un écosystème matériel/logiciel inconnu.
• La tâche mentionne « recherche », « apprendre d'abord », « meilleures pratiques », « dernier », « articles », « GitHub », « exemples », « benchmarks », « normes » ou une intention équivalente dans n'importe quelle langue.
• Une hypothèse erronée pourrait entraîner un travail d'implémentation inutile, une conception dangereuse, une qualité académique/technique médiocre ou des API incompatibles.
• La tâche implique la sélection de bibliothèques, la reproduction d'un article, l'adaptation d'un dépôt très étoilé, le suivi de la documentation officielle ou la compréhension des conventions de projet locales avant de modifier.

N'utilisez pas cette compétence pour des modifications triviales, des corrections de bogues directes avec des preuves locales claires, des travaux de formatage uniquement, ou des tâches où l'utilisateur dit explicitement de ne pas faire de recherche.

Workflow

1. Cadrer l'objectif d'apprentissage. Reformulez l'objectif du projet, le public, l'environnement cible, les critères de succès et les inconnues à résoudre.
2. Choisir la profondeur de recherche. Commencez par scout sauf si la tâche est à haut risque, nouvelle, réglementée, axée sur des articles ou conflictuelle ; utilisez alors deep. Utilisez refresh pour les tâches de maintenance où le domaine est connu mais les dépendances ont pu changer.
3. Collecter les sources par ordre de priorité. Préférez d'abord la documentation officielle et la vérité du dépôt local, puis les normes/spécifications, les articles, les dépôts GitHub de haute qualité, les exemples/tests/problèmes et les comptes rendus techniques crédibles.
4. Apprendre les modèles, pas les détails insignifiants. Extrayez les concepts du domaine, le flux de données/contrôle, les contrats d'API, les architectures courantes, les cas limites, les modes de défaillance, les approches de test et les anti-patrons.
5. Auditer la couverture des sources. Marquez clairement les lacunes. Si aucune source officielle, aucun exemple de code ou aucune source actuelle n'existe, étiquetez la conclusion comme provisoire.
6. Produire un Learning Brief. Gardez-le actionnable : ce qu'il faut construire, ce qu'il faut éviter, ce qu'il faut vérifier et quelles hypothèses subsistent.
7. Procéder seulement après ancrage. Utilisez le Learning Brief pour élaborer le plan d'implémentation ou les modifications de code. Si le brief expose un risque critique non résolu, posez des questions ou recherchez davantage avant l'implémentation.

Porte de Validation Style SkillOpt

Cette compétence est optimisée avec une boucle inspirée de SkillOpt : déployer les tâches, réfléchir aux échecs, appliquer des modifications limitées et ne conserver un candidat que lorsque la validation s'améliore. Au moment de la tâche, utilisez la même discipline :

• Traitez le Learning Brief comme la procédure entraînable pour le projet actuel, et non comme un rapport décoratif.
• Effectuez des mises à jour limitées lorsque les preuves changent : ajoutez, supprimez ou remplacez uniquement les règles nécessaires pour améliorer la prochaine décision.
• Conservez les hypothèses rejetées dans le brief afin qu'elles ne soient pas réintroduites plus tard.
• Avant l'implémentation, exécutez une porte de validation : couverture des sources, adéquation du code local, examen des risques et critères d'acceptation.
• Si la porte de validation échoue, améliorez le brief au lieu de coder dans l'incertitude.

Discipline d'Entraînement

Utilisez ces contrôles de style SkillOpt pendant les longs projets ou l'amélioration répétée de la compétence :

• Taux d'apprentissage textuel : préférez une ou deux modifications précises de règle après chaque échec, pas une réécriture complète.
• Tampon d'hypothèses rejetées : enregistrez les hypothèses qui ont été réfutées, comme les API obsolètes, les dépôts abandonnés, les licences incompatibles, les articles faibles ou les exemples qui ne correspondent pas à l'environnement d'exécution de l'utilisateur.
• Validation retenue : testez le brief mis à jour sur un scénario différent avant de faire confiance à la nouvelle règle.
• Mise à jour lente : si le même échec apparaît dans plusieurs tâches, passez d'une note ponctuelle à SKILL.md ou à un fichier de référence.
• Vérification de régression : confirmez que la compétence ignore toujours les tâches triviales et ne fait pas de recherche excessive pour les corrections directes.

Règles de Gestion des Scénarios

• Pour les tâches avec le dernier framework/API, vérifiez la documentation officielle, les notes de version, les notes de migration et les versions des dépendances locales avant de recommander du code.
• Pour les tâches de reproduction d'article, lisez la méthode de l'article, les hypothèses, la configuration d'évaluation, la disponibilité du code/données et les écarts avec l'environnement de l'utilisateur.
• Pour les tâches d'adaptation GitHub, inspectez la licence, l'activité récente, les exemples, les tests, les problèmes, la santé des dépendances et si la réutilisation est autorisée ou si seul l'apprentissage est approprié.
• Pour les tâches de projet local, inspectez les manifestes, configurations, tests, documents et conventions existantes avant les sources externes.
• Pour les corrections directes à faible risque, passez explicitement la recherche approfondie et indiquez pourquoi la compétence n'est pas nécessaire.
• Pour les tâches en réseau dégradé, marquez la vérification externe manquante et continuez uniquement avec des preuves locales ou demandez la permission/contribution si nécessaire.

Contrat de Sortie

Chaque Learning Brief doit inclure :

• Tâche : objectif d'apprentissage, environnement cible, critères de succès, profondeur de recherche et confiance.
• Sources : URLs/chemins, type, date/actualité si disponible, fiabilité et utilisation clé.
• Modèle du Domaine : concepts clés, objets, termes et relations.
• Leçons du Code Local : structure du projet, conventions, contraintes et fichiers pertinents si du code local existe.
• Leçons GitHub/Code : dépôts examinés, modèles utiles, notes de licence/réutilisation et problèmes.
• Leçons d'Article/Norme : méthodes, exigences, limites et hypothèses.
• Modèles d'Implémentation : architecture, API/contrats, flux de données/contrôle, tests et contraintes opérationnelles.
• Risques et Anti-Patrons : cas limites, hypothèses faibles et choses à éviter.
• Recommandation : approche recommandée, critères d'acceptation et prochaines étapes.
• Questions Ouvertes : décisions non résolues ou preuves manquantes.

Utilisez references/learning-brief-template.md lorsqu'un artefact Markdown structuré est utile.

Ressources Incluses

Lisez ces fichiers uniquement lorsqu'ils sont pertinents :

• references/research-depths.md : choisissez scout, deep ou refresh.
• references/source-quality-rubric.md : évaluez et comparez les sources.
• references/github-mining.md : inspectez les dépôts GitHub sans vous laisser tromper par les seules étoiles.
• references/paper-learning.md : transformez les articles en contraintes techniques.
• references/skillopt-training.md : protocole d'optimisation inspiré de SkillOpt utilisé pour cette compétence.
• references/learning-brief-template.md : produisez un brief cohérent.
• references/anti-patterns.md : évitez les modes de défaillance courants.
• training/benchmark-scenarios.json : ensemble de scénarios retenus utilisé pour les tests de régression de cette compétence.

Les scripts sont des aides facultatives :

• scripts/create_learning_brief.py : crée une structure de Learning Brief.
• scripts/github_scan.py : recherche des dépôts GitHub et exporte des candidats.
• scripts/paper_scan.py : recherche les API publiques CrossRef, arXiv et PubMed.
• scripts/source_audit.py : vérifie la couverture des sources et avertit des bases fragiles.
• scripts/merge_learning_brief.py : fusionne les sorties des analyses en un brouillon de brief.
• scripts/skillopt_train.py : exécute le benchmark local d'entraînement et de validation des scénarios de style SkillOpt.

Règles d'Intégrité

• Ne fabriquez jamais de résultats de source, de citations, de contenu de dépôt ou de comportement d'API.
• Si l'accès réseau échoue, dites que la recherche a été dégradée et expliquez ce qui n'a pas été vérifié.
• Préférez les sources primaires aux résumés.
• Pour les affirmations « dernier », vérifiez la documentation actuelle ou les versions avant de vous fier à la mémoire.
• Traitez un article de blog, une réponse Stack Overflow ou un README comme insuffisant pour les décisions à haut risque.
• En cas de désaccord entre les sources, conservez le désaccord et recommandez le chemin vérifiable le plus sûr.