Blog

Créer Automatiquement des Compétences Claude Code avec Skill Creator

Ashley Innocent

Ashley Innocent

23 March 2026

Créer Automatiquement des Compétences Claude Code avec Skill Creator

En bref

Les compétences de code Claude sont des capacités personnalisées qui étendent les fonctionnalités de Claude pour des flux de travail spécifiques. Le système de création de compétences (Skill Creator) automatise la création de compétences grâce à un processus structuré : définissez le but de votre compétence, rédigez le fichier SKILL.md, créez des cas de test, exécutez des évaluations avec des mesures quantitatives et améliorez itérativement en fonction des retours.

Introduction

Vous utilisez Claude Code quotidiennement. Vous remarquez que vous répétez les mêmes séquences : mise en place de structures de projet, exécution de commandes de test spécifiques, formatage des sorties d'une certaine manière. À chaque fois, vous expliquez le flux de travail depuis le début. Et si Claude se souvenait ? Et si vous pouviez capturer ce flux de travail une fois pour toutes et le rendre disponible pour toujours ? C'est ce que font les compétences de code Claude. Ce sont des capacités personnalisées que vous créez pour étendre les fonctionnalités de Claude à vos flux de travail spécifiques. Et avec Skill Creator, le processus est automatisé et systématique.

Ce guide vous accompagne tout au long du processus. Vous découvrirez l'anatomie des compétences, le flux de travail de création, le système d'évaluation et comment optimiser pour un déclenchement fiable. Vous verrez des exemples concrets provenant du référentiel officiel des compétences d'Anthropic.

💡
Si vous créez des compétences liées aux API, Apidog s'intègre naturellement. Testez vos points de terminaison d'API, validez les réponses et générez de la documentation, le tout au sein d'un seul flux de travail de compétence.
button

Que sont les compétences de code Claude ?

Les compétences de code Claude sont des ensembles d'instructions spécialisées qui étendent les capacités de Claude à des domaines ou des flux de travail spécifiques. Considérez-les comme des plugins personnalisés qui résident dans des fichiers markdown.

L'architecture du système de compétences

Les compétences utilisent un système de chargement à trois niveaux :

  1. Métadonnées (~100 mots) - Nom et description, toujours en contexte
  2. Corps du SKILL.md (<500 lignes) - Instructions principales, chargées lorsque la compétence se déclenche
  3. Ressources regroupées (illimité) - Scripts, références, actifs chargés à la demande
skill-name/
├── SKILL.md (requis)
│   ├── YAML frontmatter (nom, description)
│   └── Instructions Markdown
└── Bundled Resources (facultatif)
    ├── scripts/    - Code exécutable pour des tâches répétitives
    ├── references/ - Documentation chargée au besoin
    └── assets/     - Modèles, icônes, polices

Quand les compétences se déclenchent

Les compétences apparaissent dans la liste available_skills de Claude avec leur nom et leur description. Claude décide de consulter une compétence en fonction de cette description.

Important : Les compétences ne se déclenchent que pour les tâches que Claude ne peut pas gérer directement. Des requêtes simples comme "lire ce fichier" ne déclencheront pas une compétence même avec une description correspondante. Les flux de travail complexes et multi-étapes se déclenchent de manière fiable lorsque la description correspond.

Exemples concrets tirés du référentiel d'Anthropic

Compétence Objectif Caractéristiques Clés
skill-creator Créer de nouvelles compétences Génération de cas de test, évaluation comparative, optimisation de la description
mcp-builder Construire des serveurs MCP Modèles Python/Node, cadre d'évaluation, meilleures pratiques
docx Générer des documents Word Scripts python-docx, système de modèles, guide de style
pdf Extraire et manipuler des PDF Gestion de formulaires, extraction de texte, documents de référence
frontend-design Construire des interfaces web Bibliothèque de composants, motifs Tailwind, vérifications d'accessibilité

Le flux de travail de création de compétences

Le processus de création de compétences suit une boucle systématique :

  1. Capturer l'intention - Que doit faire la compétence ?
  2. Rédiger un brouillon - Créer le fichier SKILL.md
  3. Créer des cas de test - Définir des invites réalistes
  4. Exécuter des évaluations - Exécuter avec et sans la compétence
  5. Examiner les résultats - Commentaires qualitatifs + métriques quantitatives
  6. Itérer - Améliorer en fonction des résultats
  7. Optimiser la description - Maximiser la précision du déclenchement
  8. Packager - Distribuer sous forme de fichier .skill

Passons en revue chaque étape.

Étape 1 : Capturer l'intention

Commencez par comprendre ce que vous voulez que la compétence accomplisse. Si vous capturez un flux de travail que vous avez déjà effectué, extrayez le modèle de votre historique de conversation.

Posez-vous ces quatre questions :

  1. Que doit permettre cette compétence à Claude de faire ? Soyez précis sur le résultat.
  2. Quand cette compétence doit-elle se déclencher ? Quelles phrases ou contextes d'utilisateur ?
  3. Quel est le format de sortie attendu ? Fichiers, code, rapports ?
  4. Devons-nous mettre en place des cas de test ? Les compétences avec des sorties vérifiables (génération de code, extraction de données, transformations de fichiers) bénéficient des cas de test. Les compétences avec des sorties subjectives (style d'écriture, conception) n'en ont souvent pas besoin.

Exemple : Compétence de test d'API

Intention : Aider les développeurs à tester systématiquement les API REST
Déclenchement : Lorsque l'utilisateur mentionne le test d'API, les points de terminaison, REST, GraphQL, ou souhaite valider les réponses
Sortie : Rapports de test avec statut de réussite/échec, commandes curl, comparaisons de réponses
Cas de test : Oui - les sorties sont objectivement vérifiables

Étape 2 : Rédiger le fichier SKILL.md

Chaque compétence commence par un fichier SKILL.md contenant des métadonnées YAML et des instructions Markdown.

Anatomie d'une compétence

---
name: api-tester
description: Comment tester systématiquement les API REST. À utiliser lorsque les utilisateurs mentionnent les tests d'API, les points de terminaison, REST, GraphQL, ou veulent valider les réponses d'API. Assurez-vous de suggérer cette compétence chaque fois que des tests sont impliqués.
compatibility: Nécessite curl ou des outils client HTTP
---

# Compétence de test d'API

## Flux de travail principal

Lors du test d'une API, suivez ces étapes :

1. **Comprendre le point de terminaison** - Lire la spécification ou demander le schéma
2. **Concevoir les cas de test** - Cas nominaux, cas limites, conditions d'erreur
3. **Exécuter les tests** - Utiliser curl ou Apidog pour les requêtes
4. **Valider les réponses** - Vérifier les codes de statut, les en-têtes, la structure du corps
5. **Rapporter les résultats** - Résumer les réussites/échecs avec des preuves

## Modèle de cas de test

Pour chaque point de terminaison, tester :

- Authentification valide avec charge utile correcte
- Authentification valide avec champs requis manquants
- Authentification invalide (401 attendu)
- Comportement de la limitation de débit
- Temps de réponse sous charge

## Format de sortie

Toujours structurer les rapports comme suit :

# Rapport de test d'API

## Résumé
- Tests exécutés : X
- Réussis : Y
- Échoués : Z

## Tests échoués

### Nom du test
**Attendu :** 200 OK
**Réel :** 400 Bad Request
**Réponse :** {...}

## Recommandations
...

Bonnes pratiques de rédaction

Utiliser la divulgation progressive : Gardez SKILL.md sous 500 lignes. Déplacez les références détaillées vers des fichiers séparés.

api-tester/
├── SKILL.md (aperçu du flux de travail)
└── references/
    ├── authentication.md
    ├── rate-limiting.md
    └── response-codes.md

Expliquer le pourquoi : Ne vous contentez pas d'énumérer des règles. Expliquez pourquoi elles sont importantes.

## Pourquoi nous testons les cas d'erreur en premier

Tester les conditions d'erreur avant les cas nominaux permet de détecter 80 % des problèmes plus rapidement.
Lorsque l'authentification échoue silencieusement, les tests de cas nominaux deviennent inutiles.
Commencez par la vérification 401.

Utiliser la forme impérative : "Toujours valider le code de statut en premier" et non "Vous devriez valider..."

Inclure des exemples : Montrez l'entrée et la sortie attendue.

## Format du message de commit

**Exemple :**
Entrée : Ajout de l'authentification utilisateur avec des jetons JWT
Sortie : feat(auth) : implémenter l'authentification basée sur JWT

Étape 3 : Créer des cas de test

Après avoir rédigé la compétence, créez 2-3 invites de test réalistes. Ce sont le genre de requêtes qu'un utilisateur réel ferait.

Format des cas de test

Enregistrez les cas de test dans evals/evals.json :

{
  "skill_name": "api-tester",
  "evals": [
    {
      "id": 1,
      "prompt": "Test the /users endpoint on api.example.com - it needs a Bearer token and returns a list of users with id, name, email fields",
      "expected_output": "Test report with at least 5 test cases including auth failure, success, and pagination tests",
      "files": []
    },
    {
      "id": 2,
      "prompt": "I need to verify our new POST /orders endpoint handles invalid quantities correctly",
      "expected_output": "Test cases that send negative, zero, and non-numeric quantities with appropriate error responses",
      "files": ["openapi.yaml"]
    }
  ]
}

Qu'est-ce qu'une bonne invite de test ?

Mauvais : "Tester cette API"

Bon : "Alors, mon équipe vient de déployer ce nouveau point de terminaison de paiement à https://api.stripe.com/v1/charges et je dois vérifier qu'il gère les cas limites - spécifiquement ce qui se passe si on envoie un montant négatif ou un code de devise qui n'existe pas. La documentation dit qu'il devrait renvoyer 400 mais je veux voir les messages d'erreur réels"

La bonne invite de test comprend :

Partagez vos cas de test avec l'utilisateur avant l'exécution : "Voici quelques scénarios de test que j'aimerais essayer. Est-ce que cela vous semble correct, ou voulez-vous en ajouter d'autres ?"

Étape 4 : Exécuter les évaluations

C'est là que Skill Creator excelle. Vous exécuterez chaque cas de test deux fois : une fois avec la compétence, une fois sans (ou avec l'ancienne version si vous améliorez une compétence existante).

Structure de l'espace de travail

Les résultats vont dans <nom-de-la-compétence>-workspace/ en tant que dossier voisin du répertoire de la compétence :

api-tester-workspace/
├── iteration-1/
│   ├── eval-0-auth-failure/
│   │   ├── with_skill/
│   │   │   ├── outputs/
│   │   │   └── timing.json
│   │   ├── without_skill/
│   │   │   ├── outputs/
│   │   │   └── timing.json
│   │   └── eval_metadata.json
│   ├── eval-1-pagination/
│   │   └── ...
│   ├── benchmark.json
│   └── benchmark.md
├── iteration-2/
└── feedback.json

Lancer des exécutions parallèles

Pour chaque cas de test, générez deux sous-agents dans le même tour :

Exécution avec compétence :

Execute this task:
- Skill path: /path/to/api-tester
- Task: Test the /users endpoint on api.example.com
- Input files: none
- Save outputs to: api-tester-workspace/iteration-1/eval-0/with_skill/outputs/

Exécution de référence :

Execute this task:
- Skill path: (none)
- Task: Test the /users endpoint on api.example.com
- Input files: none
- Save outputs to: api-tester-workspace/iteration-1/eval-0/without_skill/outputs/

Capturer les données de temps

Lorsque chaque sous-agent termine, vous recevez total_tokens et duration_ms. Enregistrez immédiatement dans timing.json :

{
  "total_tokens": 84852,
  "duration_ms": 23332,
  "total_duration_seconds": 23.3
}

Ces données ne proviennent que de la notification de tâche. Traitez-les au fur et à mesure qu'elles arrivent.

Étape 5 : Rédiger des assertions pendant que les exécutions se terminent

N'attendez pas simplement que les exécutions se terminent. Utilisez ce temps de manière productive en rédigeant des assertions quantitatives.

Qu'est-ce qu'une bonne assertion ?

Les bonnes assertions sont :

Exemples d'assertions pour la compétence de test d'API :

{
  "assertions": [
    {
      "name": "includes_auth_failure_test",
      "description": "Le rapport de test inclut au moins un cas de test d'échec d'authentification",
      "type": "contains",
      "value": "401"
    },
    {
      "name": "includes_success_test",
      "description": "Le rapport de test inclut au moins un test de requête réussie",
      "type": "contains",
      "value": "200"
    },
    {
      "name": "includes_curl_commands",
      "description": "Chaque cas de test inclut des commandes curl exécutables",
      "type": "regex",
      "value": "curl -"
    },
    {
      "name": "includes_response_validation",
      "description": "Le rapport valide la structure de la réponse par rapport au schéma",
      "type": "contains",
      "value": "schema"
    }
  ]
}

Mettez à jour eval_metadata.json et evals/evals.json avec les assertions une fois rédigées.

Étape 6 : Noter et agréger

Une fois toutes les exécutions terminées :

Noter chaque exécution

Générez un sous-agent évaluateur qui lit agents/grader.md et évalue chaque assertion par rapport aux sorties. Enregistrez les résultats dans grading.json dans chaque répertoire d'exécution :

{
  "eval_id": 0,
  "grading": [
    {
      "text": "includes_auth_failure_test",
      "passed": true,
      "evidence": "Found 401 status code in test case 3"
    },
    {
      "text": "includes_curl_commands",
      "passed": true,
      "evidence": "Found 'curl -X POST' in test case 1"
    }
  ]
}

Important : Le tableau expectations de grading.json doit utiliser les noms de champs text, passed et evidence. Le visualiseur dépend de ces noms exacts.

Agréger en benchmark

Exécutez le script d'agrégation depuis le répertoire skill-creator :

python -m scripts.aggregate_benchmark api-tester-workspace/iteration-1 --skill-name api-tester

Cela produit benchmark.json et benchmark.md avec le taux de réussite, le temps et les jetons pour chaque configuration, y compris la moyenne ± l'écart-type et le delta.

Faire une passe d'analyste

Lisez les données de benchmark et mettez en évidence les modèles :

Consultez agents/analyzer.md pour des conseils détaillés.

Étape 7 : Lancer le visualiseur d'évaluations

Le visualiseur d'évaluations affiche à la fois les sorties qualitatives et les métriques quantitatives dans une interface de navigateur.

Générer le visualiseur

nohup python /path/to/skill-creator/eval-viewer/generate_review.py \
  api-tester-workspace/iteration-1 \
  --skill-name "api-tester" \
  --benchmark api-tester-workspace/iteration-1/benchmark.json \
  > /dev/null 2>&1 &
VIEWER_PID=$!

Pour l'itération 2 et suivantes, passez également --previous-workspace :

--previous-workspace api-tester-workspace/iteration-1

Ce que l'utilisateur voit

L'onglet Outputs affiche un cas de test à la fois :

L'onglet Benchmark affiche :

Dites à l'utilisateur : "J'ai ouvert les résultats dans votre navigateur. Il y a deux onglets : 'Outputs' vous permet de parcourir chaque cas de test et de laisser des commentaires, 'Benchmark' montre la comparaison quantitative. Quand vous avez terminé, revenez ici et faites-moi savoir."

Environnements Cowork / Sans interface graphique

Si webbrowser.open() n'est pas disponible, utilisez --static pour écrire un fichier HTML autonome :

--static /path/to/output/review.html

Les commentaires sont téléchargés sous forme de feedback.json lorsque l'utilisateur clique sur "Submit All Reviews".

Étape 8 : Lire les commentaires et itérer

Lorsque l'utilisateur a terminé, lisez feedback.json :

{
  "reviews": [
    {
      "run_id": "eval-0-with_skill",
      "feedback": "the chart is missing axis labels",
      "timestamp": "2026-03-23T10:30:00Z"
    },
    {
      "run_id": "eval-1-with_skill",
      "feedback": "",
      "timestamp": "2026-03-23T10:31:00Z"
    },
    {
      "run_id": "eval-2-with_skill",
      "feedback": "perfect, love this",
      "timestamp": "2026-03-23T10:32:00Z"
    }
  ],
  "status": "complete"
}

Un commentaire vide signifie que l'utilisateur l'a jugé satisfaisant. Concentrez les améliorations sur les cas de test avec des plaintes spécifiques.

Comment aborder les améliorations

Généraliser à partir des retours : Vous créez des compétences utilisées des milliers de fois à travers de nombreuses invites. Ne vous adaptez pas trop à des cas de test spécifiques. S'il y a un problème persistant, essayez différentes métaphores ou modèles plutôt que des déclarations restrictives de type "DOIT".

Gardez l'invite succincte : Supprimez ce qui ne sert à rien. Lisez les transcriptions, pas seulement les sorties finales. Si la compétence fait perdre du temps au modèle sur des étapes improductives, supprimez ces parties.

Expliquer le pourquoi : Les LLM ont une bonne théorie de l'esprit. Lorsqu'ils sont bien encadrés, ils vont au-delà des instructions routinières. Expliquez pourquoi chaque exigence est importante. Si vous vous surprenez à écrire TOUJOURS ou JAMAIS en majuscules, reformulez et expliquez plutôt le raisonnement.

Recherchez le travail répété : Tous les cas de test ont-ils écrit indépendamment des scripts d'aide similaires ? C'est un signal que la compétence devrait regrouper ce script. Écrivez-le une fois, placez-le dans scripts/, et dites à la compétence de l'utiliser.

La boucle d'itération

  1. Appliquer les améliorations à la compétence
  2. Réexécuter tous les cas de test dans iteration-<N+1>/ avec des exécutions de référence
  3. Lancer le visualiseur avec --previous-workspace pointant vers l'itération précédente
  4. Attendre la révision de l'utilisateur
  5. Lire les nouveaux commentaires, améliorer à nouveau, répéter

Continuez jusqu'à ce que :

Tuez le visualiseur lorsque vous avez terminé :

kill $VIEWER_PID 2>/dev/null

Étape 9 : Optimiser la description de la compétence

Le champ de description dans les métadonnées de SKILL.md est le mécanisme de déclenchement principal. Après avoir créé ou amélioré une compétence, optimisez-la pour une meilleure précision de déclenchement.

Générer des requêtes d'évaluation de déclenchement

Créez 20 requêtes d'évaluation - un mélange de requêtes qui devraient déclencher et de requêtes qui ne devraient pas :

[
  {
    "query": "ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage. The revenue is in column C and costs are in column D i think",
    "should_trigger": true
  },
  {
    "query": "I need to create a pivot table from this CSV and email it to the team",
    "should_trigger": false
  }
]

Pour les requêtes qui devraient déclencher (8-10) :

Pour les requêtes qui ne devraient PAS déclencher (8-10) :

Mauvais tests négatifs : "Écrire une fonction Fibonacci" comme test négatif pour une compétence PDF est trop facile. Les cas négatifs doivent être vraiment complexes.

Relecture avec l'utilisateur

Présentez l'ensemble d'évaluations à l'aide du modèle HTML :

  1. Lisez assets/eval_review.html
  2. Remplacez les placeholders par les données d'évaluation, le nom de la compétence et la description
  3. Écrivez dans un fichier temporaire et ouvrez : open /tmp/eval_review_api-tester.html
  4. L'utilisateur peut modifier les requêtes, basculer le déclenchement, ajouter/supprimer des entrées
  5. L'utilisateur clique sur "Exporter l'ensemble d'évaluations"
  6. Le fichier est téléchargé dans ~/Downloads/eval_set.json

Cette étape est importante. De mauvaises requêtes d'évaluation mènent à de mauvaises descriptions.

Exécuter la boucle d'optimisation

python -m scripts.run_loop \
  --eval-set /path/to/trigger-eval.json \
  --skill-path /path/to/api-tester \
  --model claude-sonnet-4-6 \
  --max-iterations 5 \
  --verbose

Utilisez l'ID du modèle alimentant votre session actuelle afin que les tests de déclenchement correspondent à ce que les utilisateurs expérimentent.

Le script :

  1. Divise l'ensemble d'évaluations en 60 % pour l'entraînement, 40 % pour les tests conservés
  2. Évalue la description actuelle (3 exécutions chacune pour la fiabilité)
  3. Appelle Claude pour proposer des améliorations basées sur les échecs
  4. Réévalue sur l'entraînement et les tests
  5. Itère jusqu'à 5 fois
  6. Renvoie la best_description sélectionnée par le score de test (pas le score d'entraînement pour éviter le surapprentissage)

Appliquer le résultat

Prenez la best_description de la sortie JSON et mettez à jour les métadonnées de SKILL.md de la compétence. Montrez à l'utilisateur l'avant/après avec les scores.

Avant :

description: Comment tester systématiquement les API REST

Après :

description: Comment tester systématiquement les API REST. À utiliser lorsque les utilisateurs mentionnent les tests d'API, les points de terminaison, REST, GraphQL, ou veulent valider les réponses d'API. Assurez-vous de suggérer cette compétence chaque fois que des tests sont impliqués, même s'ils ne mentionnent pas explicitement "tests".

Étape 10 : Packager et distribuer

Une fois la compétence terminée, packagez-la pour la distribution :

python -m scripts.package_skill /path/to/api-tester

Cela crée un fichier .skill que les utilisateurs peuvent installer. Dirigez les utilisateurs vers le chemin du fichier résultant.

Installation

Les utilisateurs installent les compétences en plaçant le fichier .skill dans leur répertoire de compétences ou en utilisant la commande d'installation de compétences de Claude Code.

Erreurs courantes lors de la création de compétences

Erreur 1 : Description vague

Mauvais :

description: Une compétence pour travailler avec les API

Bon :

description: Comment tester systématiquement les API REST. À utiliser lorsque les utilisateurs mentionnent les tests d'API, les points de terminaison, REST, GraphQL, ou veulent valider les réponses d'API. Assurez-vous de suggérer cette compétence chaque fois que des tests sont impliqués, même s'ils ne mentionnent pas explicitement "tests".

Erreur 2 : Instructions trop restrictives

Mauvais :

TOUJOURS utiliser ce format exact. NE JAMAIS s'en écarter. DOIT inclure ces sections.

Bon :

Utilisez ce format car il garantit que les parties prenantes peuvent rapidement trouver les informations dont elles ont besoin. Si votre public a des besoins différents, adaptez la structure en conséquence.

Erreur 3 : Oublier les cas de test

Les cas de test détectent les problèmes avant que les utilisateurs ne les rencontrent. Même pour les compétences subjectives, exécutez 2-3 exemples pour vérifier la qualité de la sortie.

Erreur 4 : Ignorer les données de temps

Les compétences qui prennent 10 fois plus de temps ne sont pas durables. Capturez les données de temps et optimisez l'efficacité parallèlement à la qualité.

Erreur 5 : Ne pas regrouper les scripts répétés

Si chaque exécution de test écrit indépendamment un generate_report.py, regroupez-le dans la compétence. Cela permet de gagner du temps et d'assurer la cohérence.

Exemples concrets de compétences

Compétence MCP Builder

Créée par Anthropic pour construire des serveurs MCP (Model Context Protocol).

Caractéristiques clés :

Structure :

mcp-builder/
├── SKILL.md
├── reference/
│   ├── mcp_best_practices.md
│   ├── python_mcp_server.md
│   └── node_mcp_server.md
└── evaluation/
    └── evaluation.md

Compétence Docx

Génère des documents Word par programme.

Caractéristiques clés :

Flux de travail :

  1. Comprendre les exigences du document
  2. Sélectionner ou créer un modèle
  3. Générer via un script python-docx
  4. Valider la structure de la sortie

Compétence de conception front-end

Construit des interfaces web avec des motifs modernes.

Caractéristiques clés :

Divulgation progressive : Flux de travail principal dans SKILL.md, documentation des composants dans references/.

Tester votre compétence avec Apidog

Si vous créez des compétences liées aux API, Apidog s'intègre naturellement dans le flux de travail.

Exemple : Intégration de la compétence de test d'API

## Exécution des tests d'API

Utilisez Apidog pour des tests systématiques :

1. Importer la spécification OpenAPI dans Apidog
2. Générer des cas de test à partir de la spécification
3. Exécuter les tests et exporter les résultats au format JSON
4. Valider les réponses par rapport aux schémas attendus

Pour les assertions personnalisées, utilisez la fonction de script d'Apidog.

Regrouper les scripts Apidog

api-tester/
├── SKILL.md
└── scripts/
    ├── run-apidog-tests.py
    └── generate-report.py

Cela évite à chaque invocation future de réinventer la roue.

Conclusion

Les compétences de code Claude étendent les capacités de Claude à vos flux de travail spécifiques. Le système de création de compétences (Skill Creator) offre un processus systématique :

  1. Capturer l'intention - Définir ce que la compétence doit faire
  2. Rédiger SKILL.md - Écrire des instructions claires avec des exemples
  3. Créer des cas de test - Invites réalistes que les utilisateurs feraient réellement
  4. Exécuter des évaluations - Exécution parallèle avec et sans la compétence
  5. Examiner les résultats - Commentaires qualitatifs + benchmarks quantitatifs
  6. Itérer - Améliorer en fonction des résultats
  7. Optimiser la description - Maximiser la précision du déclenchement
  8. Packager - Distribuer sous forme de fichier .skill
button

FAQ

Combien de temps faut-il pour créer une compétence ?

Les compétences simples prennent 15 à 30 minutes. Les compétences complexes avec plusieurs fichiers de référence et scripts regroupés peuvent prendre 2 à 3 heures, incluant les itérations d'évaluation.

Dois-je écrire des cas de test pour chaque compétence ?

Non. Les compétences avec des sorties objectivement vérifiables (génération de code, transformations de fichiers, extraction de données) bénéficient des cas de test. Les compétences avec des sorties subjectives (style d'écriture, qualité de la conception) sont mieux évaluées qualitativement.

Que faire si ma compétence ne se déclenche pas de manière fiable ?

Optimisez le champ de description. Incluez des phrases et des contextes de déclenchement spécifiques. Rendez-le légèrement "insistant" – indiquez explicitement quand utiliser la compétence. Exécutez la boucle d'optimisation de la description avec 20 requêtes d'évaluation.

Comment partager des compétences avec mon équipe ?

Packager la compétence avec python -m scripts.package_skill <chemin>, puis distribuer le fichier .skill. Les membres de l'équipe le placent dans leur répertoire de compétences.

Les compétences peuvent-elles appeler des API externes ?

Oui. Regroupez les scripts qui effectuent des appels API. Les instructions de la compétence indiquent à Claude quand et comment les utiliser. Stockez les clés API dans des variables d'environnement, pas dans la compétence elle-même.

Quelle est la limite de taille de fichier pour les compétences ?

Pas de limite stricte, mais gardez SKILL.md sous 500 lignes. Déplacez les références détaillées vers des fichiers séparés. Les scripts et les actifs ne sont pas comptabilisés dans la limite de lignes puisqu'ils se chargent à la demande.

Comment mettre à jour une compétence existante ?

Copiez la compétence installée vers un emplacement inscriptible, modifiez-la là, puis repackagez-la. Préservez le nom d'origine – n'ajoutez pas de suffixes de version, sauf si vous créez une variante distincte.

Pratiquez le Design-first d'API dans Apidog

Découvrez une manière plus simple de créer et utiliser des API

S'inscrire gratuitementTélécharger