Évaluer et améliorer une Agent Skill existante avec darwin-skill

À qui cela s'adresse

Ce skill s’adresse à qui a déjà une Agent Skill et veut l’évaluer et l’améliorer dans une boucle d’expérience. Officiellement : optimiser vos Agent Skills comme on entraîne un modèle. Il s’inspire de l’autoresearch de Karpathy et déplace une boucle d’expérience autonome de l’entraînement de modèle vers l’optimisation de Skill.

Source d’inspiration :

https://github.com/karpathy/autoresearch

Il n’enseigne pas à écrire une première skill depuis zéro, et ce n’est pas un lissage générique de prompt. Un meilleur point de départ : vous avez déjà un fichier de skill exécutable, vous voulez voir quelle dimension est faible, puis décider de modifier. Si vous n’avez encore aucune skill à évaluer, la page ne donne pas un autre tutoriel complet « créer d’abord une skill ».

Notes officielles :

https://github.com/alchaincyf/darwin-skill

Premier essai en 3 minutes

La commande d’installation officielle n’est que celle-ci :

npx skills add alchaincyf/darwin-skill

Cela écrit le skill dans l’environnement de l’assistant actuel. Confirmez avant d’exécuter que vous voulez l’installer. N’ajoutez pas une deuxième commande d’installation.

Après installation, une action à faible risque : choisir une skill existante, faire d’abord évaluer par l’assistant selon le flux Darwin, ne pas modifier les fichiers directement, et ne pas exécuter de suppression ou de hard reset pendant l’évaluation. La page dit que la boucle complète inclut évaluer, améliorer, tester, ainsi que garder ou revenir en arrière. La première fois, s’arrêter au résultat d’évaluation et voir clairement si l’étape suivante réécrira la skill.

Si l’assistant entre dans l’optimisation à une dimension de Phase 2, il doit s’arrêter à CHECKPOINT et attendre votre confirmation. Signal de succès : vous voyez les notes d’évaluation, et toute réécriture a lieu seulement après votre accord. S’il continue à changer des fichiers sans point de contrôle, arrêtez tout de suite.

Cas d’usage

Cas 1 : optimisation à une dimension en Phase 2 avec confirmation au point de contrôle. Les preuves disent que cette étape force une pause et attend la confirmation de l’utilisateur. Donner une skill, n’autoriser qu’une proposition de changement à une dimension, lire le changement proposé à CHECKPOINT, puis décider de continuer. Ne pas le laisser conserver automatiquement une nouvelle version avant confirmation.

Cas 2 : vérifier la liste d’interdiction des actions à haut risque. Les preuves disent que la neuvième dimension exige que la skill énumère explicitement les opérations destructrices interdites, par exemple rm, git reset --hard, force push. La première fois, seulement vérifier si la skill cible a écrit cette liste ; ne pas exécuter vraiment ces commandes. Si la liste manque, s’arrêter à « signaler le manque ». La page n’écrit pas de commande qui corrige automatiquement la liste d’interdiction.

Limites

La boucle d’optimisation modifiera vos fichiers de skill et inclut garder ou revenir en arrière. La première fois, traiter CHECKPOINT comme un arrêt dur, pas un indice sautable. Les commandes à haut risque ne sont couvertes par cette norme que si la skill évaluée les liste comme interdites ; les preuves ne disent pas que Darwin interceptera chaque rm pour vous.

Il traite l’optimisation de Skill, pas l’entraînement de modèle lui-même. autoresearch n’est que la source d’inspiration. Les matériaux n’écrivent pas de commande slash précise qui démarre l’évaluation, ni de format de jeu de test. Les étapes manquantes s’arrêtent aux notes existantes ; ne pas installer un autre optimiseur.