David-Li0406/meta-skill-evloving

Gestionnaire de Fichiers de Compétences Locaux

Objectif

Maintenir les fichiers de compétences personnels locaux de l'utilisateur comme un système de mémoire auto-améliorant et léger. L'objectif par défaut n'est pas de produire des compétences génériques prêtes pour le marché ; il est de préserver les comportements réutilisables qui aident cet utilisateur, cette équipe ou cet espace de travail lors de sessions futures. Un bon candidat peut encoder des préférences de workflow personnelles, des conventions de projet, des contrats de style, des choix d'outils ou des passerelles de révision qui ne seraient pas utiles à d'autres utilisateurs, tant qu'il est réutilisable pour le propriétaire prévu et approuvé.

Cette compétence ne dépend pas de code spécifique au projet, de serveurs, de magasins de vecteurs, de bases de données ou de dispositions de stockage. Elle fonctionne uniquement sur des dossiers de compétences locaux ordinaires :

<racine-competence/>
  <nom-competence/>
    SKILL.md
    agents/openai.yaml   (optionnel)
    scripts/             (optionnel)
    references/          (optionnel)
    assets/              (optionnel)

Utilisez cette compétence pour décider quand une session contient un élément de compétence réutilisable, déterminer si une compétence similaire existe déjà, puis rejeter, améliorer, fusionner ou créer une compétence locale. Le modèle doit initier cette vérification lorsque des signaux apparaissent ; il ne doit pas attendre que l'utilisateur le demande. La vérification doit rester légère et non bloquante, sauf si l'utilisateur demande explicitement de se concentrer sur la maintenance des compétences.

Coordination des Compétences Connexes

Cette compétence possède le cycle de vie décisionnel : quand extraire, s'il faut rejeter, améliorer ou fusionner, et où écrire. Coordonnez-vous avec les compétences voisines lorsqu'elles sont installées :

• Utilisez skill-creator pour la nouvelle structure de compétence, la dénomination, le placement des ressources, agents/openai.yaml et la validation.
• Utilisez skill-improvement ou des conseils d'amélioration équivalents pour l'itération de compétence existante, les prompts de test, l'analyse des échecs, le réglage de la description de déclencheur et la comparaison avant/après.
• Utilisez skill-finder, find-skills ou des outils de découverte équivalents pour rechercher les écosystèmes de compétences locaux ou externes avant de créer un doublon.
• N'empruntez les motifs d'auto-amélioration que comme heuristiques de décision : tri d'événements, déduplication, récurrence, priorité, contrôles de valeur et passerelles de promotion. N'adoptez pas les chemins de stockage, les hypothèses de démon ou la structure de code d'une autre compétence, sauf si l'utilisateur le demande.
• Si ces compétences auxiliaires ne sont pas disponibles, appliquez les procédures intégrées ci-dessous. Ne bloquez pas en raison de l'absence de compétences auxiliaires.
• Ne laissez pas les compétences auxiliaires affaiblir la limite d'extraction : seuls les changements de capacité réutilisables et fondés sur des preuves utilisateur doivent être enregistrés.

Sécurité et Consentement

Les compétences locales peuvent influencer le comportement futur de l'agent et peuvent inclure des scripts exécutables. Traitez les modifications de compétences comme des changements de comportement durables.

• N'installez, n'importez et n'activez pas de compétences tierces sans le consentement de l'utilisateur.
• N'ajoutez pas de capacités surprenantes, d'accès réseau caché, de gestion d'identifiants, d'exfiltration de données ou de commandes destructrices.
• Si une compétence ajoute des scripts ou des intégrations d'outils, rendez leur objectif visible dans SKILL.md.
• Lors de la modification d'une compétence qui peut être partagée avec une équipe, préservez les politiques de l'organisation et demandez avant de modifier un comportement sensible à la sécurité.
• Traitez chaque candidat comme personnel par défaut ; marquez-le équipe ou public uniquement lorsque les preuves soutiennent ce public plus large.
• Ne publiez pas, ne recommandez pas comme largement réutilisable et ne supprimez pas la portée personnelle d'une compétence spécifique à l'utilisateur sans approbation explicite de l'utilisateur.
• Avant la première note d'apprentissage persistant ou l'écriture de compétence dans une nouvelle convention locale, indiquez à l'utilisateur quel chemin serait écrit et demandez son approbation.
• Ne modifiez pas silencieusement ce gestionnaire autocompétence lui-même lors de la maintenance de routine. Améliorez-le uniquement lorsque l'utilisateur demande explicitement d'améliorer cette compétence.

Racines de Compétences

Avant d'écrire quoi que ce soit, identifiez où se trouvent les compétences locales.

• Utilisez d'abord un chemin explicite fourni par l'utilisateur.
• Sinon, vérifiez les racines courantes telles que ${CODEX_HOME}/skills, ~/.codex/skills, ./skills, .agents/skills et tout répertoire de compétences de l'espace de travail actuel contenant */SKILL.md.
• Si exactement une racine plausible existe, utilisez-la.
• Si plusieurs racines plausibles existent et que la cible est ambiguë, demandez à l'utilisateur quelle racine maintenir.
• Ne réorganisez jamais des racines de compétences non liées et ne modifiez pas les compétences en dehors de la racine choisie.

Politique de Déclenchement

Utilisez une politique de déclenchement à trois couches :

1. Analyse silencieuse : après chaque tour substantiel de l'utilisateur, demandez brièvement si le tour contient une préférence personnelle, une règle, une correction, un workflow, un échec ou un problème de qualité de compétence réutilisable.
2. Vérification d'extraction : lorsqu'un déclencheur ci-dessous se déclenche, classifiez l'expérience, attribuez des preuves et une valeur, recherchez des compétences similaires et testez-la par rapport à la limite d'extraction.
3. Écriture/mise à jour : ne modifiez les fichiers de compétences locales qu'après que le candidat a passé la limite, que la racine de compétence cible est claire et que l'utilisateur approuve le changement exact.

Le modèle doit initier proactivement les analyses et les vérifications d'extraction. Ne demandez pas à l'utilisateur « dois-je vérifier une compétence ? » Ne demandez que lorsque la racine cible est ambiguë, que la modification écraserait un comportement incertain ou que l'utilisateur doit approuver une installation externe ou un script sensible.

Cycle de Vie du Candidat

Gardez le cycle de vie séparé de tout système de stockage particulier : observez un signal, demandez éventuellement à l'utilisateur de choisir un titre/sujet candidat, rédigez le candidat, dédupliquez par motif, décidez rejeter/garder_note/améliorer/fusionner/créer, montrez la compétence ou le diff proposé complet, puis appliquez le plus petit changement approuvé et validez.

Dédupliquez par famille de tâches, déclencheur, outils, mode d'échec, contrat de sortie et compétence cible plutôt que par formulation exacte. Ne créez pas de base de données privée, de démon, de planificateur ou de magasin d'arrière-plan caché dans le cadre de cette compétence.

Porte de Sélection du Titre

Avant l'extraction complète, lorsque le sujet réutilisable est ambigu ou qu'il y a plusieurs compétences plausibles, montrez 2 à 5 titres concis de capacité réutilisable avec des raisons de preuve en une ligne, plus aucun de ceux-ci et sujet personnalisé. Si l'utilisateur choisit un titre ou saisit un sujet, traitez-le comme une direction uniquement : relancez la limite d'extraction et la recherche de compétences similaires pour cette direction, rejetez-la si elle échoue, ou montrez le SKILL.md/diff complet proposé pour approbation finale si elle réussit. Si l'utilisateur choisit aucun de ceux-ci, rejetez ou gardez une note non persistante ; n'écrivez pas de fichiers.

Cohérence Linguistique

Pour les nouvelles compétences, rédigez les titres candidats, le SKILL.md proposé, agents/openai.yaml et les petites ressources dans la langue dominante des preuves utilisateur ; une entrée en chinois produit des compétences en chinois, une entrée en anglais produit des compétences en anglais. Pour les mises à jour ou les fusions, conservez la langue dominante de la compétence cible, sauf si l'utilisateur demande explicitement de la traduire ; si des preuves mixtes rendent la langue ambiguë, demandez avant de rédiger. Ne mettez pas par défaut le contenu des compétences extraites en anglais.

Exécution en Arrière-Plan

L'extraction et la maintenance des compétences ne doivent pas bloquer la tâche principale de l'utilisateur.

• Traitez les vérifications d'extraction, la recherche de compétences similaires, la rédaction de candidats et la préparation de l'évaluation des déclencheurs comme un travail de maintenance en arrière-plan chaque fois que possible.
• Le travail en arrière-plan peut préparer des candidats, trouver des compétences similaires et rédiger des diffs, mais il ne doit pas écrire, mettre à jour, supprimer, installer ou activer des compétences sans confirmation de l'utilisateur.
• Continuez d'abord la demande principale de l'utilisateur ; ne faites pas attendre l'utilisateur pour l'extraction de compétences, sauf si l'utilisateur a explicitement demandé de se concentrer sur la maintenance des compétences.
• Ne présentez les résultats en arrière-plan que lorsqu'il y a une décision de candidat actionnable, un diff de fichier proposé ou une question de clarification/consentement.
• Exécutez au plus un travail de maintenance de compétences en arrière-plan par conversation active, sauf si l'utilisateur demande un lot ; mettez en file d'attente ou fusionnez les signaux supplémentaires.
• Ne démarrez pas de recherches coûteuses, d'évaluations larges ou de grandes réécritures au premier plan. Utilisez d'abord des vérifications légères, puis reportez la validation plus approfondie à une pause naturelle ou à un passage de maintenance explicite.
• Si l'exécution ne peut pas réellement effectuer un travail en arrière-plan, simulez-le en reportant la vérification de maintenance jusqu'à ce que la réponse actuelle soit terminée ou jusqu'à la prochaine pause naturelle.
• Ne bloquez jamais la livraison du travail demandé par l'utilisateur simplement pour terminer l'extraction du candidat, sauf si le travail demandé est lui-même la maintenance des compétences.

Porte de Confirmation

La confirmation de l'utilisateur est requise avant que tout fichier de compétence ne soit créé, mis à jour, supprimé, importé, installé, activé ou matériellement réécrit. Rédigez d'abord, demandez ensuite : après toute sélection de titre/sujet, ne demandez jamais « dois-je ajouter/mettre à jour une compétence ? » tant que le contenu ou le changement proposé n'est pas déjà rédigé pour examen.

Pour créer, montrez avant d'écrire :

• nom de compétence proposé et chemin cible
• public visé : personnel, équipe ou public, plus limites de portabilité
• pourquoi le candidat a passé la limite de compétence réutilisable
• niveau de preuve, signal de récurrence, priorité et signal de valeur
• compétences similaires vérifiées et pourquoi ce n'est pas un doublon
• contenu complet proposé du SKILL.md
• contenu complet proposé de agents/openai.yaml et de chaque script, référence ou texte d'actif proposé lorsque ces fichiers sont suffisamment petits pour être examinés en ligne ; pour les actifs volumineux, montrez la liste exacte des fichiers, l'objectif, la provenance et le diff ou manifeste généré

Pour améliorer ou fusionner, montrez avant d'écrire :

• chemin exact de la compétence cible
• type de décision : améliorer ou fusionner
• pourquoi le changement appartient à cette compétence existante
• niveau de preuve, signal de récurrence, priorité et signal de valeur
• un diff unifié complet, ou un texte avant/après complet pour chaque section modifiée lorsqu'un diff unifié n'est pas disponible
• chaque fichier qui serait ajouté, modifié, supprimé ou laissé intact
• plan de validation ou commande à exécuter après approbation

Demandez une approbation claire par oui/non uniquement après avoir montré l'artefact ou le diff complet proposé. Si l'utilisateur n'approuve pas, ne modifiez pas la compétence ; signalez le candidat comme reporté ou rejeté.

Déclencheurs Immédiats

Effectuez une vérification d'extraction immédiatement, ou à la prochaine pause naturelle si l'utilisateur attend la tâche principale, lorsque l'un de ces événements se produit :

• L'utilisateur corrige, rejette ou affine l'approche du modèle d'une manière qui devrait affecter les tâches similaires futures.
• L'utilisateur donne une préférence durable, un contrat de sortie, un workflow, une règle de nommage, une règle d'outil ou une porte de qualité.
• Une commande, un script, une intégration ou un workflow échoue et la session découvre un correctif réutilisable.
• L'agent répète un travail non trivial de configuration, de script, de transformation ou de validation qui devrait devenir une ressource réutilisable.
• Une compétence locale similaire s'est déclenchée de manière insuffisante, excessive ou a produit des conseils incomplets.
• La session révèle une référence, un modèle, un script ou une liste de contrôle manquants qui empêcheraient un effort répété futur.
• L'utilisateur utilise un langage orienté vers le futur tel que « souviens-toi de cela comme d'une compétence », « enregistre ce workflow », « mets à jour la compétence locale », « la prochaine fois, fais-le de cette façon », « c'est mon processus standard » ou « crée une compétence à partir de cette conversation ».

Considérez toujours l'extraction comme une vérification, pas une exigence : aucun changement de compétence est souvent le résultat correct.

N'extrayez pas lorsque l'utilisateur dit que la règle est temporaire, demande de ne pas s'en souvenir ou ne souhaite qu'une réponse unique.

Vérifications Programmées

Utilisez des vérifications programmées pour capturer un apprentissage graduel qu'aucun tour unique ne rend évident :

• Vérification de longueur de conversation : après environ 6 messages utilisateur substantiels, 12 tours totaux ou 2 à 3 tentatives de tâches distinctes depuis la dernière vérification.
• Vérification de jeton/volume : après un long bloc de nouveau contexte, surtout lorsque la conversation peut bientôt être résumée ou compactée.
• Vérification de limite de tâche : lorsqu'un livrable est terminé, une boucle de débogage se termine, un plan est accepté ou l'utilisateur passe à une nouvelle tâche.
• Vérification de fin de session : avant la réponse finale d'une session substantielle, examinez si quelque chose doit être rejeté, amélioré, fusionné, créé ou noté.

Gardez les vérifications programmées légères. Elles doivent généralement se produire silencieusement et ne se présenter à l'utilisateur que lorsqu'il y a une décision actionnable ou une clarification nécessaire.

Débattage et Regroupement

Empêchez l'extraction répétée et bruyante :

• Ne revérifiez pas le même signal de manière répétée dans une seule session.
• Regroupez plusieurs signaux faibles jusqu'à une limite de tâche ou une vérification programmée.
• Créez ou mettez à jour au plus une compétence par vérification, sauf si l'utilisateur demande explicitement un lot.
• Préférez garder_note ou rejeter pour les signaux limites jusqu'à ce que la répétition renforce les preuves.
• Si un candidat est proche mais pas encore assez réutilisable, souvenez-vous de la justification dans la note d'achèvement au lieu de créer une compétence.
• Fusionnez les déclencheurs simultanés en un seul passage de maintenance en arrière-plan.
• Lorsque plusieurs candidats sont en compétition, traitez d'abord l'échec répété de priorité la plus élevée ou la préférence confirmée par l'utilisateur.

Tri des Expériences

Avant de modifier les compétences, classifiez l'expérience de session. Les catégories durables sont erreur, correction, bonne_pratique, lacune_de_connaissance et préférence. résultat_unique signifie que la session a produit un travail utile mais aucun changement de processus durable.

Seules les catégories durables peuvent devenir des modifications de compétences, et seulement après avoir passé la limite d'extraction. Les résultats uniques ne doivent pas être promus.

Porte de Valeur et de Priorité

• Priorité P0 : empêche un comportement dangereux, destructeur, sensible à la vie privée ou en échec répété.
• Priorité P1 : empêche une erreur récurrente significative, un déclencheur manqué, une mauvaise fusion ou un workflow répété coûteux.
• Priorité P2 : améliore la qualité, la vitesse ou la clarté pour une famille de tâches récurrente.
• Priorité P3 : amélioration de commodité ou de style avec des preuves limitées.

Promouvez par valeur durable, pas par nouveauté. La valeur doit être explicable comme fiabilité, sécurité, vitesse, qualité, cohérence ou réduction du travail répété. Si aucune dimension de valeur n'est claire, rejetez ou conservez une note non persistante.

Modifiez un levier de comportement à la fois lors de l'amélioration d'une compétence existante : formulation du déclencheur, étape du workflow, porte de validation, placement des ressources ou contrainte de sécurité.

Règles de Promotion

Ne transformez pas chaque expérience en modification de compétence. Promouvez les expériences de manière délibérée :

• Promouvez immédiatement lorsque l'utilisateur dit explicitement que la règle doit s'appliquer la prochaine fois.
• Promouvez immédiatement lorsqu'une correction empêche une défaillance grave répétée, une action dangereuse ou un workflow destructeur.
• Promouvez après répétition lorsque la même erreur, correction ou bonne pratique apparaît dans plusieurs tâches similaires.

[La suite a été tronquée pour la traduction]