Modifié pour DeepSeek Harness. Amont : Anthropic's skill-creator (Apache-2.0, voir LICENSE.txt).
Créateur de Compétence
Une compétence pour créer de nouvelles compétences et les améliorer de manière itérative.
À un niveau élevé, le processus de création d'une compétence se déroule comme suit :
- Décidez ce que vous voulez que la compétence fasse et approximativement comment elle doit le faire
- Rédigez un brouillon de la compétence
- Créez quelques invites de test et exécutez le modèle avec la compétence installée
- Aidez l'utilisateur à évaluer les résultats à la fois qualitativement et quantitativement
- Pendant que les exécutions ont lieu en arrière-plan, rédigez quelques évaluations quantitatives s'il n'y en a pas (s'il y en a, vous pouvez soit les utiliser telles quelles, soit les modifier si vous pensez que quelque chose doit changer). Expliquez-les ensuite à l'utilisateur (ou, si elles existent déjà, expliquez celles qui existent)
- Utilisez le script
eval-viewer/generate_review.pypour montrer les résultats à l'utilisateur afin qu'il puisse les examiner, et laissez-le également consulter les métriques quantitatives
- Réécrivez la compétence en fonction des retours de l'utilisateur sur l'évaluation des résultats (et aussi s'il y a des défauts flagrants qui deviennent apparents à partir des benchmarks quantitatifs)
- Répétez jusqu'à satisfaction
- Étendez l'ensemble de test et réessayez à plus grande échelle
Votre travail lors de l'utilisation de cette compétence est de déterminer où se trouve l'utilisateur dans ce processus, puis d'intervenir et de l'aider à progresser à travers ces étapes. Par exemple, peut-être qu'ils disent "Je veux créer une compétence pour X". Vous pouvez aider à préciser ce qu'ils veulent dire, rédiger un brouillon, écrire les cas de test, déterminer comment ils veulent évaluer, exécuter toutes les invites, et répéter.
D'un autre côté, peut-être ont-ils déjà un brouillon de la compétence. Dans ce cas, vous pouvez passer directement à la partie évaluation/itération de la boucle.
Bien sûr, vous devez toujours être flexible et si l'utilisateur dit "Je n'ai pas besoin d'exécuter tout un tas d'évaluations, faisons juste du vibe avec moi", vous pouvez le faire à la place.
Ensuite, une fois la compétence terminée (mais encore une fois, l'ordre est flexible), vous pouvez également exécuter l'améliorateur de description de compétence, pour lequel nous avons un script séparé, afin d'optimiser le déclenchement de la compétence.
Cool ? Cool.
Communiquer avec l'utilisateur
Le créateur de compétence est susceptible d'être utilisé par des personnes ayant des niveaux de familiarité très variés avec le jargon de la programmation. Si vous n'avez pas entendu (et comment le pourriez-vous, c'est seulement très récemment que cela a commencé), il y a une tendance maintenant où la puissance de DSH inspire les plombiers à ouvrir leurs terminaux, les parents et grands-parents à chercher sur google "comment installer npm". D'un autre côté, la majorité des utilisateurs sont probablement assez compétents en informatique.
Alors, faites attention aux indices contextuels pour comprendre comment formuler votre communication ! Par défaut, juste pour vous donner une idée :
- "évaluation" et "benchmark" sont à la limite, mais OK
- pour "JSON" et "assertion", vous voulez voir des indices sérieux de l'utilisateur qu'il sait ce que ces termes signifient avant de les utiliser sans les expliquer
Il est acceptable d'expliquer brièvement les termes si vous avez un doute, et n'hésitez pas à clarifier les termes avec une courte définition si vous n'êtes pas sûr que l'utilisateur comprenne.
Créer une compétence
Capturer l'Intention
Commencez par comprendre l'intention de l'utilisateur. La conversation actuelle peut déjà contenir un workflow que l'utilisateur souhaite capturer (par exemple, ils disent "transforme ça en compétence"). Si c'est le cas, extrayez d'abord les réponses de l'historique de la conversation — les outils utilisés, la séquence des étapes, les corrections apportées par l'utilisateur, les formats d'entrée/sortie observés. L'utilisateur peut avoir besoin de combler les lacunes, et doit confirmer avant de passer à l'étape suivante.
- Que devrait permettre cette compétence à DSH de faire ?
- Quand cette compétence doit-elle se déclencher ? (quelles phrases/contextes utilisateur)
- Quel est le format de sortie attendu ?
- Devons-nous configurer des cas de test pour vérifier que la compétence fonctionne ? Les compétences avec des sorties objectivement vérifiables (transformations de fichiers, extraction de données, génération de code, étapes de workflow fixes) bénéficient de cas de test. Les compétences avec des sorties subjectives (style d'écriture, art) n'en ont souvent pas besoin. Suggérez la valeur par défaut appropriée en fonction du type de compétence, mais laissez l'utilisateur décider.
Entretien et Recherche
Posez des questions de manière proactive sur les cas limites, les formats d'entrée/sortie, les exemples de fichiers, les critères de succès et les dépendances. Attendez pour écrire les invites de test jusqu'à ce que cette partie soit réglée.
Vérifiez les MCP disponibles — si utiles pour la recherche (rechercher de la documentation, trouver des compétences similaires, consulter les meilleures pratiques), effectuez la recherche en parallèle via des sous-agents si disponibles, sinon en ligne. Venez préparé avec du contexte pour réduire la charge sur l'utilisateur.
Rédiger le SKILL.md
En fonction de l'entretien avec l'utilisateur, remplissez ces composants :
- name: Identifiant de la compétence
- description: Quand déclencher, ce qu'elle fait. C'est le mécanisme de déclenchement principal — incluez à la fois ce que fait la compétence ET les contextes spécifiques pour son utilisation. Toutes les informations "quand utiliser" vont ici, pas dans le corps. Note : actuellement, le modèle a tendance à "sous-déclencher" les compétences — à ne pas les utiliser quand elles seraient utiles. Pour contrer cela, veuillez rendre les descriptions de compétences un peu "insistantes". Ainsi, par exemple, au lieu de "Comment créer un tableau de bord simple et rapide pour afficher les données internes de l'entreprise", vous pourriez écrire "Comment créer un tableau de bord simple et rapide pour afficher les données internes de l'entreprise. Assurez-vous d'utiliser cette compétence chaque fois que l'utilisateur mentionne des tableaux de bord, la visualisation de données, des métriques internes, ou souhaite afficher tout type de données d'entreprise, même s'il ne demande pas explicitement un 'tableau de bord'."
- whenToUse / metadata / disable-model-invocation / user-invocable: les clés de frontmatter optionnelles que DSH reconnaît. DSH lit
name,description,whenToUse,metadata,disable-model-invocationetuser-invocabledepuis le frontmatter ; placez tout ce que vous voulez enregistrer (une licence, une version) sousmetadataplutôt que comme une clé de premier niveau. - le reste de la compétence :)
Guide de Rédaction de Compétence
Anatomie d'une Compétence
nom-de-la-competence/
├── SKILL.md (obligatoire)
│ ├── Frontmatter YAML (nom, description obligatoires)
│ └── Instructions en Markdown
└── Ressources incluses (optionnel)
├── scripts/ - Code exécutable pour tâches déterministes/répétitives
├── references/ - Documents chargés dans le contexte selon les besoins
└── assets/ - Fichiers utilisés dans la sortie (modèles, icônes, polices)
Divulgation Progressive
Les compétences utilisent un système de chargement à trois niveaux :
- Métadonnées (nom + description) - Toujours en contexte (~100 mots)
- Corps du SKILL.md - En contexte chaque fois que la compétence se déclenche (<500 lignes idéalement)
- Ressources incluses - Au besoin (illimité, les scripts peuvent s'exécuter sans chargement)
Ces nombres de mots sont indicatifs et vous pouvez librement aller plus loin si nécessaire.
Modèles clés :
- Gardez le SKILL.md en dessous de 500 lignes ; si vous approchez de cette limite, ajoutez un niveau de hiérarchie supplémentaire avec des indications claires sur la prochaine étape pour le modèle utilisant la compétence.
- Référencez clairement les fichiers depuis SKILL.md avec des indications sur quand les lire
- Pour les fichiers de référence volumineux (>300 lignes), incluez une table des matières
Organisation par domaine : Lorsqu'une compétence prend en charge plusieurs domaines/cadres, organisez par variante :
déploiement-cloud/
├── SKILL.md (workflow + sélection)
└── references/
├── aws.md
├── gcp.md
└── azure.md
DSH ne lit que le fichier de référence pertinent.
Principe d'Absence de Surprise
Cela va sans dire, mais les compétences ne doivent pas contenir de malware, de code d'exploitation, ou tout contenu pouvant compromettre la sécurité du système. Le contenu d'une compétence ne doit pas surprendre l'utilisateur dans son intention si elle est décrite. Ne vous prêtez pas à des demandes de création de compétences trompeuses ou conçues pour faciliter un accès non autorisé, une exfiltration de données, ou d'autres activités malveillantes. Des choses comme un "jeu de rôle en tant que XYZ" sont OK cependant.
Modèles d'Écriture
Préférez l'utilisation de la forme impérative dans les instructions.
Définition des formats de sortie - Vous pouvez le faire comme ceci :
## Structure du rapport
Utilisez TOUJOURS ce modèle exact :
# [Titre]
## Résumé exécutif
## Principales conclusions
## Recommandations
Modèle d'exemples - Il est utile d'inclure des exemples. Vous pouvez les formater comme ceci (mais si "Entrée" et "Sortie" sont dans les exemples, vous voudrez peut-être vous en écarter un peu) :
## Format du message de commit
**Exemple 1 :**
Entrée : Ajout de l'authentification utilisateur avec des jetons JWT
Sortie : feat(auth) : implémenter l'authentification basée sur JWT
Style d'Écriture
Essayez d'expliquer au modèle pourquoi les choses sont importantes plutôt que d'utiliser des obligations lourdes et impérieuses. Utilisez la théorie de l'esprit et essayez de rendre la compétence générale et non limitée à des exemples spécifiques. Commencez par écrire un brouillon, puis regardez-le avec un œil neuf et améliorez-le.
Cas de Test
Après avoir rédigé le brouillon de la compétence, créez 2-3 invites de test réalistes — le genre de chose qu'un véritable utilisateur dirait réellement. Partagez-les avec l'utilisateur : [vous n'êtes pas obligé d'utiliser ce langage exact] "Voici quelques cas de test que j'aimerais essayer. Est-ce que cela vous semble correct, ou souhaitez-vous en ajouter d'autres ?" Ensuite, exécutez-les.
Enregistrez les cas de test dans evals/evals.json. N'écrivez pas encore d'assertions — juste les invites. Vous rédigerez les assertions à l'étape suivante pendant que les exécutions sont en cours.
{
"skill_name": "exemple-competence",
"evals": [
{
"id": 1,
"prompt": "Invite de tâche de l'utilisateur",
"expected_output": "Description du résultat attendu",
"files": []
}
]
}
Voir references/schemas.md pour le schéma complet (y compris le champ assertions, que vous ajouterez plus tard).
Exécution et évaluation des cas de test
Cette section est une séquence continue — ne vous arrêtez pas en cours de route. N'utilisez PAS /skill-test ou toute autre compétence de test.
Placez les résultats dans <nom-competence>-workspace/ en tant que dossier frère du répertoire de la compétence. Au sein de l'espace de travail, organisez les résultats par itération (iteration-1/, iteration-2/, etc.) et à l'intérieur de celle-ci, chaque cas de test obtient un dossier (eval-0/, eval-1/, etc.). Ne créez pas tout cela à l'avance — créez simplement les dossiers au fur et à mesure.
Étape 1 : Lancer toutes les exécutions (avec-compétence ET baseline) dans le même tour
Pour chaque cas de test, lancez deux sous-agents dans le même tour — un avec la compétence, un sans. Ceci est important : ne lancez pas d'abord les exécutions avec compétence et ne revenez pas aux baselines plus tard. Lancez tout en même temps pour que tout se termine à peu près en même temps.
Exécution avec compétence :
Exécutez cette tâche :
- Chemin de la compétence : <chemin-vers-la-competence>
- Tâche : <invite d'évaluation>
- Fichiers d'entrée : <fichiers d'évaluation si présents, ou "aucun">
- Enregistrer les sorties vers : <espace de travail>/iteration-<N>/eval-<ID>/with_skill/outputs/
- Sorties à enregistrer : <ce qui intéresse l'utilisateur — par exemple, "le fichier .docx", "le CSV final">
Exécution baseline (même invite, mais la baseline dépend du contexte) :
- Créer une nouvelle compétence : aucune compétence du tout. Même invite, pas de chemin de compétence, enregistrer dans
without_skill/outputs/. - Améliorer une compétence existante : l'ancienne version. Avant de modifier, faites un instantané de la compétence en copiant le répertoire avec
shutil.copytree(par exemple<espace de travail>/skill-snapshot/à partir de<chemin-competence>), puis pointez le sous-agent baseline vers l'instantané. Enregistrer dansold_skill/outputs/.
Écrivez un eval_metadata.json pour chaque cas de test (les assertions peuvent être vides pour l'instant). Donnez à chaque évaluation un nom descriptif basé sur ce qu'elle teste — pas simplement "eval-0". Utilisez ce nom pour le dossier également. Si cette itération utilise des invites d'évaluation nouvelles ou modifiées, créez ces fichiers pour chaque nouveau dossier d'évaluation — ne supposez pas qu'ils sont reportés des itérations précédentes.
{
"eval_id": 0,
"eval_name": "nom-descriptif-ici",
"prompt": "L'invite de tâche de l'utilisateur",
"assertions": []
}
Étape 2 : Pendant que les exécutions sont en cours, rédigez les assertions
N'attendez pas simplement que les exécutions se terminent — vous pouvez utiliser ce temps de manière productive. Rédigez des assertions quantitatives pour chaque cas de test et expliquez-les à l'utilisateur. Si des assertions existent déjà dans evals/evals.json, révisez-les et expliquez ce qu'elles vérifient.
Les bonnes assertions sont objectivement vérifiables et ont des noms descriptifs — elles doivent se lire clairement dans le visualiseur de benchmark afin que quelqu'un jetant un coup d'œil aux résultats comprenne immédiatement ce que chacune vérifie. Les compétences subjectives (style d'écriture, qualité du design) sont mieux évaluées qualitativement — n'imposez pas d'assertions sur des choses qui nécessitent un jugement humain.
Mettez à jour les fichiers eval_metadata.json et evals/evals.json avec les assertions une fois rédigées. Expliquez également à l'utilisateur ce qu'il verra dans le visualiseur — à la fois les sorties qualitatives et le benchmark quantitatif.
Étape 3 : Au fur et à mesure que les exécutions se terminent, capturez les données de temps
Lorsque chaque tâche du sous-agent se termine, vous recevez une notification, mais elle ne contient ni les comptes de tokens ni le temps écoulé. Prenez vous-même la durée à partir de l'horloge murale, et lisez les totaux de tokens à partir de l'enregistrement de la session enfant dans ~/.dsh/storages/session_projcache/sessions/<enfantId>.json (tokenUsage.val.totals — uncachedInputTokens, outputTokens, cacheReadTokens, cacheWriteTokens). Enregistrez ces données immédiatement dans timing.json dans le répertoire d'exécution :
{
"total_tokens": 84852,
"duration_ms": 23332,
"total_duration_seconds": 23.3
}
Si cet enregistrement de session est manquant ou n'a pas d'utilisation de tokens, omettez les champs de tokens plutôt que d'inventer des nombres. Traitez chaque notification dès qu'elle arrive plutôt que d'essayer de les regrouper.
Étape 4 : Notez, agrégez et lancez le visualiseur
Une fois toutes les exécutions terminées :
-
Notez chaque exécution — lancez un sous-agent de notation (ou notez en ligne) qui lit
agents/grader.mdet évalue chaque assertion par rapport aux sorties. Enregistrez les résultats dansgrading.jsondans chaque répertoire d'exécution. Le tableauexpectationsde grading.json doit utiliser les champstext,passedetevidence(pasname/met/detailsou d'autres variantes) — le visualiseur dépend de ces noms de champ exacts. Pour les assertions qui peuvent être vérifiées par programme, écrivez et exécutez un script plutôt que de les évaluer à l'œil — les scripts sont plus rapides, plus fiables et peuvent être réutilisés entre les itérations. -
Agrégez en benchmark — exécutez le script d'agrégation depuis le répertoire dsh-skill-creator :
python -m scripts.aggregate_benchmark <espace de travail>/iteration-N --skill-name <nom>Cela produit
benchmark.jsonetbenchmark.mdavec le taux de réussite, le temps et les tokens pour ...