run

Présentation du run skill

Ce que fait le run skill

run est un skill d’orchestration AgentHub pour Claude qui expose la commande /hub:run. Il exécute en une seule requête un cycle complet de type compétition : initialisation de la tâche, capture d’une baseline, lancement de plusieurs agents, évaluation de leurs résultats, puis fusion de la meilleure proposition. Utilisez le run skill lorsque vous voulez qu’un workflow agentique compare plusieurs tentatives de solution, plutôt que de demander une réponse directe unique.

Pour quels utilisateurs AgentHub le run skill est le plus adapté

Le run skill convient surtout aux équipes qui utilisent déjà le modèle de commandes AgentHub et qui veulent un point d’entrée unique, de haut niveau, pour une exécution multi-agent. Il est adapté aux tâches d’ingénierie comme l’optimisation des performances, le refactoring, la génération de tests, la correction de bugs et les améliorations mesurables du code. Il peut aussi servir à sélectionner des propositions créatives hors code avec le mode judge, par exemple pour choisir la meilleure accroche marketing parmi plusieurs variantes.

Le point de décision principal avant installation

Installez run si vous voulez une commande reproductible qui enchaîne le cycle de vie AgentHub sans appeler manuellement /hub:init, la capture de baseline, le lancement des agents, l’évaluation et les étapes de fusion. Ne le considérez pas comme un exécuteur d’automatisation généraliste : sa valeur dépend d’une tâche qui peut être évaluée ou jugée, ainsi que d’un environnement AgentHub où les commandes associées sont disponibles.

Ce qui distingue le run skill

Contrairement à un prompt ordinaire qui demande à Claude « d’essayer plusieurs approches », /hub:run donne à l’agent un cycle de vie structuré avec des paramètres explicites : tâche, nombre d’agents, commande d’évaluation optionnelle, métrique, sens d’optimisation et template. Cette structure rend le résultat plus facile à comparer, auditer et fusionner.

Comment utiliser le run skill

Installation de run et vérification du repository

Installez le skill depuis le repository avec votre gestionnaire de skills, par exemple :

npx skills add alirezarezvani/claude-skills --skill run

Commencez ensuite par examiner le fichier upstream :

engineering/agenthub/skills/run/SKILL.md

Ce chemin de repository contient le comportement central et les exemples. Dans l’arborescence fournie, aucun dossier compagnon visible scripts/, resources/, references/ ou rules/ n’apparaît pour ce skill ; l’adoption dépend donc principalement de votre compréhension du contrat de commande dans SKILL.md et de la disponibilité de l’ensemble plus large de commandes AgentHub.

Schéma d’utilisation de base de run

Le format de la commande est :

/hub:run --task "..." --agents 3 --eval "..." --metric metric_name --direction lower --template optimizer

Paramètres importants :

• --task : obligatoire ; la tâche exacte sur laquelle les agents doivent concourir.
• --agents : optionnel ; vaut 3 par défaut dans les exemples source.
• --eval : optionnel ; commande utilisée pour mesurer les résultats.
• --metric : obligatoire avec --eval ; valeur à comparer.
• --direction : obligatoire lors de la comparaison d’une métrique ; utilisez lower ou higher.
• --template : optionnel ; les exemples incluent optimizer, refactorer, test-writer et bug-fixer.
• --judge : utile lorsqu’il n’existe pas de métrique déterministe et qu’un juge LLM doit comparer les résultats.

Transformer un objectif vague en commande solide

Une demande faible serait :

/hub:run --task "make it faster"

Une meilleure invite d’utilisation de run serait :

/hub:run --task "Reduce p50 latency in the product search endpoint without changing response schema" --agents 3 --eval "pytest bench.py --json" --metric p50_ms --direction lower --template optimizer

Cette version améliore la qualité des sorties, car elle définit la zone ciblée, conserve une contrainte, fournit aux agents un benchmark mesurable, nomme la métrique et précise le sens gagnant. Pour un travail sur la couverture de tests, utilisez une métrique où une valeur plus élevée est meilleure :

/hub:run --task "Add tests for untested utils without modifying production behavior" --agents 3 --eval "pytest --cov=utils --cov-report=json" --metric coverage_pct --direction higher --template test-writer

Workflow conseillé avant fusion

Avant d’utiliser le run skill sur du code important, vérifiez que le repository est propre, que les tests sont reproductibles et que la commande d’évaluation renvoie une sortie exploitable par machine ou au moins analysable de façon cohérente. Commencez avec 2 à 3 agents pour maîtriser les coûts et la vitesse. Pour le code, privilégiez autant que possible des évaluations déterministes, et réservez --judge aux sorties subjectives comme la rédaction publicitaire ou les variantes de design. Une fois la proposition gagnante fusionnée, relisez tout de même le diff manuellement ; le skill orchestre la sélection, mais il ne remplace pas la responsabilité sur le code.

FAQ du run skill

run sert-il à l’orchestration d’agents ou au prompting simple ?

run sert à l’orchestration d’agents. Il est conçu pour coordonner plusieurs agents tout au long d’un cycle de vie et sélectionner un gagnant. Si vous avez seulement besoin d’une explication, d’une suggestion de refactoring ou d’un brouillon, un prompt classique est plus simple. Utilisez le run skill lorsque la comparaison, l’évaluation et la discipline de fusion sont importantes.

Que faut-il déjà avoir pour que run fonctionne correctement ?

Vous avez besoin d’une configuration compatible avec AgentHub, capable de reconnaître /hub:run et les commandes de cycle de vie associées. Pour les tâches logicielles mesurables, il vous faut aussi une commande d’évaluation fiable, un nom de métrique clair et un sens d’optimisation connu. Sans ces éléments, la commande peut toujours fonctionner en mode judge, mais le résultat sera moins objectif.

Quand faut-il éviter ce skill ?

Évitez run pour les tâches vagues sans critères d’acceptation, les changements destructifs sans plan de retour arrière ou les projets dont les tests et benchmarks sont instables. Évitez également d’utiliser trop d’agents par défaut ; davantage d’agents peut augmenter les coûts et la charge de revue sans améliorer la qualité si la définition de la tâche est faible.

Le run skill est-il adapté aux débutants ?

Il est abordable si vous comprenez déjà les skills Claude sous forme de commandes et les concepts de base d’AgentHub. Les débutants peuvent être déstabilisés par les paramètres d’évaluation, en particulier --metric et --direction. Commencez avec le mode judge pour des tâches créatives à faible risque, ou utilisez une commande de test simple avant de tenter des workflows de performance, de refactoring ou avec beaucoup de fusion.

Comment améliorer le run skill

Améliorer les résultats de run avec des limites de tâche plus nettes

Le run skill donne les meilleurs résultats lorsque la tâche est suffisamment ciblée pour que les agents puissent l’exécuter indépendamment. Indiquez les fichiers visés, le comportement attendu, les contraintes et ce qui ne doit pas changer. Par exemple, « Refactor auth module » est acceptable, mais « Refactor src/auth/session.ts to reduce duplication while preserving public function signatures and existing tests » donne aux agents un cadre d’intervention plus sûr.

Renforcer les évaluations et les métriques

Pour les tâches de code, la commande d’évaluation est le levier de qualité le plus important. Préférez les commandes qui échouent clairement et produisent une métrique stable. Associez la métrique au bon sens d’optimisation : la latence et le nombre d’erreurs utilisent généralement lower ; la couverture, le débit ou un score utilisent généralement higher. Si la sortie d’évaluation est ambiguë, la décision de fusion peut devenir peu fiable, même lorsque les agents ont produit un travail utile.

Surveiller les modes d’échec fréquents

Les échecs courants incluent les tâches trop larges, les métriques manquantes, les suites de tests instables, les décisions en mode judge sur des tâches qui devraient être mesurées, et les templates qui ne correspondent pas au travail demandé. Utilisez optimizer pour une amélioration de performance mesurable, test-writer pour la couverture, refactorer pour un nettoyage qui préserve la structure, et bug-fixer pour la correction de défauts. Un template mal choisi peut pousser les agents vers le mauvais type de solution.

Itérer après la première sortie

Après le premier /hub:run, examinez le diff gagnant ainsi que les approches perdantes. Si aucune proposition n’est acceptable, ne relancez pas simplement la même commande. Resserrez la tâche, ajoutez des contraintes, améliorez l’évaluation ou réduisez le périmètre. Si la proposition gagnante est proche du résultat attendu mais incomplète, lancez une commande de suivi centrée uniquement sur le point manquant au lieu de redémarrer tout le cycle de vie.